Re: ifcvt: Fix PR104153 and PR104198

[Robin Dapp via Gcc-patches]

> Do you need to adjust anything now that this is emitting into TEMP 
> rather than TARGET?

The idea now is to emit to TEMP in the first pass and check if we read
the initial condition.  Overwriting the condition (and of course reading
it in every sequence) is the reason temporaries were needed in the first
place.

In the second pass (always done now) we use TEMP for those
SETs/sequences before the last one that read the condition and TARGET
for those after it.  Ideally it's TARGET for all of them which would
result in the best costing situation.

The whole logic was/is really a bit convoluted for what we want to
achieve but I'd argue it's not much worse than before ;)

Regards
 Robin

[committed] openmp, fortran: Improve !$omp atomic checks [PR104328]

[Jakub Jelinek via Gcc-patches]

Hi!

The testcase shows some cases that weren't verified and we ICE on
invalid because of that.
One problem is that unlike before, we weren't checking if some expression
is EXPR_VARIABLE with non-NULL symtree in the case where there was
a conversion around it.
The other two issues is that we check that in an IF ->block is non-NULL
and then immediately dereference ->block->next->op, but on invalid
code with no statements in the then clause ->block->next might be NULL.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to
trunk.

2022-02-02  Jakub Jelinek  

PR fortran/104328
* openmp.cc (is_scalar_intrinsic_expr): If must_be_var && conv_ok
and expr is conversion, verify it is a conversion from EXPR_VARIABLE
with non-NULL symtree.  Check ->block->next before dereferencing it.

* gfortran.dg/gomp/atomic-27.f90: New test.

--- gcc/fortran/openmp.cc.jj2022-01-21 11:01:12.458449420 +0100
+++ gcc/fortran/openmp.cc   2022-02-02 20:20:22.02000 +0100
@@ -7660,9 +7660,16 @@ static bool
 is_scalar_intrinsic_expr (gfc_expr *expr, bool must_be_var, bool conv_ok)
 {
   if (must_be_var
-  && (expr->expr_type != EXPR_VARIABLE || !expr->symtree)
-  && (!conv_ok || !is_conversion (expr, true, true)))
-return false;
+  && (expr->expr_type != EXPR_VARIABLE || !expr->symtree))
+{
+  if (!conv_ok)
+   return false;
+  gfc_expr *conv = is_conversion (expr, true, true);
+  if (!conv)
+   return false;
+  if (conv->expr_type != EXPR_VARIABLE || !conv->symtree)
+   return false;
+}
   return (expr->rank == 0
  && !gfc_is_coindexed (expr)
  && (expr->ts.type == BT_INTEGER
@@ -7705,6 +7712,7 @@ resolve_omp_atomic (gfc_code *code)
   if (next->op == EXEC_IF
  && next->block
  && next->block->op == EXEC_IF
+ && next->block->next
  && next->block->next->op == EXEC_ASSIGN)
{
  comp_cond = next->block->expr1;
@@ -7757,6 +7765,7 @@ resolve_omp_atomic (gfc_code *code)
   if (code->op == EXEC_IF
  && code->block
  && code->block->op == EXEC_IF
+ && code->block->next
  && code->block->next->op == EXEC_ASSIGN)
{
  comp_cond = code->block->expr1;
--- gcc/testsuite/gfortran.dg/gomp/atomic-27.f90.jj 2022-02-02 
20:30:44.101437198 +0100
+++ gcc/testsuite/gfortran.dg/gomp/atomic-27.f902022-02-02 
20:29:50.651217307 +0100
@@ -0,0 +1,34 @@
+! PR fortran/104328
+! { dg-do compile }
+
+subroutine foo
+  integer :: k = 1
+  !$omp atomic compare
+  if ( k == 2 ) then   ! { dg-error "unexpected !.OMP ATOMIC expression" }
+  end if
+end
+subroutine bar
+  real :: x = 1
+  !$omp atomic compare
+  if ( x == 2 ) then   ! { dg-error "unexpected !.OMP ATOMIC expression" }
+  end if
+end
+subroutine baz
+  integer :: i
+  !$omp atomic capture
+  i = 1
+  i = i + 1.   ! { dg-error "!.OMP ATOMIC capture-statement requires a 
scalar variable of intrinsic type" }
+end
+subroutine qux
+  integer :: i = 0
+  !$omp atomic capture
+  i = i + 1.0
+  i = i + 1.0  ! { dg-error "!.OMP ATOMIC capture-statement requires a 
scalar variable of intrinsic type" }
+end
+subroutine garply
+  logical :: k = .true.
+  !$omp atomic capture compare
+  if ( k ) then! { dg-error "unexpected !.OMP ATOMIC 
expression" }
+  else
+  end if
+end


Jakub

Re: s390: Fix bootstrap -Wformat-diag errors

[Robin Dapp via Gcc-patches]

Hi Martin,

> Either this:
> 
>error ("% is unknown", orig_p);
> 
> or this would be better:
> 
>error ("attribute % is unknown", orig_p);
> 
> The %< %> directives will render it in single quotes like keywords and
> identifiers.  Using %qs would render it in double quotes like a string,
> which wouldn't be quite right.

the x86 backend will print the error message in a different format using
single quotes e.g.

  bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown

I don't find that better to be frank but maybe it would make sense for
us to also adopt this error message style and not use a different one?
They use %qs, though - or is there an intention to also change x86's
error messages?  I guess in general it's better to have similar error
messages across targets for the same problem.

Regards
 Robin

Ping for [PATCH v6 00/12] Add LoongArch support.

[Paul Hua via Gcc-patches]

ping ?

On Fri, Jan 28, 2022 at 9:50 PM chenglulu  wrote:
>
> The LoongArch architecture (LoongArch) is an Instruction Set
> Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
> style.
> The documents are on
> https://loongson.github.io/LoongArch-Documentation/README-EN.html
>
> The ELF ABI Documents are on:
> https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
>
> The binutils has been merged into trunk:
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307
>
> Note: We split -mabi= into -mabi=lp64d/f/s, the new options not support by 
> upstream binutils yet,
> this GCC port requires the following patch applied to binutils to build.
> https://github.com/loongson/binutils-gdb/commit/aacb0bf860f02aa5a7dcb76dd0e392bf871c7586
> (will be submitted to upstream after gcc side comfirmed)
>
> We have compiled more than 300 CLFS packages with this compiler.
> The CLFS are currently used on Cfarm machines gcc400 and gcc401.
>
>
> changelog:
>
> v1 -> v2
> 1. Split patch set.
> 2. Change some code style.
> 3. Add -mabi=lp64d/f/s options.
> 4. Change GLIBC_DYNAMIC_LINKER_LP64 name.
>
> v2 -> v3
> 1. Change some code style.
> 2. Bug fix.
>
> v3 -> v4
> 1. Change some code style.
> 2. Bug fix.
> 3. Delete some builtin macros.
>
> v4 -> v5
> 1. delete wrong insn zero_extendsidi2_internal.
> 2. Adjust some build options.
> 3. Change some .c files to .cc.
>
> v5 -> v6
> 1. Fix compilation issues. The generated files *.opt and *.h
>are generated to $(objdir).
>
>
> chenglulu (12):
>   LoongArch Port: Regenerate configure
>   LoongArch Port: gcc build
>   LoongArch Port: Regenerate gcc/configure.
>   LoongArch Port: Machine Decsription files.
>   LoongArch Port: Machine description C files and .h files.
>   LoongArch Port: Builtin functions.
>   LoongArch Port: Builtin macros.
>   LoongArch Port: libgcc
>   LoongArch Port: Regenerate libgcc/configure.
>   LoongArch Port: libgomp
>   LoongArch Port: gcc/testsuite
>   LoongArch Port: Add doc.
>
>  config/picflag.m4 |3 +
>  configure |   10 +-
>  configure.ac  |   10 +-
>  contrib/config-list.mk|5 +-
>  contrib/gcc_update|2 +
>  .../config/loongarch/loongarch-common.cc  |   73 +
>  gcc/config.gcc|  410 +-
>  gcc/config/host-linux.cc  |2 +
>  gcc/config/loongarch/constraints.md   |  212 +
>  gcc/config/loongarch/generic.md   |  132 +
>  gcc/config/loongarch/genopts/genstr.sh|   91 +
>  .../loongarch/genopts/loongarch-strings   |   58 +
>  gcc/config/loongarch/genopts/loongarch.opt.in |  189 +
>  gcc/config/loongarch/gnu-user.h   |   84 +
>  gcc/config/loongarch/la464.md |  132 +
>  gcc/config/loongarch/larchintrin.h|  413 ++
>  gcc/config/loongarch/linux.h  |   50 +
>  gcc/config/loongarch/loongarch-builtins.cc|  511 ++
>  gcc/config/loongarch/loongarch-c.cc   |  109 +
>  gcc/config/loongarch/loongarch-cpu.cc |  206 +
>  gcc/config/loongarch/loongarch-cpu.h  |   30 +
>  gcc/config/loongarch/loongarch-def.c  |  164 +
>  gcc/config/loongarch/loongarch-def.h  |  151 +
>  gcc/config/loongarch/loongarch-driver.cc  |  187 +
>  gcc/config/loongarch/loongarch-driver.h   |   69 +
>  gcc/config/loongarch/loongarch-ftypes.def |  106 +
>  gcc/config/loongarch/loongarch-modes.def  |   29 +
>  gcc/config/loongarch/loongarch-opts.cc|  580 ++
>  gcc/config/loongarch/loongarch-opts.h |   86 +
>  gcc/config/loongarch/loongarch-protos.h   |  241 +
>  gcc/config/loongarch/loongarch-str.h  |   57 +
>  gcc/config/loongarch/loongarch-tune.h |   72 +
>  gcc/config/loongarch/loongarch.cc | 6330 +
>  gcc/config/loongarch/loongarch.h  | 1271 
>  gcc/config/loongarch/loongarch.md | 3702 ++
>  gcc/config/loongarch/loongarch.opt|  189 +
>  gcc/config/loongarch/predicates.md|  553 ++
>  gcc/config/loongarch/sync.md  |  574 ++
>  gcc/config/loongarch/t-linux  |   53 +
>  gcc/config/loongarch/t-loongarch  |   68 +
>  gcc/configure |   66 +-
>  gcc/configure.ac  |   33 +-
>  gcc/doc/install.texi  |   47 +-
>  gcc/doc/invoke.texi   |  201 +
>  gcc/doc/md.texi   |   55 +
>  gcc/testsuite/g++.dg/cpp0x/constexpr-rom.C|2 +-
>  gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C   |2 +-
>  gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C   |2 +-
>  gcc/testsuite/gcc.dg/20020312-2.c |2 +
>  gcc/testsuite/gcc.dg/loop-8.c |2 +-
>

Re: [PATCH] ranger: Fix up wi_fold_in_parts for small precision types [PR104334]

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Jakub Jelinek wrote:

> Hi!
> 
> The wide-int.h templates expect that when an int/long etc. operand is used
> it will be sign-extended based on the types precision.
> wi_fold_in_parts passes 3 such non-zero constants to wi::lt_p, wi::gt_p
> and wi::eq_p - 1, 3 and 4, which means it was doing weird things if either
> some of 1, 3 or 4 weren't representable in type, or if type was unsigned 3 bit
> type 4 should be written as -4.
> The following patch promotes the subtraction operands to widest_int and
> uses that as the type for ?h_range variables and compares them as such.
> We don't need the overflow handling because there is never an overflow.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux (on the former also
> with lto bootstrap), ok for trunk?

OK.

Thanks,
Richard.

> 2022-02-02  Jakub Jelinek  
> 
>   PR tree-optimization/104334
>   * range-op.cc (range_operator::wi_fold_in_parts): Change lh_range
>   and rh_range type to widest_int and subtract in widest_int.  Remove
>   ov_rh, ov_lh and sign vars, always perform comparisons as signed
>   and use >, < and == operators for it.
> 
>   * g++.dg/opt/pr104334.C: New test.
> 
> --- gcc/range-op.cc.jj2022-01-13 22:29:15.345831749 +0100
> +++ gcc/range-op.cc   2022-02-02 20:20:22.02000 +0100
> @@ -144,22 +144,21 @@ range_operator::wi_fold_in_parts (irange
> const wide_int &rh_lb,
> const wide_int &rh_ub) const
>  {
> -  wi::overflow_type ov_rh, ov_lh;
>int_range_max tmp;
> -  wide_int rh_range = wi::sub (rh_ub, rh_lb, TYPE_SIGN (type), &ov_rh);
> -  wide_int lh_range = wi::sub (lh_ub, lh_lb, TYPE_SIGN (type), &ov_lh);
> -  signop sign = TYPE_SIGN (type);;
> +  widest_int rh_range = wi::sub (widest_int::from (rh_ub, TYPE_SIGN (type)),
> +  widest_int::from (rh_lb, TYPE_SIGN (type)));
> +  widest_int lh_range = wi::sub (widest_int::from (lh_ub, TYPE_SIGN (type)),
> +  widest_int::from (lh_lb, TYPE_SIGN (type)));
>// If there are 2, 3, or 4 values in the RH range, do them separately.
>// Call wi_fold_in_parts to check the RH side.
> -  if (wi::gt_p (rh_range, 0, sign) && wi::lt_p (rh_range, 4, sign)
> -  && ov_rh == wi::OVF_NONE)
> +  if (rh_range > 0 && rh_range < 4)
>  {
>wi_fold_in_parts (r, type, lh_lb, lh_ub, rh_lb, rh_lb);
> -  if (wi::gt_p (rh_range, 1, sign))
> +  if (rh_range > 1)
>   {
> wi_fold_in_parts (tmp, type, lh_lb, lh_ub, rh_lb + 1, rh_lb + 1);
> r.union_ (tmp);
> -   if (wi::eq_p (rh_range, 3))
> +   if (rh_range == 3)
>   {
> wi_fold_in_parts (tmp, type, lh_lb, lh_ub, rh_lb + 2, rh_lb + 2);
> r.union_ (tmp);
> @@ -170,15 +169,14 @@ range_operator::wi_fold_in_parts (irange
>  }
>// Otherise check for 2, 3, or 4 values in the LH range and split them up.
>// The RH side has been checked, so no recursion needed.
> -  else if (wi::gt_p (lh_range, 0, sign) && wi::lt_p (lh_range, 4, sign)
> -&& ov_lh == wi::OVF_NONE)
> +  else if (lh_range > 0 && lh_range < 4)
>  {
>wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
> -  if (wi::gt_p (lh_range, 1, sign))
> +  if (lh_range > 1)
>   {
> wi_fold (tmp, type, lh_lb + 1, lh_lb + 1, rh_lb, rh_ub);
> r.union_ (tmp);
> -   if (wi::eq_p (lh_range, 3))
> +   if (lh_range == 3)
>   {
> wi_fold (tmp, type, lh_lb + 2, lh_lb + 2, rh_lb, rh_ub);
> r.union_ (tmp);
> --- gcc/testsuite/g++.dg/opt/pr104334.C.jj2022-02-02 14:35:51.184657968 
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr104334.C   2022-02-02 14:37:14.888478594 
> +0100
> @@ -0,0 +1,40 @@
> +// PR tree-optimization/104334
> +// { dg-do run { target c++11 } }
> +// { dg-options "-O2 --param logical-op-non-short-circuit=0" }
> +
> +enum class A { A0, A1, A2, A3 };
> +int x;
> +
> +__attribute__((noipa)) void
> +baz ()
> +{
> +  x = 1;
> +}
> +
> +struct B {
> +  unsigned b : 2;
> +
> +  A
> +  foo () const
> +  {
> +return static_cast (b);
> +  }
> +
> +  __attribute__((noinline)) void
> +  bar ()
> +  {
> +if (foo () == A::A2 || foo () == A::A3)
> +  baz ();
> +  }
> +};
> +
> +int
> +main ()
> +{
> +  B c;
> +  c.b = 2;
> +  c.bar ();
> +  if (x != 1)
> +__builtin_abort ();
> +  return 0;
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)

[PATCH] libgcc: Actually force divide by zero

[Jakub Jelinek via Gcc-patches]

Hi!

Eric mentioned we have a code trying to divide by zero intentionally
in gcc (since r0-241 !).
But, it clearly doesn't do what it wanted (which I think is raise
SIGFPE if the target normally raises it upon division by zero)
since r7-4470-g606f928d3805614, because we replace the division instruction
by __builtin_trap (), which does raise some signal, but quite different,
and then sure, r12-6924-gc2b610e7c6c89fd optimizes away even that
__builtin_trap ().

So I think on the libgcc side we should just hide the fact we are dividing
by zero from the optimizers, but it raises the question about what Ada
actually mandates and wants for such cases.  Because in 7+ it can end up
with a different signal and supposedly different exception at least.

Ok for trunk if this passes bootstrap/regtest?

2022-02-03  Jakub Jelinek  

* libgcc2.c (__udivmoddi4): Add optimization barriers to actually
ensure division by zero.

--- libgcc/libgcc2.c.jj 2022-01-11 23:11:23.810270199 +0100
+++ libgcc/libgcc2.c2022-02-03 09:24:14.513682731 +0100
@@ -1022,8 +1022,13 @@ __udivmoddi4 (UDWtype n, UDWtype d, UDWt
{
  /* qq = NN / 0d */
 
- if (d0 == 0)
-   d0 = 1 / d0;/* Divide intentionally by zero.  */
+ if (__builtin_expect (d0 == 0, 0))
+   {
+ UWtype one = 1;
+ __asm ("" : "+g" (one));
+ __asm ("" : "+g" (d0));
+ d0 = one / d0;/* Divide intentionally by zero.  */
+   }
 
  udiv_qrnnd (q1, n1, 0, n1, d0);
  udiv_qrnnd (q0, n0, n1, n0, d0);
@@ -1068,8 +1073,13 @@ __udivmoddi4 (UDWtype n, UDWtype d, UDWt
{
  /* qq = NN / 0d */
 
- if (d0 == 0)
-   d0 = 1 / d0;/* Divide intentionally by zero.  */
+ if (__builtin_expect (d0 == 0, 0))
+   {
+ UWtype one = 1;
+ __asm ("" : "+g" (one));
+ __asm ("" : "+g" (d0));
+ d0 = one / d0;/* Divide intentionally by zero.  */
+   }
 
  count_leading_zeros (bm, d0);
 


Jakub

[PATCH][pushed] s390x: Fix one more -Wformat-diag.

[Martin Liška]

gcc/ChangeLog:

* config/s390/s390.cc (s390_valid_target_attribute_inner_p):
Use the error message for i386 target.
---
 gcc/config/s390/s390.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 2db12d4ba4b..63b78ab16d8 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -15903,7 +15903,7 @@ s390_valid_target_attribute_inner_p (tree args,
   /* Process the option.  */
   if (!found)
{
- error ("attribute(target(\"%s\")) is unknown", orig_p);
+ error ("attribute %qs argument % is unknown", orig_p);
  return false;
}
   else if (attrs[i].only_as_pragma && !force_pragma)
@@ -15953,7 +15953,7 @@ s390_valid_target_attribute_inner_p (tree args,
}
  else
{
- error ("attribute(target(\"%s\")) is unknown", orig_p);
+ error ("attribute %qs argument % is unknown", orig_p);
  ret = false;
}
}
@@ -15970,7 +15970,7 @@ s390_valid_target_attribute_inner_p (tree args,
global_dc);
  else
{
- error ("attribute(target(\"%s\")) is unknown", orig_p);
+ error ("attribute %qs argument % is unknown", orig_p);
  ret = false;
}
}
--
2.34.1

Re: [PATCH] libgcc: Actually force divide by zero

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Jakub Jelinek wrote:

> Hi!
> 
> Eric mentioned we have a code trying to divide by zero intentionally
> in gcc (since r0-241 !).
> But, it clearly doesn't do what it wanted (which I think is raise
> SIGFPE if the target normally raises it upon division by zero)
> since r7-4470-g606f928d3805614, because we replace the division instruction
> by __builtin_trap (), which does raise some signal, but quite different,
> and then sure, r12-6924-gc2b610e7c6c89fd optimizes away even that
> __builtin_trap ().
> 
> So I think on the libgcc side we should just hide the fact we are dividing
> by zero from the optimizers, but it raises the question about what Ada
> actually mandates and wants for such cases.  Because in 7+ it can end up
> with a different signal and supposedly different exception at least.
> 
> Ok for trunk if this passes bootstrap/regtest?

I think the special case we're trying hard to _not_ optimize
is literal 0/0 for the case where the user wants to preserve
a trap.  But I see 0/0 optimized to zero by EVRP even in GCC 7 ...

IMHO it makes sense to have a way to represent the div-by-zero
trap, either by a builtin or by such kind of a division (if only
for QOI and maybe documented as such).

That is, fold-const.c and now match.pd still have

/* Preserve explicit divisions by 0: the C++ front-end wants to detect
   undefined behavior in constexpr evaluation, and assuming that the 
division
   traps enables better optimizations than these anyway.  */
(for div (trunc_div ceil_div floor_div round_div exact_div)
 /* 0 / X is always zero.  */
 (simplify
  (div integer_zerop@0 @1)
  /* But not for 0 / 0 so that we can get the proper warnings and errors.  
*/
  (if (!integer_zerop (@1))
   @0))

it suggests we want to preserve all X / 0 when the 0 is literal but
I think we can go a bit further and require 0/0 to not unnecessarily
restrict other special cases.

Comments on the libgcc case below

> 2022-02-03  Jakub Jelinek  
> 
>   * libgcc2.c (__udivmoddi4): Add optimization barriers to actually
>   ensure division by zero.
> 
> --- libgcc/libgcc2.c.jj   2022-01-11 23:11:23.810270199 +0100
> +++ libgcc/libgcc2.c  2022-02-03 09:24:14.513682731 +0100
> @@ -1022,8 +1022,13 @@ __udivmoddi4 (UDWtype n, UDWtype d, UDWt
>   {
> /* qq = NN / 0d */
>  
> -   if (d0 == 0)
> - d0 = 1 / d0;/* Divide intentionally by zero.  */
> +   if (__builtin_expect (d0 == 0, 0))
> + {
> +   UWtype one = 1;
> +   __asm ("" : "+g" (one));
> +   __asm ("" : "+g" (d0));
> +   d0 = one / d0;/* Divide intentionally by zero.  */
> + }

I'm not sure why we even bother - division or modulo by zero is
undefined behavior and we are not emulating CPU behavior because
the wide instructions emulated here do not actually exist.  That
gives us the freedom of choosing the implementation defined
behavior.

That said, _if_ we choose to "care" I'd rather choose to
define the implementation to use the trap mechanism the
target provides and thus use __builtin_trap ().  That then
at least traps reliably, compared to the division by zero
which doesn't do that on all targets.

So I'm not sure there's anything to fix besides eventually
just deleting the d0 == 0 special case?

Richard.

Re: s390: Fix bootstrap -Wformat-diag errors

[Martin Liška]

On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:

Hi Martin,


Either this:

error ("% is unknown", orig_p);

or this would be better:

error ("attribute % is unknown", orig_p);

The %< %> directives will render it in single quotes like keywords and
identifiers.  Using %qs would render it in double quotes like a string,
which wouldn't be quite right.


the x86 backend will print the error message in a different format using
single quotes e.g.

   bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown

I don't find that better to be frank but maybe it would make sense for
us to also adopt this error message style and not use a different one?
They use %qs, though - or is there an intention to also change x86's
error messages?  I guess in general it's better to have similar error
messages across targets for the same problem.

Regards
  Robin


Hello.

I've just coincidentally fixed the issue with r12-7013-g0415470c8d6620
where I use the same error format as i386 does.

Martin

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Eric Botcazou via Gcc-patches]

> Well, yes, we have to fix it.  I will share my thoughts when coming
> along the bugreport.

IMO we should simply scrap it, as it does not serve any useful purpose, breaks 
a very ancient and useful idiom and also introduces an artificial discrepancy 
between 1/X and 2/X for example.

-- 
Eric Botcazou

Re: [PATCH 0/3] Enable pointer_query caching throughout.

[Richard Biener via Gcc-patches]

On Thu, Feb 3, 2022 at 12:35 AM Martin Sebor  wrote:
>
> Richard, as we discussed(*), this patch series enables the pointer_query
> cache in the remaining two passes where it's currently disabled.  Since
> not using the cache is not an option anymore, the first patch in
> the series makes it a private member of the pointer_query class and its
> use unconditional.  It also simplifies the two passes that use it to
> avoid having to install it.
>
> Tested on x86_64-linux.

OK for the whole series.

Thanks for fixing this issue!
Richard.

> Martin
>
> [*] For reference:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589243.html

Re: [PATCH][pushed] s390x: Fix one more -Wformat-diag.

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 09:56:25AM +0100, Martin Liška wrote:
> gcc/ChangeLog:
> 
>   * config/s390/s390.cc (s390_valid_target_attribute_inner_p):
>   Use the error message for i386 target.
> ---
>  gcc/config/s390/s390.cc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
> index 2db12d4ba4b..63b78ab16d8 100644
> --- a/gcc/config/s390/s390.cc
> +++ b/gcc/config/s390/s390.cc
> @@ -15903,7 +15903,7 @@ s390_valid_target_attribute_inner_p (tree args,
>/* Process the option.  */
>if (!found)
>   {
> -   error ("attribute(target(\"%s\")) is unknown", orig_p);
> +   error ("attribute %qs argument % is unknown", orig_p);

This is backwards, isn't it?  It should be
"attribute % argument %qs is unknown", no?

> return false;
>   }
>else if (attrs[i].only_as_pragma && !force_pragma)
> @@ -15953,7 +15953,7 @@ s390_valid_target_attribute_inner_p (tree args,
>   }
> else
>   {
> -   error ("attribute(target(\"%s\")) is unknown", orig_p);
> +   error ("attribute %qs argument % is unknown", orig_p);
> ret = false;
>   }
>   }
> @@ -15970,7 +15970,7 @@ s390_valid_target_attribute_inner_p (tree args,
>   global_dc);
> else
>   {
> -   error ("attribute(target(\"%s\")) is unknown", orig_p);
> +   error ("attribute %qs argument % is unknown", orig_p);
> ret = false;
>   }
>   }
> -- 
> 2.34.1

Jakub

Re: [PATCH][pushed] s390x: Fix one more -Wformat-diag.

[Martin Liška]

On 2/3/22 10:08, Jakub Jelinek wrote:

This is backwards, isn't it?  It should be
"attribute % argument %qs is unknown", no?


Oh, correct:

cat x.c && gcc x.c -c
int __attribute__((target("-ff"))) foo() { }
x.c:1:36: error: attribute ‘-ff’ argument ‘target’ is unknown
1 | int __attribute__((target("-ff"))) foo() { }
  |^~~

Let me prepare a patch for both targets.

Martin

[PATCH][pushed] Fix wording for: attribute ‘-xyz’ argument ‘target’ is unknown

[Martin Liška]

Pushed based on Jakub's comment.

Martin

gcc/ChangeLog:

* config/i386/i386-options.cc (ix86_valid_target_attribute_inner_p):
Change subject and object in the error message.
* config/s390/s390.cc (s390_valid_target_attribute_inner_p):
Likewise.
---
 gcc/config/i386/i386-options.cc | 2 +-
 gcc/config/s390/s390.cc | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index 715d9a15ff5..082abd2c948 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -1201,7 +1201,7 @@ ix86_valid_target_attribute_inner_p (tree fndecl, tree 
args, char *p_strings[],
   if (opt == N_OPTS)
{
  error_at (loc, "attribute %qs argument %qs is unknown",
-   orig_p, attr_name);
+   attr_name, orig_p);
  ret = false;
}
 
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc

index 63b78ab16d8..5c2a830f9f0 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -15903,7 +15903,7 @@ s390_valid_target_attribute_inner_p (tree args,
   /* Process the option.  */
   if (!found)
{
- error ("attribute %qs argument % is unknown", orig_p);
+ error ("attribute % argument %qs is unknown", orig_p);
  return false;
}
   else if (attrs[i].only_as_pragma && !force_pragma)
@@ -15953,7 +15953,7 @@ s390_valid_target_attribute_inner_p (tree args,
}
  else
{
- error ("attribute %qs argument % is unknown", orig_p);
+ error ("attribute % argument %qs is unknown", orig_p);
  ret = false;
}
}
@@ -15970,7 +15970,7 @@ s390_valid_target_attribute_inner_p (tree args,
global_dc);
  else
{
- error ("attribute %qs argument % is unknown", orig_p);
+ error ("attribute % argument %qs is unknown", orig_p);
  ret = false;
}
}
--
2.34.1

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 10:06:42AM +0100, Eric Botcazou wrote:
> > Well, yes, we have to fix it.  I will share my thoughts when coming
> > along the bugreport.
> 
> IMO we should simply scrap it, as it does not serve any useful purpose, 
> breaks 
> a very ancient and useful idiom and also introduces an artificial discrepancy 
> between 1/X and 2/X for example.

That doesn't make sense.
The optimization can be useful, it doesn't have to be for user written
y = 1 / x; but can appear through inlining or some other optimizations, e.g.
jump threading and suddenly we have constant 1 in some bb, if it a never
executed at runtime block, it will be likely shorter because of the
optimization, if it is not, then it will be cheaper.
And, this is definitely not the first optimization that assumes undefined
behavior in integer division should not happen, lots of other optimizations
do the same thing.
E.g. consider
unsigned
foo (unsigned x, unsigned y)
{
  if (x >= 2)
return 0;
  if (x == 1)
y += 4;
  return y / x;
}
Here the ranger optimizes away the division, in GCC11 in vrp1 pass, in
GCC12 in evrp pass already.  Even in match.pd I vaguely remember one or two
optimizations where it also relied on division by zero being undefined.

Jakub

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Jakub Jelinek wrote:

> On Thu, Feb 03, 2022 at 10:06:42AM +0100, Eric Botcazou wrote:
> > > Well, yes, we have to fix it.  I will share my thoughts when coming
> > > along the bugreport.
> > 
> > IMO we should simply scrap it, as it does not serve any useful purpose, 
> > breaks 
> > a very ancient and useful idiom and also introduces an artificial 
> > discrepancy 
> > between 1/X and 2/X for example.
> 
> That doesn't make sense.
> The optimization can be useful, it doesn't have to be for user written
> y = 1 / x; but can appear through inlining or some other optimizations, e.g.
> jump threading and suddenly we have constant 1 in some bb, if it a never
> executed at runtime block, it will be likely shorter because of the
> optimization, if it is not, then it will be cheaper.
> And, this is definitely not the first optimization that assumes undefined
> behavior in integer division should not happen, lots of other optimizations
> do the same thing.
> E.g. consider
> unsigned
> foo (unsigned x, unsigned y)
> {
>   if (x >= 2)
> return 0;
>   if (x == 1)
> y += 4;
>   return y / x;
> }
> Here the ranger optimizes away the division, in GCC11 in vrp1 pass, in
> GCC12 in evrp pass already.  Even in match.pd I vaguely remember one or two
> optimizations where it also relied on division by zero being undefined.

Yes, we definitely have multiple of those cases.  I do think
preserving "an idiom", for example literal 0/0 or all x/0 might be
worth considering.  But I also think we have to sort out different
language standards requirements vs. the middle-end and whos
responsible for making sure we adhere here.

That said, for GCC 12 we can take shortcuts and one option is of
course to revert (but we don't have to rush).

oh, and even GCC 4.3 optimizes

int main()
{
  volatile int tem = 0/0;
}

to just

movl$0, -4(%rsp)

even with -fnon-call-exceptions -fexceptions.

Richard.

Re: Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812] (was: [PATCH][testsuite, nvptx] Add effective target sync_int_long_stack)

[Thomas Schwinge]

Hi Tom!

On 2021-05-19T14:56:17+0200, I wrote:
> On 2020-08-12T15:57:23+0200, Tom de Vries  wrote:
>> When enabling sync_int_long for nvptx, we run into a failure in
>> gcc.dg/pr86314.c:
>> ...
>>  nvptx-run: error getting kernel result: operation not supported on \
>>global/shared address space
>> ...
>> due to a ptx restriction:  accesses to local memory are illegal, and the
>> test-case does an atomic operation on a stack address, which is mapped to
>> local memory.
>
> Now, that problem also is easy to reproduce in an OpenACC/nvptx
> offloading setting.  (..., as Julian had reported and analyzed in an
> internal "Date: Fri, 31 May 2019 00:29:17 +0100" email, similar to Tom's
> comments in PR96494 "[nvptx] Enable effective target sync_int_long" and
> PR97444 "[nvptx] stack atomics".)
>
>> Fix this by adding a target sync_int_long_stack, wich returns false for 
>> nvptx,
>> which can be used to mark test-cases that require sync_int_long support for
>> stack address.

Shouldn't this now again be reverted/removed after your
commit e0451f93d9faa13495132f4e246e9bef30b51417
"[nvptx] Add some support for .local atomics"?
(But I haven't looked in detail.)


Is PR83812 "nvptx-run: error getting kernel result: operation not
supported on global/shared address space" resolved then?

Or, because of:

| This only solves some cases that are detected at compile-time.

... not completely resolved?

There's also still PR97444 "[nvptx] stack atomics" open.


> Similar to PR97444 "[nvptx] stack atomics", such a conditional is of
> course not applicable for the OpenACC implementation, so to at least
> document/test/XFAIL nvptx offloading: PR83812 "operation not supported
> on global/shared address space", I've now pushed to master branch
> "Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812]" in
> commit 1467100fc72562a59f70cdd4e05f6c810d1fadcc, see attached.

... which later got replicated in other test cases --
all of which I confirm are resolved and un-XFAILed with
commit e0451f93d9faa13495132f4e246e9bef30b51417
"[nvptx] Add some support for .local atomics".


> And then, I got back testresults from one more system, and I've filed
>  "[OpenACC/nvptx]
> 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in
> certain configurations"...  :-\

..., and that I also confirm to be resolved with
commit e0451f93d9faa13495132f4e246e9bef30b51417
"[nvptx] Add some support for .local atomics".


Grüße
 Thomas
-
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

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Eric Botcazou via Gcc-patches]

> The optimization can be useful, it doesn't have to be for user written
> y = 1 / x; but can appear through inlining or some other optimizations, e.g.
> jump threading and suddenly we have constant 1 in some bb, if it a never
> executed at runtime block, it will be likely shorter because of the
> optimization, if it is not, then it will be cheaper.

The hundreds of people having worked on GCC for the past 30 years must have 
been stupid then, how come have they missed such a great optimization? ;-)

-- 
Eric Botcazou

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 10:40:10AM +0100, Richard Biener wrote:
> Yes, we definitely have multiple of those cases.  I do think
> preserving "an idiom", for example literal 0/0 or all x/0 might be
> worth considering.  But I also think we have to sort out different
> language standards requirements vs. the middle-end and whos
> responsible for making sure we adhere here.

I think we try to preserve literal 0/0 and x/0, including this
optimization which punts if the divisor is literal.  But, for literal
0/0 and x/0 we alsy emit -Wdiv-by-zero warning, maybe that was the
reason why libgcc2.c did it differently.

Jakub

Re: Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812] (was: [PATCH][testsuite, nvptx] Add effective target sync_int_long_stack)

[Tom de Vries via Gcc-patches]

On 2/3/22 10:40, Thomas Schwinge wrote:

Hi Tom!

On 2021-05-19T14:56:17+0200, I wrote:

On 2020-08-12T15:57:23+0200, Tom de Vries  wrote:

When enabling sync_int_long for nvptx, we run into a failure in
gcc.dg/pr86314.c:
...
  nvptx-run: error getting kernel result: operation not supported on \
global/shared address space
...
due to a ptx restriction:  accesses to local memory are illegal, and the
test-case does an atomic operation on a stack address, which is mapped to
local memory.


Now, that problem also is easy to reproduce in an OpenACC/nvptx
offloading setting.  (..., as Julian had reported and analyzed in an
internal "Date: Fri, 31 May 2019 00:29:17 +0100" email, similar to Tom's
comments in PR96494 "[nvptx] Enable effective target sync_int_long" and
PR97444 "[nvptx] stack atomics".)


Fix this by adding a target sync_int_long_stack, wich returns false for nvptx,
which can be used to mark test-cases that require sync_int_long support for
stack address.


Shouldn't this now again be reverted/removed after your
commit e0451f93d9faa13495132f4e246e9bef30b51417
"[nvptx] Add some support for .local atomics"?
(But I haven't looked in detail.)


Is PR83812 "nvptx-run: error getting kernel result: operation not
supported on global/shared address space" resolved then?

Or, because of:

| This only solves some cases that are detected at compile-time.

... not completely resolved?



Yeah, I focused for now just on getting the libgomp testsuite passing.

The generic issue hasn't been fixed yet.  If you take the address of 
stack variable which results in generic addressing, you'll run into the 
same issue.  Fixing that'll involve runtime tests, which probably means 
introducing a -mstack-atomics or some such.



There's also still PR97444 "[nvptx] stack atomics" open.



Similar to PR97444 "[nvptx] stack atomics", such a conditional is of
course not applicable for the OpenACC implementation, so to at least
document/test/XFAIL nvptx offloading: PR83812 "operation not supported
on global/shared address space", I've now pushed to master branch
"Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812]" in
commit 1467100fc72562a59f70cdd4e05f6c810d1fadcc, see attached.


... which later got replicated in other test cases --
all of which I confirm are resolved and un-XFAILed with
commit e0451f93d9faa13495132f4e246e9bef30b51417
"[nvptx] Add some support for .local atomics".



And then, I got back testresults from one more system, and I've filed
 "[OpenACC/nvptx]
'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in
certain configurations"...  :-\


..., and that I also confirm to be resolved with
commit e0451f93d9faa13495132f4e246e9bef30b51417
"[nvptx] Add some support for .local atomics".




Ack, thanks for confirming.

Thanks,
- Tom

[PATCH] debug/104337 - avoid messing with the abstract origin chain in NRV

[Richard Biener via Gcc-patches]

The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after
variable creation since NRV runs _after_ the function was inlined and thus
affects the inlined variables copy indirectly.  We may adjust the abstract
origin of a variable only at the point we create it, not further along the
path since otherwise the (new) invariant that the abstract origin is always
the ultimate origin cannot be maintained.

The intent of what NRV does is OK I guess and it may improve the debug
experience.  But I also notice we do

  SET_DECL_VALUE_EXPR (found, result);
  DECL_HAS_VALUE_EXPR_P (found) = 1;

the code is there since the merge from tree-ssa which added tree-nrv.c.

Jakub added the DECL_VALUE_EXPR in g:938650d8fddb878f623e315f0b7fd94b217efa96
and Jason added the abstract origin setting conditional in g:7716876bbd3a

The follwoing takes the radical approach and remove the attempt
to "optimize" the debug info.

The gdb testsuites show no regressions.

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

OK?

Thanks,
Richard.

2022-02-03  Richard Biener  

PR debug/104337
* tree-nrv.cc (pass_nrv::execute): Remove tieing result and found
together via DECL_ABSTRACT_ORIGIN.

* gcc.dg/debug/pr104337.c: New testcase.
---
 gcc/testsuite/gcc.dg/debug/pr104337.c | 15 +++
 gcc/tree-nrv.cc   | 13 -
 2 files changed, 15 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/debug/pr104337.c

diff --git a/gcc/testsuite/gcc.dg/debug/pr104337.c 
b/gcc/testsuite/gcc.dg/debug/pr104337.c
new file mode 100644
index 000..d15680fbf1a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/pr104337.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+
+struct a {
+  unsigned b : 7;
+};
+inline __attribute__((optimize(3))) __attribute__((always_inline)) struct a
+c() {
+  struct a d;
+  return d;
+}
+void e() {
+  for (;;)
+c();
+}
+int main() {}
diff --git a/gcc/tree-nrv.cc b/gcc/tree-nrv.cc
index a67736dae5c..b96d5b86f27 100644
--- a/gcc/tree-nrv.cc
+++ b/gcc/tree-nrv.cc
@@ -236,19 +236,6 @@ pass_nrv::execute (function *fun)
   fprintf (dump_file, "\n");
 }
 
-  /* At this point we know that all the return statements return the
- same local which has suitable attributes for NRV.   Copy debugging
- information from FOUND to RESULT if it will be useful.  But don't set
- DECL_ABSTRACT_ORIGIN to point at another function.  */
-  if (!DECL_IGNORED_P (found)
-  && !(DECL_ABSTRACT_ORIGIN (found)
-  && DECL_CONTEXT (DECL_ABSTRACT_ORIGIN (found)) != 
current_function_decl))
-{
-  DECL_NAME (result) = DECL_NAME (found);
-  DECL_SOURCE_LOCATION (result) = DECL_SOURCE_LOCATION (found);
-  DECL_ABSTRACT_ORIGIN (result) = DECL_ABSTRACT_ORIGIN (found);
-}
-
   TREE_ADDRESSABLE (result) |= TREE_ADDRESSABLE (found);
 
   /* Now walk through the function changing all references to VAR to be
-- 
2.34.1

[pushed] testsuite: Update guality xfails for aarch64*-*-*

[Richard Sandiford via Gcc-patches]

Following on from GCC 11 patch g:f31ddad8ac8, this one gives clean
guality.exp test results for aarch64-linux-gnu with modern gdb
(this time gdb 11.2).

The justification is the same as previously:

--
For people using older gdbs, it will trade one set of noisy results for
another set.  I still think it's better to have the xfails based on
one “clean” and “modern” run rather than have FAILs and XPASSes for
all runs.

It's hard to tell which of these results are aarch64-specific and
which aren't.  If other target maintainers want to do something similar,
and are prepared to assume the same gdb version, then it should become
clearer over time which ones are target-specific and which aren't.

There are no new skips here, so changes in test results will still
show up as XPASSes.

I've not analysed the failures or filed PRs for them.  In some
ways the guality directory itself seems like the best place to
start looking for xfails, if someone's interested in working
in this area.
--

gcc/testsuite/
* gcc.dg/guality/ipa-sra-1.c: Update aarch64*-*-* xfails.
* gcc.dg/guality/pr54519-1.c: Likewise.
* gcc.dg/guality/pr54519-3.c: Likewise.
---
 gcc/testsuite/gcc.dg/guality/ipa-sra-1.c | 2 +-
 gcc/testsuite/gcc.dg/guality/pr54519-1.c | 6 +++---
 gcc/testsuite/gcc.dg/guality/pr54519-3.c | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/guality/ipa-sra-1.c 
b/gcc/testsuite/gcc.dg/guality/ipa-sra-1.c
index 5434b3d7665..9ef4eac93a7 100644
--- a/gcc/testsuite/gcc.dg/guality/ipa-sra-1.c
+++ b/gcc/testsuite/gcc.dg/guality/ipa-sra-1.c
@@ -12,7 +12,7 @@ static int __attribute__((noinline))
 bar (int i, int k)
 {
   asm ("" : "+r" (i));
-  use (i); /* { dg-final { gdb-test . "k" "3" { xfail *-*-* } } } 
*/
+  use (i); /* { dg-final { gdb-test . "k" "3" { xfail { ! { 
aarch64*-*-* && { any-opts "-O0" "-O1" "-Og" } } } } } } */
   return 6;
 }
 
diff --git a/gcc/testsuite/gcc.dg/guality/pr54519-1.c 
b/gcc/testsuite/gcc.dg/guality/pr54519-1.c
index 81703eb1744..5880d9b4f57 100644
--- a/gcc/testsuite/gcc.dg/guality/pr54519-1.c
+++ b/gcc/testsuite/gcc.dg/guality/pr54519-1.c
@@ -18,9 +18,9 @@ fn2 (int x, int y, int z)
   fn1 (x); /* { dg-final { gdb-test .+2 "x" "36" } } */
   if (x == 36) /* { dg-final { gdb-test .+1 "y" "25" { xfail { 
aarch64*-*-* && { any-opts "-flto" } } } } } */
fn1 (x);/* { dg-final { gdb-test . "z" "6" { xfail { 
aarch64*-*-* && { any-opts "-flto" } } } } } */
-  fn1 (x); /* { dg-final { gdb-test .+2 "x" "98" } } */
-  if (x == 98) /* { dg-final { gdb-test .+1 "y" "117" { xfail { 
aarch64*-*-* && { any-opts "-flto" } } } } } */
-   fn1 (x);/* { dg-final { gdb-test . "z" "8" { xfail { 
aarch64*-*-* && { any-opts "-flto" } } } } } */
+  fn1 (x); /* { dg-final { gdb-test .+2 "x" "98" { xfail { 
aarch64*-*-* && { any-opts "-Os" } } } } } */
+  if (x == 98) /* { dg-final { gdb-test .+1 "y" "117" { xfail { 
aarch64*-*-* && { any-opts "-Os" "-flto" } } } } } */
+   fn1 (x);/* { dg-final { gdb-test . "z" "8" { xfail { 
aarch64*-*-* && { any-opts "-Os" "-flto" } } } } } */
   fn1 (x);
   fn1 (x + a);
 }
diff --git a/gcc/testsuite/gcc.dg/guality/pr54519-3.c 
b/gcc/testsuite/gcc.dg/guality/pr54519-3.c
index fabab963d72..9c18993e7a9 100644
--- a/gcc/testsuite/gcc.dg/guality/pr54519-3.c
+++ b/gcc/testsuite/gcc.dg/guality/pr54519-3.c
@@ -18,9 +18,9 @@ fn2 (int x, int y, int z)
   fn1 (x); /* { dg-final { gdb-test .+2 "x" "36" } } */
   if (x == 36) /* { dg-final { gdb-test .+1 "y" "25" { xfail { 
aarch64*-*-* && { any-opts "-flto" } } } } } */
fn1 (x);/* { dg-final { gdb-test . "z" "6" { xfail { 
aarch64*-*-* && { any-opts "-flto" } } } } } */
-  fn1 (x); /* { dg-final { gdb-test .+2 "x" "98" } } */
-  if (x == 98) /* { dg-final { gdb-test .+1 "y" "117" { xfail { 
aarch64*-*-* && { any-opts "-flto" } } } } } */
-   fn1 (x);/* { dg-final { gdb-test . "z" "8" { xfail { 
aarch64*-*-* && { any-opts "-flto" } } } } } */
+  fn1 (x); /* { dg-final { gdb-test .+2 "x" "98" { xfail { 
aarch64*-*-* && { any-opts "-Os" } } } } } */
+  if (x == 98) /* { dg-final { gdb-test .+1 "y" "117" { xfail { 
aarch64*-*-* && { any-opts "-Os" "-flto" } } } } } */
+   fn1 (x);/* { dg-final { gdb-test . "z" "8" { xfail { 
aarch64*-*-* && { any-opts "-Os" "-flto" } } } } } */
   fn1 (x);
   fn1 (x + a);
 }
-- 
2.25.1

[pushed] testsuite: Remove TSVC XFAILs for SVE

[Richard Sandiford via Gcc-patches]

Many of the XFAILed TSVC tests pass for SVE.  This patch updates
the markup accordingly.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/testsuite/
* gcc.dg/vect/tsvc/vect-tsvc-s1115.c: Don't XFAIL for SVE.
* gcc.dg/vect/tsvc/vect-tsvc-s114.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s1161.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s1232.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s124.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s1279.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s161.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s253.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s257.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s271.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s2711.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s2712.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s272.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s273.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s274.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s276.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s278.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s279.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s3111.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s4113.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s441.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s443.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s491.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-vas.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-vif.c: Likewise.
---
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1115.c | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s114.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1161.c | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1232.c | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s124.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1279.c | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s161.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s253.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s257.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s271.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2711.c | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2712.c | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s272.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s273.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s274.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s276.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s278.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s279.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s3111.c | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s4113.c | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s441.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s443.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s491.c  | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-vas.c   | 2 +-
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-vif.c   | 2 +-
 25 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1115.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1115.c
index 1b2ff0cb4c4..18cb5ecb691 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1115.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1115.c
@@ -38,4 +38,4 @@ int main (int argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { xfail *-*-* } } } 
*/
+/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { xfail { ! 
aarch64_sve } } } } */
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s114.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s114.c
index fded659bacf..59e5041a622 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s114.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s114.c
@@ -39,4 +39,4 @@ int main (int argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { xfail *-*-* } } } 
*/
+/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { xfail { ! 
aarch64_sve } } } } */
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1161.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1161.c
index dfdeaf7fb48..28ce526da2a 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1161.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1161.c
@@ -45,4 +45,4 @@ int main (int argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { xfail *-*-* } } } 
*/
+/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { xfail { ! 
aarch64_sve }  } } } */
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1232.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1232.c
index cfa2e673d1e..347ed472234 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1232.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1232.c
@@ -38,4 +38,4 @@ int main (int argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { xfail *-*-* } } } 
*/
+/* { dg-final { scan-tre

[pushed] aarch64: Remove VALL_F16MOV iterator

[Richard Sandiford via Gcc-patches]

The VALL_F16MOV iterator now has the same modes as VALL_F16,
in the same order.  This patch removes the former in favour
of the latter.

This doesn't fix a bug as such, but it's ultra-safe (no change in
object code) and it saves a follow-up patch from having to make
a false choice between the iterators.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/
* config/aarch64/iterators.md (VALL_F16MOV): Delete.
* config/aarch64/aarch64-simd.md (mov): Use VALL_F16 instead
of VALL_F16MOV.
---
 gcc/config/aarch64/aarch64-simd.md | 4 ++--
 gcc/config/aarch64/iterators.md| 5 -
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index 13255be84fd..f6d7b42c289 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -19,8 +19,8 @@
 ;; .
 
 (define_expand "mov"
-  [(set (match_operand:VALL_F16MOV 0 "nonimmediate_operand")
-   (match_operand:VALL_F16MOV 1 "general_operand"))]
+  [(set (match_operand:VALL_F16 0 "nonimmediate_operand")
+   (match_operand:VALL_F16 1 "general_operand"))]
   "TARGET_SIMD"
   "
   /* Force the operand into a register if it is not an
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 9160ce3e69c..a0c02e4ac15 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -187,11 +187,6 @@ (define_mode_iterator VALL [V8QI V16QI V4HI V8HI V2SI V4SI 
V2DI V2SF V4SF V2DF])
 (define_mode_iterator VALL_F16 [V8QI V16QI V4HI V8HI V2SI V4SI V2DI
V4HF V8HF V4BF V8BF V2SF V4SF V2DF])
 
-;; All Advanced SIMD modes suitable for moving, loading, and storing,
-;; including special Bfloat vector types.
-(define_mode_iterator VALL_F16MOV [V8QI V16QI V4HI V8HI V2SI V4SI V2DI
-  V4HF V8HF V4BF V8BF V2SF V4SF V2DF])
-
 ;; The VALL_F16 modes except the 128-bit 2-element ones.
 (define_mode_iterator VALL_F16_NO_V2Q [V8QI V16QI V4HI V8HI V2SI V4SI
V4HF V8HF V2SF V4SF])
-- 
2.25.1

[pushed] aarch64: Add missing movmisalign patterns

[Richard Sandiford via Gcc-patches]

The Advanced SIMD movmisalign patterns didn't handle 16-bit
FP modes, which meant that the vector loop for:

  void
  test (_Float16 *data)
  {
_Pragma ("omp simd")
for (int i = 0; i < 8; ++i)
  data[i] = 1.0;
  }

would be versioned for alignment.

This was causing some new failures in aarch64/sve/single_5.c:

FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-not \\tb
FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-not \\tcmp
FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-times \\tstr\\tq[0-9]+, 
10

but I didn't look into what changed from earlier releases.
Adding the missing modes removes some existing xfails.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/
* config/aarch64/aarch64-simd.md (movmisalign): Extend from
VALL to VALL_F16.

gcc/testsuite/
* gcc.target/aarch64/sve/single_5.c: Remove some XFAILs.
---
 gcc/config/aarch64/aarch64-simd.md  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/single_5.c | 7 +++
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index f6d7b42c289..6646e069ad2 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -50,8 +50,8 @@ (define_expand "mov"
 )
 
 (define_expand "movmisalign"
-  [(set (match_operand:VALL 0 "nonimmediate_operand")
-(match_operand:VALL 1 "general_operand"))]
+  [(set (match_operand:VALL_F16 0 "nonimmediate_operand")
+(match_operand:VALL_F16 1 "general_operand"))]
   "TARGET_SIMD && !STRICT_ALIGNMENT"
 {
   /* This pattern is not permitted to fail during expansion: if both arguments
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/single_5.c 
b/gcc/testsuite/gcc.target/aarch64/sve/single_5.c
index 7d16205b28c..233118bbb38 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/single_5.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/single_5.c
@@ -13,15 +13,14 @@
 /* { dg-final { scan-assembler-times {\tmovi\tv[0-9]+\.4s, 0x6\n} 1 } } */
 /* { dg-final { scan-assembler-times {\tmov\tz[0-9]+\.d, #7\n} 1 { xfail *-*-* 
} } } */
 /* { dg-final { scan-assembler-times {\tmov\tz[0-9]+\.d, #8\n} 1 { xfail *-*-* 
} } } */
-/* { dg-final { scan-assembler-times {\tfmov\tv[0-9]+\.8h, 1\.0e\+0\n} 1 { 
xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tfmov\tv[0-9]+\.8h, 1\.0e\+0\n} 1 } } */
 /* { dg-final { scan-assembler-times {\tfmov\tv[0-9]+\.4s, 2\.0e\+0\n} 1 } } */
 /* { dg-final { scan-assembler-times {\tfmov\tv[0-9]+\.2d, 3\.0e\+0\n} 1 } } */
 
-/* { dg-final { scan-assembler-times {\tstr\tq[0-9]+,} 11 { xfail *-*-* } } } 
*/
-/* { dg-final { scan-assembler-times {\tstr\tq[0-9]+,} 10 } } */
+/* { dg-final { scan-assembler-times {\tstr\tq[0-9]+,} 11 } } */
 
 /* { dg-final { scan-assembler-not {\twhile} } } */
 /* { dg-final { scan-assembler-not {\tb} } } */
 /* { dg-final { scan-assembler-not {\tcmp} } } */
 /* { dg-final { scan-assembler-not {\tindex} } } */
-/* { dg-final { scan-assembler-not {\tptrue\t} { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not {\tptrue\t} } } */
-- 
2.25.1

[pushed] aarch64: Adjust tests after fix for PR102659

[Richard Sandiford via Gcc-patches]

After the fix for PR102659, the vectoriser can no longer group
conditional accesses of the form:

  for (int i = 0; i < n; ++i)
if (...)
  ...a[i * 2] + a[i * 2 + 1]...;

on LP64 targets.  It has to treat them as two independent
gathers instead.

This was causing failures in the sve mask_struct*.c tests.
The tests weren't really testing that int iterators could
be used, so this patch switches to pointer-sized iterators
instead.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/testsuite/
* gcc.target/aarch64/sve/mask_struct_load_1.c: Use intptr_t
iterators instead of int iterators.
* gcc.target/aarch64/sve/mask_struct_load_2.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_3.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_4.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_5.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_6.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_7.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_8.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_1.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_2.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_3.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_4.c: Likewise.
---
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_4.c  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_5.c  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_6.c  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_7.c  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_8.c  | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_1.c | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_2.c | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_3.c | 4 ++--
 gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_4.c | 6 +++---
 12 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c
index 03b2b93df07..450fbb887e3 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c
@@ -6,9 +6,9 @@
 #define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \
   void __attribute__ ((noinline, noclone)) \
   NAME##_2 (OUTTYPE *__restrict dest, INTYPE *__restrict src,  \
-   MASKTYPE *__restrict cond, int n)   \
+   MASKTYPE *__restrict cond, intptr_t n)  \
   {\
-for (int i = 0; i < n; ++i)\
+for (intptr_t i = 0; i < n; ++i)   \
   if (cond[i]) \
dest[i] = src[i * 2] + src[i * 2 + 1];  \
   }
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c 
b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c
index 87ac3178be0..499abd7c99a 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c
@@ -6,9 +6,9 @@
 #define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \
   void __attribute__ ((noinline, noclone)) \
   NAME##_3 (OUTTYPE *__restrict dest, INTYPE *__restrict src,  \
-   MASKTYPE *__restrict cond, int n)   \
+   MASKTYPE *__restrict cond, intptr_t n)  \
   {\
-for (int i = 0; i < n; ++i)\
+for (intptr_t i = 0; i < n; ++i)   \
   if (cond[i]) \
dest[i] = (src[i * 3]   \
   + src[i * 3 + 1] \
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c 
b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c
index 54806f93ad9..a5ce0716322 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c
@@ -6,9 +6,9 @@
 #define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \
   void __attribute__ ((noinline, noclone)) \
   NAME##_4 (OUTTYPE *__restrict dest, INTYPE *__restrict src,  \
-   MASKTYPE *__restrict cond, int n)   \
+   MASKTYPE *__restrict cond, intptr_t n)  \
   {\
-for (int i = 0; i < n; ++

[pushed] aarch64: Remove struct_vect_25.c XFAILs

[Richard Sandiford via Gcc-patches]

At some point we started generating the intended code for
aarch64/sve/struct_vect_25.c.  This patch removes the xfails
and the scan-assembler-times that replaced the xfailed forms.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/testsuite/
* gcc.target/aarch64/sve/struct_vect_25.c: Remove XFAILs.
---
 .../gcc.target/aarch64/sve/struct_vect_25.c| 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_25.c 
b/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_25.c
index bde6d04679c..bce4adca224 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_25.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_25.c
@@ -10,18 +10,12 @@
 /* { dg-final { scan-assembler-times {\tst3\t{v[0-9]+\.16b - v[0-9]+\.16b}, 
\[x[0-9]+\], #?48\n} 1 } } */
 /* { dg-final { scan-assembler-times {\tst4\t{v[0-9]+\.16b - v[0-9]+\.16b}, 
\[x[0-9]+\], #?64\n} 1 } } */
 
-/* { dg-final { scan-assembler-times {\tld2\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?32\n} 2 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tld3\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?48\n} 2 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tld4\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?64\n} 2 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tst2\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?32\n} 2 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tst3\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?48\n} 2 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tst4\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?64\n} 2 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tld2\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?32\n} 1 } } */
-/* { dg-final { scan-assembler-times {\tld3\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?48\n} 1 } } */
-/* { dg-final { scan-assembler-times {\tld4\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?64\n} 1 } } */
-/* { dg-final { scan-assembler-times {\tst2\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?32\n} 1 } } */
-/* { dg-final { scan-assembler-times {\tst3\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?48\n} 1 } } */
-/* { dg-final { scan-assembler-times {\tst4\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?64\n} 1 } } */
+/* { dg-final { scan-assembler-times {\tld2\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?32\n} 2 } } */
+/* { dg-final { scan-assembler-times {\tld3\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?48\n} 2 } } */
+/* { dg-final { scan-assembler-times {\tld4\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?64\n} 2 } } */
+/* { dg-final { scan-assembler-times {\tst2\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?32\n} 2 } } */
+/* { dg-final { scan-assembler-times {\tst3\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?48\n} 2 } } */
+/* { dg-final { scan-assembler-times {\tst4\t{v[0-9]+\.8h - v[0-9]+\.8h}, 
\[x[0-9]+\], #?64\n} 2 } } */
 
 /* { dg-final { scan-assembler-times {\tld2\t{v[0-9]+\.4s - v[0-9]+\.4s}, 
\[x[0-9]+\], #?32\n} 2 } } */
 /* { dg-final { scan-assembler-times {\tld3\t{v[0-9]+\.4s - v[0-9]+\.4s}, 
\[x[0-9]+\], #?48\n} 2 } } */
-- 
2.25.1

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Jakub Jelinek wrote:

> On Thu, Feb 03, 2022 at 10:40:10AM +0100, Richard Biener wrote:
> > Yes, we definitely have multiple of those cases.  I do think
> > preserving "an idiom", for example literal 0/0 or all x/0 might be
> > worth considering.  But I also think we have to sort out different
> > language standards requirements vs. the middle-end and whos
> > responsible for making sure we adhere here.
> 
> I think we try to preserve literal 0/0 and x/0, including this
> optimization which punts if the divisor is literal.  But, for literal
> 0/0 and x/0 we alsy emit -Wdiv-by-zero warning, maybe that was the
> reason why libgcc2.c did it differently.

Sure, I bet the code is quite old since we very likely propagate
the equality and optimize the division away since a long time.
Now that #pragma GCC diagnostic is a thing we can probably write
literal 0/0 if we choose to preserve that until the end.

But as said, for the libgcc2.c case I'd simply remove all of it.

Richard.

[PATCH] PR rtl-optimization/101885: Prevent combine from clobbering flags

[Roger Sayle]

This patch addresses PR rtl-optimization/101885 which is a P2 wrong code
regression.  In combine, if the resulting fused instruction is a parallel
of two sets which fails to be recognized by the backend, combine tries to
emit these as two sequential set instructions (known as split_i2i3).
As each set is recognized the backend may add any necessary "clobbers".
The code currently checks that any clobbers added to the first "set"
don't interfere with the second set, but doesn't currently handle the
case that clobbers added to the second set may interfere/kill the
destination of the first set (which must be live at this point).
The solution is to cut'n'paste the "clobber" logic from just a few
lines earlier, suitably adjusted for the second instruction.

One minor nit that may confuse a reviewer is that at this point in
the code we've lost track of which set was first and which was second
(combine chooses dynamically, and the recog processes that adds the
clobbers may have obfuscated the original SET_DEST) so the actual test
below is to confirm that any newly added clobbers (on the second set
instruction) don't overlap either set0's or set1's destination.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check with no new failures.  Ok for mainline?


2022-02-03  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/101885
* combine.c (try_combine): When splitting a parallel into two
sequential sets, check not only that the first doesn't clobber
the second but also that the second doesn't clobber the first.

gcc/testsuite/ChangeLog
PR rtl-optimization/101885
* gcc.dg/pr101885.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/combine.cc b/gcc/combine.cc
index 2d40635..38e0369 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -4017,6 +4017,23 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, 
rtx_insn *i0,
 
  insn_code_number = recog_for_combine (&newpat, i3, &new_i3_notes);
 
+ /* Likewise, recog_for_combine might have added clobbers to NEWPAT.
+Make sure NEWI2PAT2's original SET_DEST isn't clobbered.  */
+ if (insn_code_number >= 0 && GET_CODE (newpat) == PARALLEL)
+   {
+ for (i = XVECLEN (newpat, 0) - 1; i >= 0; i--)
+   if (GET_CODE (XVECEXP (newpat, 0, i)) == CLOBBER)
+ {
+   rtx reg = XEXP (XVECEXP (newpat, 0, i), 0);
+   if (reg_overlap_mentioned_p (reg, SET_DEST (set0))
+   || reg_overlap_mentioned_p (reg, SET_DEST (set1)))
+ {
+   undo_all ();
+   return 0;
+ }
+ }
+   }
+
  if (insn_code_number >= 0)
split_i2i3 = 1;
}
diff --git a/gcc/testsuite/gcc.dg/pr101885.c b/gcc/testsuite/gcc.dg/pr101885.c
new file mode 100644
index 000..05fd0ed
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101885.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O3" } */
+int a = 3, c;
+short b = 5, d, f;
+volatile short e;
+
+__attribute__((noipa)) void
+foo (void)
+{
+}
+
+int
+main ()
+{
+  for (f = 0; f != 2; f++)
+{
+  int g = a;
+  if (b)
+   if (a)
+ for (a = b = 0; b <= 3; b++)
+   ;
+  for (c = 0; c != 16; ++c)
+   e;
+}
+  b = d;
+  foo ();
+  if (a != 0)
+__builtin_abort ();
+  return 0;
+}
+

[PATCH v2] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[David Seifert via Gcc-patches]

* `-Werror` can cause issues when a more recent version of GCC compiles
  an older version:
  - https://bugs.gentoo.org/229059
  - https://bugs.gentoo.org/475350
  - https://bugs.gentoo.org/667104
---
 libatomic/configure.ac| 6 --
 libbacktrace/configure.ac | 7 ---
 libgo/configure.ac| 8 
 libgomp/configure.ac  | 6 --
 libitm/configure.ac   | 6 --
 libsanitizer/configure.ac | 9 +
 libsanitizer/libbacktrace/Makefile.am | 2 --
 7 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/libatomic/configure.ac b/libatomic/configure.ac
index f350b9b3509..c715d06fe8b 100644
--- a/libatomic/configure.ac
+++ b/libatomic/configure.ac
@@ -251,10 +251,12 @@ LIBAT_ENABLE_SYMVERS
 CFLAGS="$save_CFLAGS"
 AC_CACHE_SAVE
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 # Add CET specific flags if CET is enabled
 GCC_CET_FLAGS(CET_FLAGS)
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 0dfd82bc03e..f18de946597 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -145,10 +145,11 @@ ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwrite-strings 
-Wstrict-prototypes \
  -Wmissing-format-attribute -Wcast-qual],
  [WARN_FLAGS])
 
-if test -n "${with_target_subdir}"; then
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
+AS_IF([test "x$enable_werror" != "xno" && test -n "${with_target_subdir}"], [
   WARN_FLAGS="$WARN_FLAGS -Werror"
-fi
-
+])
 AC_SUBST(WARN_FLAGS)
 
 if test -n "${with_target_subdir}"; then
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 1f4f32dae2b..11dd9a7fc21 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -62,11 +62,11 @@ AC_PROG_AWK
 WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
 AC_SUBST(WARN_FLAGS)
 
-AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
-  [turns on -Werror @<:@default=yes@:>@])])
-if test "x$enable_werror" != "xno"; then
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   WERROR="-Werror"
-fi
+])
 AC_SUBST(WERROR)
 
 glibgo_toolexecdir=no
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index bfb613b91f0..9b77c8f44e8 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -121,10 +121,12 @@ AC_SUBST(CFLAGS)
 # in both places for now and restore CFLAGS at the end of config.
 save_CFLAGS="$CFLAGS"
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 # Find other programs we need.
 AC_CHECK_TOOL(AR, ar)
diff --git a/libitm/configure.ac b/libitm/configure.ac
index ac81b146845..616158f5c43 100644
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -261,10 +261,12 @@ GCC_CHECK_ELF_STYLE_WEAKREF
 CFLAGS="$save_CFLAGS"
 AC_CACHE_SAVE
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 XCFLAGS="$XCFLAGS $XPCFLAGS"
 
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index 13cd302030d..432f05d160a 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -400,6 +400,15 @@ fi
 AC_SUBST([TSAN_TARGET_DEPENDENT_OBJECTS])
 AC_SUBST([SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS])
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
+
+WARN_FLAGS="-Wextra -Wall -Wwrite-strings -Wmissing-format-attribute 
-Wcast-qual"
+AS_IF([test "x$enable_werror" != "xno"], [
+  WARN_FLAGS="$WARN_FLAGS -Werror"
+])
+AC_SUBST([WARN_FLAGS])
+
 # Determine what GCC version number to use in filesystem paths.
 GCC_BASE_VER
 
diff --git a/libsanitizer/libbacktrace/Makefile.am 
b/libsanitizer/libbacktrace/Makefile.am
index 16accd468df..0cf8d2104c0 100644
--- a/libsanitizer/libbacktrace/Makefile.am
+++ b/libsanitizer/libbacktrace/Makefile.am
@@ -34,8 +34,6 @@ ACLOCAL_AMFLAGS = -I ../.. -I ../../config
 AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \
-I ../../libgcc -I .. -I $(top_srcdir) -I $(top_srcdir)/../libbacktrace
 
-WARN_FLAGS = -W -Wall -Wwrite-strings -Wmissing-format-attribute \
--Wcast-qual -Werror
 C_WARN_FLAGS = $(WARN_FLAGS)

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 12:03:15PM +0100, Richard Biener wrote:
> But as said, for the libgcc2.c case I'd simply remove all of it.

I can't read RMS' mind, it is indeed UB, so we can do anything, but I bet
it was just a QoI attempt, when (most of the time) normal single-word
or smaller division for / 0 behaves certain way (SIGFPE with FPE_INTDIV,
or being ignored, or whatever else) that it would be nice if the multi-word
division behaved likewise.
On the platforms where it is SIGFPE with FPE_INTDIV, raising that would
help people figure out what's going on.

Jakub

Re: [PATCH v2] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[Jonathan Wakely via Gcc-patches]

On 03/02/22 12:08 +0100, David Seifert wrote:

* `-Werror` can cause issues when a more recent version of GCC compiles
 an older version:
 - https://bugs.gentoo.org/229059
 - https://bugs.gentoo.org/475350
 - https://bugs.gentoo.org/667104


Honouring --disable-werror everywhere seems reasonable to me (but I
can't approve it).

It will need a ChangeLog in the Git commit message, of the form:

libatomic/ChangeLog:

* libatomic/configure.ac: Support --disable-werror.
* libatomic/configure: Regenerate.

libbacktrace/ChangeLog:

* libbacktrace/configure.ac: Support --disable-werror.
* libbacktrace/configure: Regenerate.

libgo/ChangeLog:

* libgo/configure.ac: Support --disable-werror.
* libgo/configure: Regenerate.

libgomp/ChangeLog:

* libgomp/configure.ac: Support --disable-werror.
* libgomp/configure: Regenerate.

libitm/ChangeLog:

* libitm/configure.ac: Support --disable-werror.
* libitm/configure: Regenerate.

libsanitizer/ChangeLog:

* libsanitizer/configure.ac: Support --disable-werror.
* libsanitizer/libbacktrace/Makefile.am (WARN_FLAGS): Remove.


And if you don't have an FSF assignment on file for GCC, you can
contribute it under the terms of https://gcc.gnu.org/dco.html (and if
you want to do that, please add the Signed-off-by: tag to indicate
you've understood those terms and agreed to them).


Is the hunk below removing the warning flags so that they use the ones
from the parent directory?


diff --git a/libsanitizer/libbacktrace/Makefile.am 
b/libsanitizer/libbacktrace/Makefile.am
index 16accd468df..0cf8d2104c0 100644
--- a/libsanitizer/libbacktrace/Makefile.am
+++ b/libsanitizer/libbacktrace/Makefile.am
@@ -34,8 +34,6 @@ ACLOCAL_AMFLAGS = -I ../.. -I ../../config
AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \
-I ../../libgcc -I .. -I $(top_srcdir) -I $(top_srcdir)/../libbacktrace

-WARN_FLAGS = -W -Wall -Wwrite-strings -Wmissing-format-attribute \
--Wcast-qual -Werror
C_WARN_FLAGS = $(WARN_FLAGS) -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition
CXX_WARN_FLAGS = $(WARN_FLAGS) -Wno-unused-parameter
AM_CFLAGS = $(C_WARN_FLAGS)

Re: [PATCH v2] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[David Seifert via Gcc-patches]

On Thu, 2022-02-03 at 11:23 +, Jonathan Wakely wrote:
> On 03/02/22 12:08 +0100, David Seifert wrote:
> > * `-Werror` can cause issues when a more recent version of GCC
> > compiles
> >  an older version:
> >  - https://bugs.gentoo.org/229059
> >  - https://bugs.gentoo.org/475350
> >  - https://bugs.gentoo.org/667104
> 
> Honouring --disable-werror everywhere seems reasonable to me (but I
> can't approve it).
> 
> It will need a ChangeLog in the Git commit message, of the form:
> 
> libatomic/ChangeLog:
> 
> * libatomic/configure.ac: Support --disable-werror.
> * libatomic/configure: Regenerate.
> 
> libbacktrace/ChangeLog:
> 
> * libbacktrace/configure.ac: Support --disable-werror.
> * libbacktrace/configure: Regenerate.
> 
> libgo/ChangeLog:
> 
> * libgo/configure.ac: Support --disable-werror.
> * libgo/configure: Regenerate.
> 
> libgomp/ChangeLog:
> 
> * libgomp/configure.ac: Support --disable-werror.
> * libgomp/configure: Regenerate.
> 
> libitm/ChangeLog:
> 
> * libitm/configure.ac: Support --disable-werror.
> * libitm/configure: Regenerate.
> 
> libsanitizer/ChangeLog:
> 
> * libsanitizer/configure.ac: Support --disable-werror.
> * libsanitizer/libbacktrace/Makefile.am (WARN_FLAGS): Remove.
> 
> 
> And if you don't have an FSF assignment on file for GCC, you can
> contribute it under the terms of https://gcc.gnu.org/dco.html (and if
> you want to do that, please add the Signed-off-by: tag to indicate
> you've understood those terms and agreed to them).
> 
> 
> Is the hunk below removing the warning flags so that they use the ones
> from the parent directory?

correct

> > diff --git a/libsanitizer/libbacktrace/Makefile.am
> > b/libsanitizer/libbacktrace/Makefile.am
> > index 16accd468df..0cf8d2104c0 100644
> > --- a/libsanitizer/libbacktrace/Makefile.am
> > +++ b/libsanitizer/libbacktrace/Makefile.am
> > @@ -34,8 +34,6 @@ ACLOCAL_AMFLAGS = -I ../.. -I ../../config
> > AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc
> > \
> > -I ../../libgcc -I .. -I $(top_srcdir) -I
> > $(top_srcdir)/../libbacktrace
> > 
> > -WARN_FLAGS = -W -Wall -Wwrite-strings -Wmissing-format-attribute \
> > -    -Wcast-qual -Werror
> > C_WARN_FLAGS = $(WARN_FLAGS) -Wstrict-prototypes -Wmissing-
> > prototypes -Wold-style-definition
> > CXX_WARN_FLAGS = $(WARN_FLAGS) -Wno-unused-parameter
> > AM_CFLAGS = $(C_WARN_FLAGS)
> 

[PATCH v3] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[David Seifert via Gcc-patches]

* `-Werror` can cause issues when a more recent version of GCC compiles
  an older version:
  - https://bugs.gentoo.org/229059
  - https://bugs.gentoo.org/475350
  - https://bugs.gentoo.org/667104

libatomic/ChangeLog:

* libatomic/configure.ac: Support --disable-werror.
* libatomic/configure: Regenerate.

libbacktrace/ChangeLog:

* libbacktrace/configure.ac: Support --disable-werror.
* libbacktrace/configure: Regenerate.

libgo/ChangeLog:

* libgo/configure.ac: Support --disable-werror.
* libgo/configure: Regenerate.

libgomp/ChangeLog:

* libgomp/configure.ac: Support --disable-werror.
* libgomp/configure: Regenerate.

libitm/ChangeLog:

* libitm/configure.ac: Support --disable-werror.
* libitm/configure: Regenerate.

libsanitizer/ChangeLog:

* libsanitizer/configure.ac: Support --disable-werror.
* libsanitizer/libbacktrace/Makefile.am (WARN_FLAGS): Remove.
---
 libatomic/configure.ac| 6 --
 libbacktrace/configure.ac | 7 ---
 libgo/configure.ac| 8 
 libgomp/configure.ac  | 6 --
 libitm/configure.ac   | 6 --
 libsanitizer/configure.ac | 9 +
 libsanitizer/libbacktrace/Makefile.am | 2 --
 7 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/libatomic/configure.ac b/libatomic/configure.ac
index f350b9b3509..c715d06fe8b 100644
--- a/libatomic/configure.ac
+++ b/libatomic/configure.ac
@@ -251,10 +251,12 @@ LIBAT_ENABLE_SYMVERS
 CFLAGS="$save_CFLAGS"
 AC_CACHE_SAVE
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 # Add CET specific flags if CET is enabled
 GCC_CET_FLAGS(CET_FLAGS)
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 0dfd82bc03e..f18de946597 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -145,10 +145,11 @@ ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwrite-strings 
-Wstrict-prototypes \
  -Wmissing-format-attribute -Wcast-qual],
  [WARN_FLAGS])
 
-if test -n "${with_target_subdir}"; then
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
+AS_IF([test "x$enable_werror" != "xno" && test -n "${with_target_subdir}"], [
   WARN_FLAGS="$WARN_FLAGS -Werror"
-fi
-
+])
 AC_SUBST(WARN_FLAGS)
 
 if test -n "${with_target_subdir}"; then
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 1f4f32dae2b..11dd9a7fc21 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -62,11 +62,11 @@ AC_PROG_AWK
 WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
 AC_SUBST(WARN_FLAGS)
 
-AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
-  [turns on -Werror @<:@default=yes@:>@])])
-if test "x$enable_werror" != "xno"; then
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   WERROR="-Werror"
-fi
+])
 AC_SUBST(WERROR)
 
 glibgo_toolexecdir=no
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index bfb613b91f0..9b77c8f44e8 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -121,10 +121,12 @@ AC_SUBST(CFLAGS)
 # in both places for now and restore CFLAGS at the end of config.
 save_CFLAGS="$CFLAGS"
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 # Find other programs we need.
 AC_CHECK_TOOL(AR, ar)
diff --git a/libitm/configure.ac b/libitm/configure.ac
index ac81b146845..616158f5c43 100644
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -261,10 +261,12 @@ GCC_CHECK_ELF_STYLE_WEAKREF
 CFLAGS="$save_CFLAGS"
 AC_CACHE_SAVE
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 XCFLAGS="$XCFLAGS $XPCFLAGS"
 
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index 13cd302030d..432f05d160a 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -400,6 +400,15 @@ fi
 AC_SUBST([TSAN_TARGET_DEPENDENT_OBJECTS])
 AC_SUBST([SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS])
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
+
+WARN_FLAGS="-Wextra -Wall -Wwrite-strings -Wmissing-format-attribu

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Richard Biener via Gcc-patches]

On Wed, 2 Feb 2022, Michael Matz wrote:

> Hello,
> 
> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
> 
> > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this 
> > marks the end-of-life of storage as opposed to just ending the lifetime 
> > of the object that occupied it. The dangling pointer diagnostics uses 
> > CLOBBERs but is confused by those emitted by the C++ frontend for 
> > example which emits them for the second purpose at the start of CTORs.  
> > The issue is also appearant for aarch64 in PR104092.
> > 
> > Distinguishing the two cases is also necessary for the PR90348 fix.
> 
> (Just FWIW: I agree with the plan to have different types of CLOBBERs, in 
> particular those for marking births)
> 
> A style nit:
> 
> >   tree clobber = build_clobber (TREE_TYPE (t));
> > + CLOBBER_MARKS_EOL (clobber) = 1;
> 
> I think it really were better if build_clobber() gained an additional 
> argument (non-optional!) that sets the type of it.

It indeed did occur to me as well, so as we're two now I tried to see
how it looks like.  It does like the following (didn't bother to
replace all build_clobber calls but defaulted the parameter - there
are too many).  With CLOBBER_BIRTH added for the fix for PR90348
the enum would be constructed like

#define CLOBBER_KIND(NODE) \
  ((clobber_kind) (CONSTRUCTOR_CHECK (NODE)->base.private_flag << 1
   | CONSTRUCTOR_CHECK (NODE)->base.protected_flag))

or so (maybe different dependent on bitfield endianess to make
extracting the two adjacent bits cheap).  That would leave us space
for a fourth state.

So do you think that makes it nicer?  What do others think?

Thanks,
Richard.


-- 

>From a06a7b8f8ffbd6b3b0f77f9dfbbea1822f39b714 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Wed, 2 Feb 2022 14:24:39 +0100
Subject: [PATCH] Add CLOBBER_EOL to mark storage end-of-life clobbers
To: gcc-patches@gcc.gnu.org

This adds a flag to CONSTRUCTOR nodes indicating that for
clobbers this marks the end-of-life of storage as opposed to
just ending the lifetime of the object that occupied it.
The dangling pointer diagnostics uses CLOBBERs but is confused
by those emitted by the C++ frontend for example which emits
them for the second purpose at the start of CTORs.  The issue
is also appearant for aarch64 in PR104092.

Distinguishing the two cases is also necessary for the PR90348 fix.

Since I'm going to add another flag I added an enum clobber_flags
and a defaulted argument to build_clobber plus a convenient way to
query the enum from the CTOR tree and specify it for gimple_clobber_p.
Since 'CLOBBER' is already taken and I needed a name for the unspecified
clobber we have now I used 'CLOBBER_UNDEF'.

2022-02-03  Richard Biener  

PR middle-end/90348
PR middle-end/104092
* tree-core.h: Document protected_flag use on CONSTRUCTOR nodes.
* tree.h (clobber_kind): New enum.
(CLOBBER_KIND): Add.
(build_clobber): Add clobber kind argument, defaulted to
CLOBBER_UNDEF.
* gimple.h (gimple_clobber_p): New overload with specified kind.
* tree-pretty-print.cc (dump_generic_node): Mark EOL CLOBBERs.
* gimplify.c (gimplify_bind_expr): Build storage end-of-life clobbers
with CLOBBER_EOL.
(gimplify_target_expr): Likewise.
* tree-inline.cc (expand_call_inline): Likewise.
* tree-ssa-ccp.cc (insert_clobber_before_stack_restore): Likewise.
* gimple-ssa-warn-access.cc (pass_waccess::check_stmt): Only treat
CLOBBER_EOL clobbers as ending lifetime of storage.

* gcc.dg/pr87052.c: Adjust.
---
 gcc/gimple-ssa-warn-access.cc  | 3 ++-
 gcc/gimple.h   | 9 +
 gcc/gimplify.cc| 4 ++--
 gcc/testsuite/gcc.dg/pr87052.c | 2 +-
 gcc/tree-core.h| 3 +++
 gcc/tree-inline.cc | 4 ++--
 gcc/tree-pretty-print.cc   | 6 +-
 gcc/tree-ssa-ccp.cc| 2 +-
 gcc/tree.cc| 9 -
 gcc/tree.h | 9 -
 10 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index ad5e2f4458e..2559ad1506a 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -4330,7 +4330,8 @@ is_auto_decl (tree x)
 void
 pass_waccess::check_stmt (gimple *stmt)
 {
-  if (m_check_dangling_p && gimple_clobber_p (stmt))
+  if (m_check_dangling_p
+  && gimple_clobber_p (stmt, CLOBBER_EOL))
 {
   /* Ignore clobber statemts in blocks with exceptional edges.  */
   basic_block bb = gimple_bb (stmt);
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 441d29a109a..77a5a07e9b5 100644
--- a/gcc/gimple.h
+++ b/gcc/gimple.h
@@ -2939,6 +2939,15 @@ gimple_clobber_p (const gimple *s)
  && TREE_CLOBBER_P (gimple_assign_rhs1 (s));
 }
 
+/* Return true if S is a clobber statement.  */
+
+static inline bool
+gimple_clobber_p (const gimple *s

Re: [PATCH v3] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> * `-Werror` can cause issues when a more recent version of GCC compiles
>   an older version:
>   - https://bugs.gentoo.org/229059
>   - https://bugs.gentoo.org/475350
>   - https://bugs.gentoo.org/667104
> 
> libatomic/ChangeLog:
> 
> * libatomic/configure.ac: Support --disable-werror.
> * libatomic/configure: Regenerate.
> 
> libbacktrace/ChangeLog:
> 
> * libbacktrace/configure.ac: Support --disable-werror.
> * libbacktrace/configure: Regenerate.
> 
> libgo/ChangeLog:
> 
> * libgo/configure.ac: Support --disable-werror.
> * libgo/configure: Regenerate.
> 
> libgomp/ChangeLog:
> 
> * libgomp/configure.ac: Support --disable-werror.
> * libgomp/configure: Regenerate.
> 
> libitm/ChangeLog:
> 
> * libitm/configure.ac: Support --disable-werror.
> * libitm/configure: Regenerate.
> 
> libsanitizer/ChangeLog:
> 
> * libsanitizer/configure.ac: Support --disable-werror.
> * libsanitizer/libbacktrace/Makefile.am (WARN_FLAGS): Remove.

As Jonathan wrote, if you don't have a copyright assignment on file,
we need either that copyright assignment or the patch needs to be
submitted according to https://gcc.gnu.org/dco.html which is
expressed by Signed-off-by line in the mail and commit message.

> --- a/libsanitizer/configure.ac
> +++ b/libsanitizer/configure.ac
> @@ -400,6 +400,15 @@ fi
>  AC_SUBST([TSAN_TARGET_DEPENDENT_OBJECTS])
>  AC_SUBST([SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS])
>  
> +AC_ARG_ENABLE([werror], [
> +  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
> +
> +WARN_FLAGS="-Wextra -Wall -Wwrite-strings -Wmissing-format-attribute 
> -Wcast-qual"

This should be using
ACX_PROG_CC_WARNING_OPTS([-Wextra -Wall -Wwrite-strings \
  -Wmissing-format-attribute -Wcast-qual],
  [WARN_FLAGS])
instead.

Otherwise LGTM.

Jakub

Re: [PATCH v3] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[David Seifert via Gcc-patches]

On Thu, 2022-02-03 at 12:50 +0100, Jakub Jelinek wrote:
> On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> > * `-Werror` can cause issues when a more recent version of GCC
> > compiles
> >   an older version:
> >   - https://bugs.gentoo.org/229059
> >   - https://bugs.gentoo.org/475350
> >   - https://bugs.gentoo.org/667104
> > 
> > libatomic/ChangeLog:
> > 
> >     * libatomic/configure.ac: Support --disable-werror.
> >     * libatomic/configure: Regenerate.
> > 
> > libbacktrace/ChangeLog:
> > 
> >     * libbacktrace/configure.ac: Support --disable-werror.
> >     * libbacktrace/configure: Regenerate.
> > 
> > libgo/ChangeLog:
> > 
> >     * libgo/configure.ac: Support --disable-werror.
> >     * libgo/configure: Regenerate.
> > 
> > libgomp/ChangeLog:
> > 
> >     * libgomp/configure.ac: Support --disable-werror.
> >     * libgomp/configure: Regenerate.
> > 
> > libitm/ChangeLog:
> > 
> >     * libitm/configure.ac: Support --disable-werror.
> >     * libitm/configure: Regenerate.
> > 
> > libsanitizer/ChangeLog:
> > 
> >     * libsanitizer/configure.ac: Support --disable-werror.
> >     * libsanitizer/libbacktrace/Makefile.am (WARN_FLAGS):
> > Remove.
> 
> As Jonathan wrote, if you don't have a copyright assignment on file,
> we need either that copyright assignment or the patch needs to be
> submitted according to https://gcc.gnu.org/dco.html which is
> expressed by Signed-off-by line in the mail and commit message.
> 

I have an FSF copyright assignment, is there anything you need me to do
to this end?

> > --- a/libsanitizer/configure.ac
> > +++ b/libsanitizer/configure.ac
> > @@ -400,6 +400,15 @@ fi
> >  AC_SUBST([TSAN_TARGET_DEPENDENT_OBJECTS])
> >  AC_SUBST([SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS])
> >  
> > +AC_ARG_ENABLE([werror], [
> > +  AS_HELP_STRING([--disable-werror], [disable building with -
> > Werror])])
> > +
> > +WARN_FLAGS="-Wextra -Wall -Wwrite-strings -Wmissing-format-
> > attribute -Wcast-qual"
> 
> This should be using
> ACX_PROG_CC_WARNING_OPTS([-Wextra -Wall -Wwrite-strings \
>   -Wmissing-format-attribute -Wcast-qual],
>   [WARN_FLAGS])
> instead.
> 
> Otherwise LGTM.
> 
> Jakub
> 

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Richard Sandiford via Gcc-patches]

Richard Biener  writes:
> On Wed, 2 Feb 2022, Michael Matz wrote:
>
>> Hello,
>> 
>> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
>> 
>> > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this 
>> > marks the end-of-life of storage as opposed to just ending the lifetime 
>> > of the object that occupied it. The dangling pointer diagnostics uses 
>> > CLOBBERs but is confused by those emitted by the C++ frontend for 
>> > example which emits them for the second purpose at the start of CTORs.  
>> > The issue is also appearant for aarch64 in PR104092.
>> > 
>> > Distinguishing the two cases is also necessary for the PR90348 fix.
>> 
>> (Just FWIW: I agree with the plan to have different types of CLOBBERs, in 
>> particular those for marking births)
>> 
>> A style nit:
>> 
>> >  tree clobber = build_clobber (TREE_TYPE (t));
>> > +CLOBBER_MARKS_EOL (clobber) = 1;
>> 
>> I think it really were better if build_clobber() gained an additional 
>> argument (non-optional!) that sets the type of it.
>
> It indeed did occur to me as well, so as we're two now I tried to see
> how it looks like.  It does like the following (didn't bother to
> replace all build_clobber calls but defaulted the parameter - there
> are too many).  With CLOBBER_BIRTH added for the fix for PR90348
> the enum would be constructed like
>
> #define CLOBBER_KIND(NODE) \
>   ((clobber_kind) (CONSTRUCTOR_CHECK (NODE)->base.private_flag << 1
>| CONSTRUCTOR_CHECK (NODE)->base.protected_flag))
>
> or so (maybe different dependent on bitfield endianess to make
> extracting the two adjacent bits cheap).  That would leave us space
> for a fourth state.
>
> So do you think that makes it nicer?  What do others think?

This way looks cleaner to me FWIW.

Which arm of tree_base::u do constructors use?  If we need a 2-bit
enum then maybe we can carve one out from there.

Thanks,
Richard

Re: [PATCH v3] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 12:59:43PM +0100, David Seifert wrote:
> I have an FSF copyright assignment, is there anything you need me to do
> to this end?

Ok.

> > > --- a/libsanitizer/configure.ac
> > > +++ b/libsanitizer/configure.ac
> > > @@ -400,6 +400,15 @@ fi
> > >  AC_SUBST([TSAN_TARGET_DEPENDENT_OBJECTS])
> > >  AC_SUBST([SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS])
> > >  
> > > +AC_ARG_ENABLE([werror], [
> > > +  AS_HELP_STRING([--disable-werror], [disable building with -
> > > Werror])])
> > > +
> > > +WARN_FLAGS="-Wextra -Wall -Wwrite-strings -Wmissing-format-
> > > attribute -Wcast-qual"
> > 
> > This should be using
> > ACX_PROG_CC_WARNING_OPTS([-Wextra -Wall -Wwrite-strings \
> >   -Wmissing-format-attribute -Wcast-qual],
> >   [WARN_FLAGS])
> > instead.

Then just this change and a note where and how it has been tested,
I can commit it afterwards for you.

Jakub

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Richard Sandiford wrote:

> Richard Biener  writes:
> > On Wed, 2 Feb 2022, Michael Matz wrote:
> >
> >> Hello,
> >> 
> >> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
> >> 
> >> > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this 
> >> > marks the end-of-life of storage as opposed to just ending the lifetime 
> >> > of the object that occupied it. The dangling pointer diagnostics uses 
> >> > CLOBBERs but is confused by those emitted by the C++ frontend for 
> >> > example which emits them for the second purpose at the start of CTORs.  
> >> > The issue is also appearant for aarch64 in PR104092.
> >> > 
> >> > Distinguishing the two cases is also necessary for the PR90348 fix.
> >> 
> >> (Just FWIW: I agree with the plan to have different types of CLOBBERs, in 
> >> particular those for marking births)
> >> 
> >> A style nit:
> >> 
> >> >tree clobber = build_clobber (TREE_TYPE (t));
> >> > +  CLOBBER_MARKS_EOL (clobber) = 1;
> >> 
> >> I think it really were better if build_clobber() gained an additional 
> >> argument (non-optional!) that sets the type of it.
> >
> > It indeed did occur to me as well, so as we're two now I tried to see
> > how it looks like.  It does like the following (didn't bother to
> > replace all build_clobber calls but defaulted the parameter - there
> > are too many).  With CLOBBER_BIRTH added for the fix for PR90348
> > the enum would be constructed like
> >
> > #define CLOBBER_KIND(NODE) \
> >   ((clobber_kind) (CONSTRUCTOR_CHECK (NODE)->base.private_flag << 1
> >| CONSTRUCTOR_CHECK (NODE)->base.protected_flag))
> >
> > or so (maybe different dependent on bitfield endianess to make
> > extracting the two adjacent bits cheap).  That would leave us space
> > for a fourth state.
> >
> > So do you think that makes it nicer?  What do others think?
> 
> This way looks cleaner to me FWIW.
> 
> Which arm of tree_base::u do constructors use?  If we need a 2-bit
> enum then maybe we can carve one out from there.

constructors are tcc_exceptional but since they are used where
tree operands reside they need to be compatible to EXPR_P and
thus various things like TREE_SIDE_EFFECTS need to work.

Which means, we can't.

Richard.

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Jakub Jelinek wrote:

> On Thu, Feb 03, 2022 at 12:03:15PM +0100, Richard Biener wrote:
> > But as said, for the libgcc2.c case I'd simply remove all of it.
> 
> I can't read RMS' mind, it is indeed UB, so we can do anything, but I bet
> it was just a QoI attempt, when (most of the time) normal single-word
> or smaller division for / 0 behaves certain way (SIGFPE with FPE_INTDIV,
> or being ignored, or whatever else) that it would be nice if the multi-word
> division behaved likewise.
> On the platforms where it is SIGFPE with FPE_INTDIV, raising that would
> help people figure out what's going on.

Yes, I think the intent is clear.  The question is whether we should
re-instantiate the clear intent of preserving a literal / 0 as well
(for C, without -fnon-call-exceptions).

That said, I'm fine with the asms but they are ugly ;)

Richard.

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Richard Sandiford via Gcc-patches]

Richard Biener  writes:
> On Thu, 3 Feb 2022, Richard Sandiford wrote:
>
>> Richard Biener  writes:
>> > On Wed, 2 Feb 2022, Michael Matz wrote:
>> >
>> >> Hello,
>> >> 
>> >> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
>> >> 
>> >> > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this 
>> >> > marks the end-of-life of storage as opposed to just ending the lifetime 
>> >> > of the object that occupied it. The dangling pointer diagnostics uses 
>> >> > CLOBBERs but is confused by those emitted by the C++ frontend for 
>> >> > example which emits them for the second purpose at the start of CTORs.  
>> >> > The issue is also appearant for aarch64 in PR104092.
>> >> > 
>> >> > Distinguishing the two cases is also necessary for the PR90348 fix.
>> >> 
>> >> (Just FWIW: I agree with the plan to have different types of CLOBBERs, in 
>> >> particular those for marking births)
>> >> 
>> >> A style nit:
>> >> 
>> >> >   tree clobber = build_clobber (TREE_TYPE (t));
>> >> > + CLOBBER_MARKS_EOL (clobber) = 1;
>> >> 
>> >> I think it really were better if build_clobber() gained an additional 
>> >> argument (non-optional!) that sets the type of it.
>> >
>> > It indeed did occur to me as well, so as we're two now I tried to see
>> > how it looks like.  It does like the following (didn't bother to
>> > replace all build_clobber calls but defaulted the parameter - there
>> > are too many).  With CLOBBER_BIRTH added for the fix for PR90348
>> > the enum would be constructed like
>> >
>> > #define CLOBBER_KIND(NODE) \
>> >   ((clobber_kind) (CONSTRUCTOR_CHECK (NODE)->base.private_flag << 1
>> >| CONSTRUCTOR_CHECK (NODE)->base.protected_flag))
>> >
>> > or so (maybe different dependent on bitfield endianess to make
>> > extracting the two adjacent bits cheap).  That would leave us space
>> > for a fourth state.
>> >
>> > So do you think that makes it nicer?  What do others think?
>> 
>> This way looks cleaner to me FWIW.
>> 
>> Which arm of tree_base::u do constructors use?  If we need a 2-bit
>> enum then maybe we can carve one out from there.
>
> constructors are tcc_exceptional but since they are used where
> tree operands reside they need to be compatible to EXPR_P and
> thus various things like TREE_SIDE_EFFECTS need to work.
>
> Which means, we can't.

But TREE_SIDE_EFFECTS is part of the main set of flags.  For tree_base::u
we have:

  union {
/* The bits in the following structure should only be used with
   accessor macros that constrain inputs with tree checking.  */
struct {
  unsigned lang_flag_0 : 1;
  unsigned lang_flag_1 : 1;
  unsigned lang_flag_2 : 1;
  unsigned lang_flag_3 : 1;
  unsigned lang_flag_4 : 1;
  unsigned lang_flag_5 : 1;
  unsigned lang_flag_6 : 1;
  unsigned saturating_flag : 1;

  unsigned unsigned_flag : 1;
  unsigned packed_flag : 1;
  unsigned user_align : 1;
  unsigned nameless_flag : 1;
  unsigned atomic_flag : 1;
  unsigned unavailable_flag : 1;
  unsigned spare0 : 2;

  unsigned spare1 : 8;

  /* This field is only used with TREE_TYPE nodes; the only reason it is
 present in tree_base instead of tree_type is to save space.  The size
 of the field must be large enough to hold addr_space_t values.  */
  unsigned address_space : 8;
} bits;

/* The following fields are present in tree_base to save space.  The
   nodes using them do not require any of the flags above and so can
   make better use of the 4-byte sized word.  */

/* The number of HOST_WIDE_INTs in an INTEGER_CST.  */
struct {
  /* The number of HOST_WIDE_INTs if the INTEGER_CST is accessed in
 its native precision.  */
  unsigned char unextended;

  /* The number of HOST_WIDE_INTs if the INTEGER_CST is extended to
 wider precisions based on its TYPE_SIGN.  */
  unsigned char extended;

  /* The number of HOST_WIDE_INTs if the INTEGER_CST is accessed in
 offset_int precision, with smaller integers being extended
 according to their TYPE_SIGN.  This is equal to one of the two
 fields above but is cached for speed.  */
  unsigned char offset;
} int_length;

/* VEC length.  This field is only used with TREE_VEC.  */
int length;

/* This field is only used with VECTOR_CST.  */
struct {
  /* The value of VECTOR_CST_LOG2_NPATTERNS.  */
  unsigned int log2_npatterns : 8;

  /* The value of VECTOR_CST_NELTS_PER_PATTERN.  */
  unsigned int nelts_per_pattern : 8;

  /* For future expansion.  */
  unsigned int unused : 16;
} vector_cst;

/* SSA version number.  This field is only used with SSA_NAME.  */
unsigned int version;

/* CHREC_VARIABLE.  This field is only used with POLYNOMIAL_CHREC.  */
unsigned int chrec_var;

/* Internal function code.  */
enum internal_fn ifn;

/* OMP_ATOMIC* memory order.  *

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 01:13:29PM +0100, Richard Biener wrote:
> On Thu, 3 Feb 2022, Jakub Jelinek wrote:
> 
> > On Thu, Feb 03, 2022 at 12:03:15PM +0100, Richard Biener wrote:
> > > But as said, for the libgcc2.c case I'd simply remove all of it.
> > 
> > I can't read RMS' mind, it is indeed UB, so we can do anything, but I bet
> > it was just a QoI attempt, when (most of the time) normal single-word
> > or smaller division for / 0 behaves certain way (SIGFPE with FPE_INTDIV,
> > or being ignored, or whatever else) that it would be nice if the multi-word
> > division behaved likewise.
> > On the platforms where it is SIGFPE with FPE_INTDIV, raising that would
> > help people figure out what's going on.
> 
> Yes, I think the intent is clear.  The question is whether we should
> re-instantiate the clear intent of preserving a literal / 0 as well
> (for C, without -fnon-call-exceptions).

I think currently it is path isolation that breaks it.
Bet in a good intent that everything after it is UB and allowing the
stmts after it to be optimized away.
Unfortunately we don't (easily) know whether the division by zero
was literal already in the source or propagated through inlining etc.
or even jump threading.  Especially in the last case it is nice to
be able to emit as short code as possible, which __builtin_trap ()
serves nicely on many targets.
Emitting both a 1 / 0 insn followed by __builtin_trap () might work
with perhaps some RTL optimization to optimize away the trap if
the target is known to trap on division by zero.

Jakub

Re: [PATCH] match.pd: Fix up 1 / X for unsigned X optimization [PR104280]

[Eric Botcazou via Gcc-patches]

> Yes, I think the intent is clear.  The question is whether we should
> re-instantiate the clear intent of preserving a literal / 0 as well
> (for C, without -fnon-call-exceptions).

Note that the code is precisely compiled with -fnon-call-exceptions:

ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),)
# Provide default flags for compiling divmod functions, if they haven't been
# set already by a target-specific Makefile fragment.
LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions
endif

# Build LIB2_DIVMOD_FUNCS.
lib2-divmod-o = $(patsubst %,%$(objext),$(LIB2_DIVMOD_FUNCS))
$(lib2-divmod-o): %$(objext): $(srcdir)/libgcc2.c
$(gcc_compile) -DL$* -c $< \
  $(LIB2_DIVMOD_EXCEPTION_FLAGS) $(vis_hide)
libgcc-objects += $(lib2-divmod-o)

ifeq ($(enable_shared),yes)
lib2-divmod-s-o = $(patsubst %,%_s$(objext),$(LIB2_DIVMOD_FUNCS))
$(lib2-divmod-s-o): %_s$(objext): $(srcdir)/libgcc2.c
$(gcc_s_compile) -DL$* -c $< \
  $(LIB2_DIVMOD_EXCEPTION_FLAGS)
libgcc-s-objects += $(lib2-divmod-s-o)
endif

so it seems like we were about to reinvent the wheel here. ;-)

-- 
Eric Botcazou

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Richard Sandiford wrote:

> Richard Biener  writes:
> > On Thu, 3 Feb 2022, Richard Sandiford wrote:
> >
> >> Richard Biener  writes:
> >> > On Wed, 2 Feb 2022, Michael Matz wrote:
> >> >
> >> >> Hello,
> >> >> 
> >> >> On Wed, 2 Feb 2022, Richard Biener via Gcc-patches wrote:
> >> >> 
> >> >> > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers 
> >> >> > this 
> >> >> > marks the end-of-life of storage as opposed to just ending the 
> >> >> > lifetime 
> >> >> > of the object that occupied it. The dangling pointer diagnostics uses 
> >> >> > CLOBBERs but is confused by those emitted by the C++ frontend for 
> >> >> > example which emits them for the second purpose at the start of 
> >> >> > CTORs.  
> >> >> > The issue is also appearant for aarch64 in PR104092.
> >> >> > 
> >> >> > Distinguishing the two cases is also necessary for the PR90348 fix.
> >> >> 
> >> >> (Just FWIW: I agree with the plan to have different types of CLOBBERs, 
> >> >> in 
> >> >> particular those for marking births)
> >> >> 
> >> >> A style nit:
> >> >> 
> >> >> > tree clobber = build_clobber (TREE_TYPE (t));
> >> >> > +   CLOBBER_MARKS_EOL (clobber) = 1;
> >> >> 
> >> >> I think it really were better if build_clobber() gained an additional 
> >> >> argument (non-optional!) that sets the type of it.
> >> >
> >> > It indeed did occur to me as well, so as we're two now I tried to see
> >> > how it looks like.  It does like the following (didn't bother to
> >> > replace all build_clobber calls but defaulted the parameter - there
> >> > are too many).  With CLOBBER_BIRTH added for the fix for PR90348
> >> > the enum would be constructed like
> >> >
> >> > #define CLOBBER_KIND(NODE) \
> >> >   ((clobber_kind) (CONSTRUCTOR_CHECK (NODE)->base.private_flag << 1
> >> >| CONSTRUCTOR_CHECK (NODE)->base.protected_flag))
> >> >
> >> > or so (maybe different dependent on bitfield endianess to make
> >> > extracting the two adjacent bits cheap).  That would leave us space
> >> > for a fourth state.
> >> >
> >> > So do you think that makes it nicer?  What do others think?
> >> 
> >> This way looks cleaner to me FWIW.
> >> 
> >> Which arm of tree_base::u do constructors use?  If we need a 2-bit
> >> enum then maybe we can carve one out from there.
> >
> > constructors are tcc_exceptional but since they are used where
> > tree operands reside they need to be compatible to EXPR_P and
> > thus various things like TREE_SIDE_EFFECTS need to work.
> >
> > Which means, we can't.
> 
> But TREE_SIDE_EFFECTS is part of the main set of flags.  For tree_base::u
> we have:
> 
>   union {
> /* The bits in the following structure should only be used with
>accessor macros that constrain inputs with tree checking.  */
> struct {
>   unsigned lang_flag_0 : 1;
>   unsigned lang_flag_1 : 1;
>   unsigned lang_flag_2 : 1;
>   unsigned lang_flag_3 : 1;
>   unsigned lang_flag_4 : 1;
>   unsigned lang_flag_5 : 1;
>   unsigned lang_flag_6 : 1;
>   unsigned saturating_flag : 1;
> 
>   unsigned unsigned_flag : 1;
>   unsigned packed_flag : 1;
>   unsigned user_align : 1;
>   unsigned nameless_flag : 1;
>   unsigned atomic_flag : 1;
>   unsigned unavailable_flag : 1;
>   unsigned spare0 : 2;
> 
>   unsigned spare1 : 8;
> 
>   /* This field is only used with TREE_TYPE nodes; the only reason it is
>present in tree_base instead of tree_type is to save space.  The size
>of the field must be large enough to hold addr_space_t values.  */
>   unsigned address_space : 8;
> } bits;
> 
> /* The following fields are present in tree_base to save space.  The
>nodes using them do not require any of the flags above and so can
>make better use of the 4-byte sized word.  */
> 
> /* The number of HOST_WIDE_INTs in an INTEGER_CST.  */
> struct {
>   /* The number of HOST_WIDE_INTs if the INTEGER_CST is accessed in
>its native precision.  */
>   unsigned char unextended;
> 
>   /* The number of HOST_WIDE_INTs if the INTEGER_CST is extended to
>wider precisions based on its TYPE_SIGN.  */
>   unsigned char extended;
> 
>   /* The number of HOST_WIDE_INTs if the INTEGER_CST is accessed in
>offset_int precision, with smaller integers being extended
>according to their TYPE_SIGN.  This is equal to one of the two
>fields above but is cached for speed.  */
>   unsigned char offset;
> } int_length;
> 
> /* VEC length.  This field is only used with TREE_VEC.  */
> int length;
> 
> /* This field is only used with VECTOR_CST.  */
> struct {
>   /* The value of VECTOR_CST_LOG2_NPATTERNS.  */
>   unsigned int log2_npatterns : 8;
> 
>   /* The value of VECTOR_CST_NELTS_PER_PATTERN.  */
>   unsigned int nelts_per_pattern : 8;
> 
>   /* For future expansion.  */
>   unsigned int unused : 16;
> 

ARM patch ping

[Jakub Jelinek via Gcc-patches]

Hi!

I'd like to ping the following patch.

Thanks.

On Thu, Jan 27, 2022 at 11:07:26AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jan 20, 2022 at 11:27:20AM +, Richard Earnshaw via Gcc-patches 
> wrote:
> > gcc/ChangeLog:
> > 
> > * config/arm/arm.opt (mfix-cortex-a57-aes-1742098): New command-line
> > option.
> > (mfix-cortex-a72-aes-1655431): New option alias.
> 
> > --- a/gcc/config/arm/arm.opt
> > +++ b/gcc/config/arm/arm.opt
> > @@ -272,6 +272,16 @@ mfix-cmse-cve-2021-35465
> >  Target Var(fix_vlldm) Init(2)
> >  Mitigate issues with VLLDM on some M-profile devices (CVE-2021-35465).
> >  
> > +mfix-cortex-a57-aes-1742098
> > +Target Var(fix_aes_erratum_1742098) Init(2) Save
> > +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> > +Arm erratum #1742098
> > +
> > +mfix-cortex-a72-aes-1655431
> > +Target Alias(mfix-cortex-a57-aes-1742098)
> > +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> > +Arm erratum #1655431
> > +
> >  munaligned-access
> >  Target Var(unaligned_access) Init(2) Save
> >  Enable unaligned word and halfword accesses to packed data.
> 
> This breaks:
> Running /usr/src/gcc/gcc/testsuite/gcc.misc-tests/help.exp ...
> FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from 
> output: "  -mfix-cortex-a57-aes-1742098 Mitigate issues with AES instructions 
> on Cortex-A57 and Cortex-A72. Arm erratum #1742098"
> 
> help.exp with help of lib/options.exp tests whether all non-empty 
> descriptions of
> options are terminated with . or :.
> 
> The following patch fixes that, ok for trunk?
> 
> 2022-01-27  Jakub Jelinek  
> 
>   * config/arm/arm.opt (mfix-cortex-a57-aes-1742098,
>   mfix-cortex-a72-aes-1655431): Ensure description ends with full stop.
> 
> --- gcc/config/arm/arm.opt.jj 2022-01-21 22:43:22.879719389 +0100
> +++ gcc/config/arm/arm.opt2022-01-27 11:02:29.457553296 +0100
> @@ -274,13 +274,13 @@ Mitigate issues with VLLDM on some M-pro
>  
>  mfix-cortex-a57-aes-1742098
>  Target Var(fix_aes_erratum_1742098) Init(2) Save
> -Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> -Arm erratum #1742098
> +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72
> +(Arm erratum #1742098).
>  
>  mfix-cortex-a72-aes-1655431
>  Target Alias(mfix-cortex-a57-aes-1742098)
> -Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> -Arm erratum #1655431
> +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72
> +(Arm erratum #1655431).
>  
>  munaligned-access
>  Target Var(unaligned_access) Init(2) Save

Jakub

Re: ARM patch ping

[Richard Biener via Gcc-patches]

On Thu, Feb 3, 2022 at 2:21 PM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> I'd like to ping the following patch.

OK (note the patch is obvious IMHO)

Richard.

> Thanks.
>
> On Thu, Jan 27, 2022 at 11:07:26AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Thu, Jan 20, 2022 at 11:27:20AM +, Richard Earnshaw via Gcc-patches 
> > wrote:
> > > gcc/ChangeLog:
> > >
> > > * config/arm/arm.opt (mfix-cortex-a57-aes-1742098): New command-line
> > > option.
> > > (mfix-cortex-a72-aes-1655431): New option alias.
> >
> > > --- a/gcc/config/arm/arm.opt
> > > +++ b/gcc/config/arm/arm.opt
> > > @@ -272,6 +272,16 @@ mfix-cmse-cve-2021-35465
> > >  Target Var(fix_vlldm) Init(2)
> > >  Mitigate issues with VLLDM on some M-profile devices (CVE-2021-35465).
> > >
> > > +mfix-cortex-a57-aes-1742098
> > > +Target Var(fix_aes_erratum_1742098) Init(2) Save
> > > +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> > > +Arm erratum #1742098
> > > +
> > > +mfix-cortex-a72-aes-1655431
> > > +Target Alias(mfix-cortex-a57-aes-1742098)
> > > +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> > > +Arm erratum #1655431
> > > +
> > >  munaligned-access
> > >  Target Var(unaligned_access) Init(2) Save
> > >  Enable unaligned word and halfword accesses to packed data.
> >
> > This breaks:
> > Running /usr/src/gcc/gcc/testsuite/gcc.misc-tests/help.exp ...
> > FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from 
> > output: "  -mfix-cortex-a57-aes-1742098 Mitigate issues with AES 
> > instructions on Cortex-A57 and Cortex-A72. Arm erratum #1742098"
> >
> > help.exp with help of lib/options.exp tests whether all non-empty 
> > descriptions of
> > options are terminated with . or :.
> >
> > The following patch fixes that, ok for trunk?
> >
> > 2022-01-27  Jakub Jelinek  
> >
> >   * config/arm/arm.opt (mfix-cortex-a57-aes-1742098,
> >   mfix-cortex-a72-aes-1655431): Ensure description ends with full stop.
> >
> > --- gcc/config/arm/arm.opt.jj 2022-01-21 22:43:22.879719389 +0100
> > +++ gcc/config/arm/arm.opt2022-01-27 11:02:29.457553296 +0100
> > @@ -274,13 +274,13 @@ Mitigate issues with VLLDM on some M-pro
> >
> >  mfix-cortex-a57-aes-1742098
> >  Target Var(fix_aes_erratum_1742098) Init(2) Save
> > -Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> > -Arm erratum #1742098
> > +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72
> > +(Arm erratum #1742098).
> >
> >  mfix-cortex-a72-aes-1655431
> >  Target Alias(mfix-cortex-a57-aes-1742098)
> > -Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> > -Arm erratum #1655431
> > +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72
> > +(Arm erratum #1655431).
> >
> >  munaligned-access
> >  Target Var(unaligned_access) Init(2) Save
>
> Jakub
>

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Michael Matz via Gcc-patches]

Hello,

On Thu, 3 Feb 2022, Richard Biener wrote:

> > > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this 
> > > marks the end-of-life of storage as opposed to just ending the lifetime 
> > > of the object that occupied it. The dangling pointer diagnostics uses 
> > > CLOBBERs but is confused by those emitted by the C++ frontend for 
> > > example which emits them for the second purpose at the start of CTORs.  
> > > The issue is also appearant for aarch64 in PR104092.
> > > 
> > > Distinguishing the two cases is also necessary for the PR90348 fix.
> > 
> > (Just FWIW: I agree with the plan to have different types of CLOBBERs, in 
> > particular those for marking births)
> > 
> > A style nit:
> > 
> > > tree clobber = build_clobber (TREE_TYPE (t));
> > > +   CLOBBER_MARKS_EOL (clobber) = 1;
> > 
> > I think it really were better if build_clobber() gained an additional 
> > argument (non-optional!) that sets the type of it.
> 
> It indeed did occur to me as well, so as we're two now I tried to see
> how it looks like.  It does like the following (didn't bother to
> replace all build_clobber calls but defaulted the parameter - there
> are too many).

Except for this part I like it (I wouldn't call ca. 25 calls too 
many).  I often find optional arguments to be a long term maintenance 
burden when reading code.

(And yeah, enum good, putting the enum to tree_base.u, if it works, 
otherwise use your bit shuffling)


Ciao,
Michael.

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Michael Matz wrote:

> Hello,
> 
> On Thu, 3 Feb 2022, Richard Biener wrote:
> 
> > > > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers this 
> > > > marks the end-of-life of storage as opposed to just ending the lifetime 
> > > > of the object that occupied it. The dangling pointer diagnostics uses 
> > > > CLOBBERs but is confused by those emitted by the C++ frontend for 
> > > > example which emits them for the second purpose at the start of CTORs.  
> > > > The issue is also appearant for aarch64 in PR104092.
> > > > 
> > > > Distinguishing the two cases is also necessary for the PR90348 fix.
> > > 
> > > (Just FWIW: I agree with the plan to have different types of CLOBBERs, in 
> > > particular those for marking births)
> > > 
> > > A style nit:
> > > 
> > > >   tree clobber = build_clobber (TREE_TYPE (t));
> > > > + CLOBBER_MARKS_EOL (clobber) = 1;
> > > 
> > > I think it really were better if build_clobber() gained an additional 
> > > argument (non-optional!) that sets the type of it.
> > 
> > It indeed did occur to me as well, so as we're two now I tried to see
> > how it looks like.  It does like the following (didn't bother to
> > replace all build_clobber calls but defaulted the parameter - there
> > are too many).
> 
> Except for this part I like it (I wouldn't call ca. 25 calls too 
> many).  I often find optional arguments to be a long term maintenance 
> burden when reading code.

But I think in this case it makes clear that the remaining callers
are un-audited - as Jakub said some of them may want to use a
specific kind.  I also wanted to make the patch small just in case
we're considering the fix for GCC 12 ...

> (And yeah, enum good, putting the enum to tree_base.u, if it works, 
> otherwise use your bit shuffling)

It seems to.  Updated patch in testing.

Richard.

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Richard Biener via Gcc-patches]

On Thu, 3 Feb 2022, Richard Biener wrote:

> On Thu, 3 Feb 2022, Michael Matz wrote:
> 
> > Hello,
> > 
> > On Thu, 3 Feb 2022, Richard Biener wrote:
> > 
> > > > > This adds a flag to CONSTRUCTOR nodes indicating that for clobbers 
> > > > > this 
> > > > > marks the end-of-life of storage as opposed to just ending the 
> > > > > lifetime 
> > > > > of the object that occupied it. The dangling pointer diagnostics uses 
> > > > > CLOBBERs but is confused by those emitted by the C++ frontend for 
> > > > > example which emits them for the second purpose at the start of 
> > > > > CTORs.  
> > > > > The issue is also appearant for aarch64 in PR104092.
> > > > > 
> > > > > Distinguishing the two cases is also necessary for the PR90348 fix.
> > > > 
> > > > (Just FWIW: I agree with the plan to have different types of CLOBBERs, 
> > > > in 
> > > > particular those for marking births)
> > > > 
> > > > A style nit:
> > > > 
> > > > > tree clobber = build_clobber (TREE_TYPE (t));
> > > > > +   CLOBBER_MARKS_EOL (clobber) = 1;
> > > > 
> > > > I think it really were better if build_clobber() gained an additional 
> > > > argument (non-optional!) that sets the type of it.
> > > 
> > > It indeed did occur to me as well, so as we're two now I tried to see
> > > how it looks like.  It does like the following (didn't bother to
> > > replace all build_clobber calls but defaulted the parameter - there
> > > are too many).
> > 
> > Except for this part I like it (I wouldn't call ca. 25 calls too 
> > many).  I often find optional arguments to be a long term maintenance 
> > burden when reading code.
> 
> But I think in this case it makes clear that the remaining callers
> are un-audited - as Jakub said some of them may want to use a
> specific kind.  I also wanted to make the patch small just in case
> we're considering the fix for GCC 12 ...
> 
> > (And yeah, enum good, putting the enum to tree_base.u, if it works, 
> > otherwise use your bit shuffling)
> 
> It seems to.  Updated patch in testing.

Meh.  C++ uses LANG_FLAG_3 on CTORs at least, so I'm switching to
u.bits.address_space.

Richard.

[PATCH v4] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[David Seifert via Gcc-patches]

* `-Werror` can cause issues when a more recent version of GCC compiles
  an older version:
  - https://bugs.gentoo.org/229059
  - https://bugs.gentoo.org/475350
  - https://bugs.gentoo.org/667104

Bootstrapped/regtested x86_64-linux, tested without --disable-werror and
with ./configure --disable-werror, the latter removing -Werror as expected.

libatomic/ChangeLog:

* libatomic/configure.ac: Support --disable-werror.
* libatomic/configure: Regenerate.

libbacktrace/ChangeLog:

* libbacktrace/configure.ac: Support --disable-werror.
* libbacktrace/configure: Regenerate.

libgo/ChangeLog:

* libgo/configure.ac: Support --disable-werror.
* libgo/configure: Regenerate.

libgomp/ChangeLog:

* libgomp/configure.ac: Support --disable-werror.
* libgomp/configure: Regenerate.

libitm/ChangeLog:

* libitm/configure.ac: Support --disable-werror.
* libitm/configure: Regenerate.

libsanitizer/ChangeLog:

* libsanitizer/configure.ac: Support --disable-werror.
* libsanitizer/libbacktrace/Makefile.am (WARN_FLAGS): Remove.
---
 libatomic/configure.ac|  6 --
 libbacktrace/configure.ac |  7 ---
 libgo/configure.ac|  8 
 libgomp/configure.ac  |  6 --
 libitm/configure.ac   |  6 --
 libsanitizer/configure.ac | 11 +++
 libsanitizer/libbacktrace/Makefile.am |  2 --
 7 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/libatomic/configure.ac b/libatomic/configure.ac
index f350b9b3509..c715d06fe8b 100644
--- a/libatomic/configure.ac
+++ b/libatomic/configure.ac
@@ -251,10 +251,12 @@ LIBAT_ENABLE_SYMVERS
 CFLAGS="$save_CFLAGS"
 AC_CACHE_SAVE
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 # Add CET specific flags if CET is enabled
 GCC_CET_FLAGS(CET_FLAGS)
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 0dfd82bc03e..f18de946597 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -145,10 +145,11 @@ ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwrite-strings 
-Wstrict-prototypes \
  -Wmissing-format-attribute -Wcast-qual],
  [WARN_FLAGS])
 
-if test -n "${with_target_subdir}"; then
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
+AS_IF([test "x$enable_werror" != "xno" && test -n "${with_target_subdir}"], [
   WARN_FLAGS="$WARN_FLAGS -Werror"
-fi
-
+])
 AC_SUBST(WARN_FLAGS)
 
 if test -n "${with_target_subdir}"; then
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 1f4f32dae2b..11dd9a7fc21 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -62,11 +62,11 @@ AC_PROG_AWK
 WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
 AC_SUBST(WARN_FLAGS)
 
-AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
-  [turns on -Werror @<:@default=yes@:>@])])
-if test "x$enable_werror" != "xno"; then
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   WERROR="-Werror"
-fi
+])
 AC_SUBST(WERROR)
 
 glibgo_toolexecdir=no
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index bfb613b91f0..9b77c8f44e8 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -121,10 +121,12 @@ AC_SUBST(CFLAGS)
 # in both places for now and restore CFLAGS at the end of config.
 save_CFLAGS="$CFLAGS"
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 # Find other programs we need.
 AC_CHECK_TOOL(AR, ar)
diff --git a/libitm/configure.ac b/libitm/configure.ac
index ac81b146845..616158f5c43 100644
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -261,10 +261,12 @@ GCC_CHECK_ELF_STYLE_WEAKREF
 CFLAGS="$save_CFLAGS"
 AC_CACHE_SAVE
 
+AC_ARG_ENABLE([werror], [
+  AS_HELP_STRING([--disable-werror], [disable building with -Werror])])
 # Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
   XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
 
 XCFLAGS="$XCFLAGS $XPCFLAGS"
 
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index 13cd302030d..e422a36333c 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -400,6 +400,17 @@ fi
 AC_SUBST([TSAN_TARGET_DEPENDENT_OBJECTS])
 AC_SUBST([SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS])
 
+AC_ARG_EN

Re: [PATCH] debug/104337 - avoid messing with the abstract origin chain in NRV

[Jason Merrill via Gcc-patches]

On 2/3/22 05:27, Richard Biener wrote:

The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after
variable creation since NRV runs _after_ the function was inlined and thus
affects the inlined variables copy indirectly.  We may adjust the abstract
origin of a variable only at the point we create it, not further along the
path since otherwise the (new) invariant that the abstract origin is always
the ultimate origin cannot be maintained.

The intent of what NRV does is OK I guess and it may improve the debug
experience.  But I also notice we do

   SET_DECL_VALUE_EXPR (found, result);
   DECL_HAS_VALUE_EXPR_P (found) = 1;

the code is there since the merge from tree-ssa which added tree-nrv.c.

Jakub added the DECL_VALUE_EXPR in g:938650d8fddb878f623e315f0b7fd94b217efa96
and Jason added the abstract origin setting conditional in g:7716876bbd3a

The follwoing takes the radical approach and remove the attempt
to "optimize" the debug info.

The gdb testsuites show no regressions.

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

OK?


OK. It makes sense that the DECL_VALUE_EXPR is enough for lookup in the 
debugger to find 'd', and the debug output when I change c to noinline 
seems the same.



Thanks,
Richard.

2022-02-03  Richard Biener  

PR debug/104337
* tree-nrv.cc (pass_nrv::execute): Remove tieing result and found
together via DECL_ABSTRACT_ORIGIN.

* gcc.dg/debug/pr104337.c: New testcase.
---
  gcc/testsuite/gcc.dg/debug/pr104337.c | 15 +++
  gcc/tree-nrv.cc   | 13 -
  2 files changed, 15 insertions(+), 13 deletions(-)
  create mode 100644 gcc/testsuite/gcc.dg/debug/pr104337.c

diff --git a/gcc/testsuite/gcc.dg/debug/pr104337.c 
b/gcc/testsuite/gcc.dg/debug/pr104337.c
new file mode 100644
index 000..d15680fbf1a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/pr104337.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+
+struct a {
+  unsigned b : 7;
+};
+inline __attribute__((optimize(3))) __attribute__((always_inline)) struct a
+c() {
+  struct a d;
+  return d;
+}
+void e() {
+  for (;;)
+c();
+}
+int main() {}
diff --git a/gcc/tree-nrv.cc b/gcc/tree-nrv.cc
index a67736dae5c..b96d5b86f27 100644
--- a/gcc/tree-nrv.cc
+++ b/gcc/tree-nrv.cc
@@ -236,19 +236,6 @@ pass_nrv::execute (function *fun)
fprintf (dump_file, "\n");
  }
  
-  /* At this point we know that all the return statements return the

- same local which has suitable attributes for NRV.   Copy debugging
- information from FOUND to RESULT if it will be useful.  But don't set
- DECL_ABSTRACT_ORIGIN to point at another function.  */
-  if (!DECL_IGNORED_P (found)
-  && !(DECL_ABSTRACT_ORIGIN (found)
-  && DECL_CONTEXT (DECL_ABSTRACT_ORIGIN (found)) != 
current_function_decl))
-{
-  DECL_NAME (result) = DECL_NAME (found);
-  DECL_SOURCE_LOCATION (result) = DECL_SOURCE_LOCATION (found);
-  DECL_ABSTRACT_ORIGIN (result) = DECL_ABSTRACT_ORIGIN (found);
-}
-
TREE_ADDRESSABLE (result) |= TREE_ADDRESSABLE (found);
  
/* Now walk through the function changing all references to VAR to be

Re: [PATCH] Add CLOBBER_MARKS_EOL to mark storage end-of-life clobbers

[Michael Matz via Gcc-patches]

Hello,

On Thu, 3 Feb 2022, Richard Biener via Gcc-patches wrote:

> > > It indeed did occur to me as well, so as we're two now I tried to 
> > > see how it looks like.  It does like the following (didn't bother to 
> > > replace all build_clobber calls but defaulted the parameter - there 
> > > are too many).
> > 
> > Except for this part I like it (I wouldn't call ca. 25 calls too 
> > many).  I often find optional arguments to be a long term maintenance 
> > burden when reading code.
> 
> But I think in this case it makes clear that the remaining callers are 
> un-audited

My pedantic answer to that would be that to make something clear you want 
to be explicit, and being explicit means writing something, not 
leaving something out, so you'd add another "CLOBBER_DONTKNOW" and use 
that for the unaudited calls.  Pedantic, as I said :)

But, of course, you built the shed, so paint it green, all right :)


Ciao,
Michael.

Re: [pushed] aarch64: Adjust tests after fix for PR102659

[Richard Biener via Gcc-patches]

On Thu, Feb 3, 2022 at 11:52 AM Richard Sandiford via Gcc-patches
 wrote:
>
> After the fix for PR102659, the vectoriser can no longer group
> conditional accesses of the form:
>
>   for (int i = 0; i < n; ++i)
> if (...)
>   ...a[i * 2] + a[i * 2 + 1]...;
>
> on LP64 targets.  It has to treat them as two independent
> gathers instead.

Hmm, that's unfortunate.  Can you file an enhancement bugreport?
How does using intptr_t help?  i * 2 can still overflow with large n,
so can it with 'int' on ILP32.  So I guess this is the old issue
of transforming (uint64)(i * 2 + 1) to (uint64)(i*2) + 1UL?

> This was causing failures in the sve mask_struct*.c tests.
> The tests weren't really testing that int iterators could
> be used, so this patch switches to pointer-sized iterators
> instead.
>
> Tested on aarch64-linux-gnu & pushed.
>
> Richard
>
>
> gcc/testsuite/
> * gcc.target/aarch64/sve/mask_struct_load_1.c: Use intptr_t
> iterators instead of int iterators.
> * gcc.target/aarch64/sve/mask_struct_load_2.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_load_3.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_load_4.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_load_5.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_load_6.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_load_7.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_load_8.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_store_1.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_store_2.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_store_3.c: Likewise.
> * gcc.target/aarch64/sve/mask_struct_store_4.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c  | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c  | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c  | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_4.c  | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_5.c  | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_6.c  | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_7.c  | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_8.c  | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_1.c | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_2.c | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_3.c | 4 ++--
>  gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_4.c | 6 +++---
>  12 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c 
> b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c
> index 03b2b93df07..450fbb887e3 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_1.c
> @@ -6,9 +6,9 @@
>  #define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \
>void __attribute__ ((noinline, noclone)) \
>NAME##_2 (OUTTYPE *__restrict dest, INTYPE *__restrict src,  \
> -   MASKTYPE *__restrict cond, int n)   \
> +   MASKTYPE *__restrict cond, intptr_t n)  \
>{\
> -for (int i = 0; i < n; ++i)\
> +for (intptr_t i = 0; i < n; ++i)   \
>if (cond[i]) \
> dest[i] = src[i * 2] + src[i * 2 + 1];  \
>}
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c 
> b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c
> index 87ac3178be0..499abd7c99a 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_2.c
> @@ -6,9 +6,9 @@
>  #define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \
>void __attribute__ ((noinline, noclone)) \
>NAME##_3 (OUTTYPE *__restrict dest, INTYPE *__restrict src,  \
> -   MASKTYPE *__restrict cond, int n)   \
> +   MASKTYPE *__restrict cond, intptr_t n)  \
>{\
> -for (int i = 0; i < n; ++i)\
> +for (intptr_t i = 0; i < n; ++i)   \
>if (cond[i]) \
> dest[i] = (src[i * 3]   \
>+ src[i * 3 + 1] \
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c 
> b/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c
> index 54806f93ad9..a5ce0716322 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_load_3.c
> ++

Re: [PATCH] libgcc: Actually force divide by zero

[Michael Matz via Gcc-patches]

Hello,

On Thu, 3 Feb 2022, Richard Biener via Gcc-patches wrote:

> /* Preserve explicit divisions by 0: the C++ front-end wants to detect
>undefined behavior in constexpr evaluation, and assuming that the 
> division
>traps enables better optimizations than these anyway.  */
> (for div (trunc_div ceil_div floor_div round_div exact_div)
>  /* 0 / X is always zero.  */
>  (simplify
>   (div integer_zerop@0 @1)
>   /* But not for 0 / 0 so that we can get the proper warnings and errors.  
> */
>   (if (!integer_zerop (@1))
>@0))
> 
> it suggests we want to preserve all X / 0 when the 0 is literal but
> I think we can go a bit further and require 0/0 to not unnecessarily
> restrict other special cases.

Just remember that 0/0 is completely different from X/0 (with X != 0), the 
latter is a sensible limit, the former is just non-sense.  There's a 
reason why one is a NaN and the other Inf in floating point.  So it does 
make sense to differ between both on integer side as well.

(i'm split mind on the usefullness of "1/x -> 0" vs. its effect on 
trapping behaviour)


Ciao,
Michael.

> 
> Comments on the libgcc case below
> 
> > 2022-02-03  Jakub Jelinek  
> > 
> > * libgcc2.c (__udivmoddi4): Add optimization barriers to actually
> > ensure division by zero.
> > 
> > --- libgcc/libgcc2.c.jj 2022-01-11 23:11:23.810270199 +0100
> > +++ libgcc/libgcc2.c2022-02-03 09:24:14.513682731 +0100
> > @@ -1022,8 +1022,13 @@ __udivmoddi4 (UDWtype n, UDWtype d, UDWt
> > {
> >   /* qq = NN / 0d */
> >  
> > - if (d0 == 0)
> > -   d0 = 1 / d0;/* Divide intentionally by zero.  */
> > + if (__builtin_expect (d0 == 0, 0))
> > +   {
> > + UWtype one = 1;
> > + __asm ("" : "+g" (one));
> > + __asm ("" : "+g" (d0));
> > + d0 = one / d0;/* Divide intentionally by zero.  */
> > +   }
> 
> I'm not sure why we even bother - division or modulo by zero is
> undefined behavior and we are not emulating CPU behavior because
> the wide instructions emulated here do not actually exist.  That
> gives us the freedom of choosing the implementation defined
> behavior.
> 
> That said, _if_ we choose to "care" I'd rather choose to
> define the implementation to use the trap mechanism the
> target provides and thus use __builtin_trap ().  That then
> at least traps reliably, compared to the division by zero
> which doesn't do that on all targets.
> 
> So I'm not sure there's anything to fix besides eventually
> just deleting the d0 == 0 special case?
> 
> Richard.
> 

[PATCH v3 1/8] rs6000: More factoring of overload processing

[Bill Schmidt via Gcc-patches]

Hi!

Although the previous patch was correct, the logic around what to do when
the number of arguments is wrong was still hard to understand.  It should
be better now.  I'm now explicitly counting the number of expected arguments
and comparing against that.  The way the argument list is represented ensures
there is always at least one element in the argument chain, by terminating
the chain with an argument type of void, which is why the previous logic was
so convoluted.

The revisions are in altivec_resolve_overloaded_builtin.  Otherwise the patch
is the same as before.  I hope this is much easier to read!  Bootstrapped and
tested on powerpc64le-linux-gnu.  Is this okay for trunk?

Original changelog message follows:

This patch continues the refactoring started with r12-6014.  I had previously
noted that the resolve_vec* routines can be further simplified by processing
the argument list earlier, so that all routines can use the arrays of arguments
and types.  I found that this was useful for some of the routines, but not for
all of them.

For several of the special-cased overloads, we don't specify all of the
possible type combinations in rs6000-overload.def, because the types don't
matter for the expansion we do.  For these, we can't use generic error message
handling when the number of arguments is incorrect, because the result is
misleading error messages that indicate argument types are wrong.

So this patch goes halfway and improves the factoring on the remaining special
cases, but leaves vec_splats, vec_promote, vec_extract, vec_insert, and
vec_step alone.

Thanks,
Bill


2022-02-02  Bill Schmidt  

gcc/
* config/rs6000/rs6000-c.cc (resolve_vec_mul): Accept args and types
parameters instead of arglist and nargs.  Simplify accordingly.  Remove
unnecessary test for argument count mismatch.
(resolve_vec_cmpne): Likewise.
(resolve_vec_adde_sube): Likewise.
(resolve_vec_addec_subec): Likewise.
(altivec_resolve_overloaded_builtin): Move overload special handling
after the gathering of arguments into args[] and types[] and the test
for correct number of arguments.  Don't perform the test for correct
number of arguments for certain special cases.  Call the other special
cases with args and types instead of arglist and nargs.
---
 gcc/config/rs6000/rs6000-c.cc | 304 ++
 1 file changed, 127 insertions(+), 177 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc
index 145421ab8f2..15251efc209 100644
--- a/gcc/config/rs6000/rs6000-c.cc
+++ b/gcc/config/rs6000/rs6000-c.cc
@@ -939,37 +939,25 @@ altivec_build_resolved_builtin (tree *args, int n, tree 
fntype, tree ret_type,
 enum resolution { unresolved, resolved, resolved_bad };
 
 /* Resolve an overloaded vec_mul call and return a tree expression for the
-   resolved call if successful.  NARGS is the number of arguments to the call.
-   ARGLIST contains the arguments.  RES must be set to indicate the status of
+   resolved call if successful.  ARGS contains the arguments to the call.
+   TYPES contains their types.  RES must be set to indicate the status of
the resolution attempt.  LOC contains statement location information.  */
 
 static tree
-resolve_vec_mul (resolution *res, vec *arglist, unsigned nargs,
-location_t loc)
+resolve_vec_mul (resolution *res, tree *args, tree *types, location_t loc)
 {
   /* vec_mul needs to be special cased because there are no instructions for it
  for the {un}signed char, {un}signed short, and {un}signed int types.  */
-  if (nargs != 2)
-{
-  error ("builtin %qs only accepts 2 arguments", "vec_mul");
-  *res = resolved;
-  return error_mark_node;
-}
-
-  tree arg0 = (*arglist)[0];
-  tree arg0_type = TREE_TYPE (arg0);
-  tree arg1 = (*arglist)[1];
-  tree arg1_type = TREE_TYPE (arg1);
 
   /* Both arguments must be vectors and the types must be compatible.  */
-  if (TREE_CODE (arg0_type) != VECTOR_TYPE
-  || !lang_hooks.types_compatible_p (arg0_type, arg1_type))
+  if (TREE_CODE (types[0]) != VECTOR_TYPE
+  || !lang_hooks.types_compatible_p (types[0], types[1]))
 {
   *res = resolved_bad;
   return error_mark_node;
 }
 
-  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
+  switch (TYPE_MODE (TREE_TYPE (types[0])))
 {
 case E_QImode:
 case E_HImode:
@@ -978,21 +966,21 @@ resolve_vec_mul (resolution *res, vec 
*arglist, unsigned nargs,
 case E_TImode:
   /* For scalar types just use a multiply expression.  */
   *res = resolved;
-  return fold_build2_loc (loc, MULT_EXPR, TREE_TYPE (arg0), arg0,
- fold_convert (TREE_TYPE (arg0), arg1));
+  return fold_build2_loc (loc, MULT_EXPR, types[0], args[0],
+ fold_convert (types[0], args[1]));
 case E_SFmode:
   {
/* For floats use the xvmulsp instruction directly.  */

Re: [PATCH v2] constrain conservative string lengths to array sizes [PR104119]

[Jason Merrill via Gcc-patches]

On 1/20/22 17:54, Martin Sebor wrote:

The updated patch ensures the tighter bound isn't used to compute
the sprintf result and adds a test to verify that.  (This is messy
in the strlen/sprintf pass and should be cleaned up to avoid this
mistake in the future.)

Rested on x86_64-linux.


OK, thanks.


On 1/19/22 18:20, Martin Sebor wrote:

The attached patch suppresses a class of unexpected -Wformat-overflow
(and -truncation) warnings introduced as a result of better range info
with the integration of the strlen pass with Ranger.

The sprintf warning code relies on the strlen pass data to determine
the lengths of string arguments to %s directives.  When the data for
a string are present, such as after a strlen call, the length can be
either a constant or, in the case of interest, a range (including
[N, PTRDIFF_MAX - 2] for a string of unbounded length).  When absent
because no string call has been seen yet, the string length is
considered to be bounded by the size of the array it's stored in.
This constrains the maximum number of bytes output by the %s directive
and reduces false positives.

The problem this patch addresses is that in the interesting case there
is no logic similar to the last ("no data") case, and so the maximum
number of bytes can be in excess of the size of the array.  The patch
does it by computing the size of the object (or member) in which
the string is stored and using its size minus 1 as the upper bound
on the length.  To do that, I had to adjust the APIs to pass in
the pointer_query instance of the range_query.  The meat of the change
is in the new get_maxbound() function.

There might be opportunities to do better still.  I'll try to look
into them if I still have time.

Tested on x86_64-linux.

Martin

[PATCH] ranger: fix small thinko in fur_list constructor

[Aldy Hernandez via Gcc-patches]

The fur_list constructor for two ranges is leaving [1] in an undefined
state.  The reason we haven't noticed is because after all the
shuffling in the last cycle there are no remaining users of it
(similarly for fur_list(unsigned, irange *)).

Since it's very late in the cycle, I would prefer to fix this, rather
than removing unused constructors altogether.  Besides, we have uses
for them queued up for the next release.

Committed as obvious.

gcc/ChangeLog:

* gimple-range-fold.cc (fur_list::fur_list): Set m_local[1] correctly.
---
 gcc/gimple-range-fold.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index d70f6a2e8c8..5133a430f25 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -243,7 +243,7 @@ fur_list::fur_list (irange &r1, irange &r2) : fur_source 
(NULL)
   m_index = 0;
   m_limit = 2;
   m_local[0] = r1;
-  m_local[0] = r2;
+  m_local[1] = r2;
 }
 
 // Arbitrary number of ranges in a vector.
-- 
2.34.1

[PATCH] Speed up fixincludes.

[Martin Liška]

In my case:
$ rm ./stmp-fixinc ; time make -j16

takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.

The scripts searches ~2500 folders in my case with total 20K header
files.

Ready to be installed?
Thanks,
Martin

fixincludes/ChangeLog:

* fixinc.in: Use mkdir -p rather that a loop.
---
 fixincludes/fixinc.in | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index de5a37f6acc..cdc0ca2e4c4 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -258,13 +258,9 @@ then echo "All directories (including links to 
directories):"
  echo $all_dirs
 fi
 
-for file in $all_dirs; do

-  rm -rf $LIB/$file
-  if [ ! -d $LIB/$file ]
-  then mkdir $LIB/$file
-  fi
-done
-mkdir $LIB/root
+cd $LIB
+mkdir -p $all_dirs
+cd ..
 
 # # # # # # # # # # # # # # # # # # # # #

 #
--
2.35.1

Re: [pushed] aarch64: Adjust tests after fix for PR102659

[Richard Sandiford via Gcc-patches]

Richard Biener  writes:
> On Thu, Feb 3, 2022 at 11:52 AM Richard Sandiford via Gcc-patches
>  wrote:
>>
>> After the fix for PR102659, the vectoriser can no longer group
>> conditional accesses of the form:
>>
>>   for (int i = 0; i < n; ++i)
>> if (...)
>>   ...a[i * 2] + a[i * 2 + 1]...;
>>
>> on LP64 targets.  It has to treat them as two independent
>> gathers instead.
>
> Hmm, that's unfortunate.  Can you file an enhancement bugreport?

OK, filed as PR104368.

> How does using intptr_t help?  i * 2 can still overflow with large n,
> so can it with 'int' on ILP32.  So I guess this is the old issue
> of transforming (uint64)(i * 2 + 1) to (uint64)(i*2) + 1UL?

That does happen, but I'm not sure that it's the main problem.
SCEV analysis seems to fail for the a[i * 2] access too.

With ints the &a[i * 2] calculation is:

  _45 = (unsigned int) i_26;
  _46 = _45 * 2;
  _5 = (int) _46;
  _6 = (long unsigned int) _5;
  _7 = _6 * 4;
  _48 = _47 + _7;

and the &a[i * 2 + 1] calculation is:

  _10 = _6 + 1;
  _11 = _10 * 4;
  _51 = _11 + _47;
 
With intptr_ts the &a[i * 2] calculation is:

  i.0_1 = (long unsigned int) i_23;
  _5 = i.0_1 * 8;
  _40 = _39 + _5;

and the &a[i * 2 + 1] calculation is:

  _8 = _5 + 4;
  _43 = _8 + _39;

which looks correct.

If the intptr_t i * 2 wraps then a &a[(uintptr_t)i * 2] IV will still
behave correctly, so the {a, +, 8} SCEV still seems accurate.  The int
i * 2 would instead wrap at 32 bits, so &a[(unsigned)i * 2] isn't
linear in any meaningful sense.

I don't know if the wrapping intptr_t SCEV leads to well-formed gimple
though.  Are pointer IVs assumed not to overflow?  If so, I guess we
might still be introducing UB for some intptr_t cases (although not
this one AFAICT, since any wrapping cases would be UB in the source too).

Thanks,
Richard

[PATCH][v2] Add CLOBBER_EOL to mark storage end-of-life clobbers

[Richard Biener via Gcc-patches]

This adds a flag to CONSTRUCTOR nodes indicating that for
clobbers this marks the end-of-life of storage as opposed to
just ending the lifetime of the object that occupied it.
The dangling pointer diagnostics uses CLOBBERs but is confused
by those emitted by the C++ frontend for example which emits
them for the second purpose at the start of CTORs.  The issue
is also appearant for aarch64 in PR104092.

Distinguishing the two cases is also necessary for the PR90348 fix.

Since I'm going to add another flag I added an enum clobber_flags
and a defaulted argument to build_clobber plus a convenient way to
query the enum from the CTOR tree and specify it for gimple_clobber_p.
Since 'CLOBBER' is already taken and I needed a name for the unspecified
clobber we have now I used 'CLOBBER_UNDEF'.

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

I'll push tomorrow if there are no further comments based on Jeffs
earlier OK.

Richard.

2022-02-03  Richard Biener  

PR middle-end/90348
PR middle-end/104092
gcc/
* tree-core.h (clobber_kind): New enum.
(tree_base::u::bits::address_space): Document use in CONSTRUCTORs.
* tree.h (CLOBBER_KIND): Add.
(build_clobber): Add clobber kind argument, defaulted to
CLOBBER_UNDEF.
* gimple.h (gimple_clobber_p): New overload with specified kind.
* tree-streamer-in.cc (streamer_read_tree_bitfields): Stream
CLOBBER_KIND.
* tree-streamer-out.cc (streamer_write_tree_bitfields):
Likewise.
* tree-pretty-print.cc (dump_generic_node): Mark EOL CLOBBERs.
* gimplify.c (gimplify_bind_expr): Build storage end-of-life clobbers
with CLOBBER_EOL.
(gimplify_target_expr): Likewise.
* tree-inline.cc (expand_call_inline): Likewise.
* tree-ssa-ccp.cc (insert_clobber_before_stack_restore): Likewise.
* gimple-ssa-warn-access.cc (pass_waccess::check_stmt): Only treat
CLOBBER_EOL clobbers as ending lifetime of storage.

gcc/lto/
* lto-common.cc (compare_tree_sccs_1): Compare CLOBBER_KIND.

gcc/testsuite/
* gcc.dg/pr87052.c: Adjust.
---
 gcc/gimple-ssa-warn-access.cc  |  3 ++-
 gcc/gimple.h   |  9 +
 gcc/gimplify.cc|  4 ++--
 gcc/lto/lto-common.cc  |  5 -
 gcc/testsuite/gcc.dg/pr87052.c |  2 +-
 gcc/tree-core.h| 12 +++-
 gcc/tree-inline.cc |  4 ++--
 gcc/tree-pretty-print.cc   |  6 +-
 gcc/tree-ssa-ccp.cc|  2 +-
 gcc/tree-streamer-in.cc|  2 ++
 gcc/tree-streamer-out.cc   |  5 -
 gcc/tree.cc|  3 ++-
 gcc/tree.h |  6 +-
 13 files changed, 50 insertions(+), 13 deletions(-)

diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index ad5e2f4458e..2559ad1506a 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -4330,7 +4330,8 @@ is_auto_decl (tree x)
 void
 pass_waccess::check_stmt (gimple *stmt)
 {
-  if (m_check_dangling_p && gimple_clobber_p (stmt))
+  if (m_check_dangling_p
+  && gimple_clobber_p (stmt, CLOBBER_EOL))
 {
   /* Ignore clobber statemts in blocks with exceptional edges.  */
   basic_block bb = gimple_bb (stmt);
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 441d29a109a..77a5a07e9b5 100644
--- a/gcc/gimple.h
+++ b/gcc/gimple.h
@@ -2939,6 +2939,15 @@ gimple_clobber_p (const gimple *s)
  && TREE_CLOBBER_P (gimple_assign_rhs1 (s));
 }
 
+/* Return true if S is a clobber statement.  */
+
+static inline bool
+gimple_clobber_p (const gimple *s, enum clobber_kind kind)
+{
+  return gimple_clobber_p (s)
+&& CLOBBER_KIND (gimple_assign_rhs1 (s)) == kind;
+}
+
 /* Return true if GS is a GIMPLE_CALL.  */
 
 static inline bool
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index cd4b61362b4..875b115d02d 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -1475,7 +1475,7 @@ gimplify_bind_expr (tree *expr_p, gimple_seq *pre_p)
  && !is_gimple_reg (t)
  && flag_stack_reuse != SR_NONE)
{
- tree clobber = build_clobber (TREE_TYPE (t));
+ tree clobber = build_clobber (TREE_TYPE (t), CLOBBER_EOL);
  gimple *clobber_stmt;
  clobber_stmt = gimple_build_assign (t, clobber);
  gimple_set_location (clobber_stmt, end_locus);
@@ -6981,7 +6981,7 @@ gimplify_target_expr (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p)
{
  if (flag_stack_reuse == SR_ALL)
{
- tree clobber = build_clobber (TREE_TYPE (temp));
+ tree clobber = build_clobber (TREE_TYPE (temp), CLOBBER_EOL);
  clobber = build2 (MODIFY_EXPR, TREE_TYPE (temp), temp, clobber);
  gimple_push_cleanup (temp, clobber, false, pre_p, true);
}
diff --git a/gcc/lto/lto-common.cc b/gcc/lto/lto-common.cc
index 11fde671162..ca28586a1e8 100644
--- a/gcc/lto/lto-common.cc

Re: [PATCH v4] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 03:06:07PM +0100, David Seifert wrote:
> * `-Werror` can cause issues when a more recent version of GCC compiles
>   an older version:
>   - https://bugs.gentoo.org/229059
>   - https://bugs.gentoo.org/475350
>   - https://bugs.gentoo.org/667104

Now committed as https://gcc.gnu.org/r12-7027-g45ba6bf28b75ee33
but I had to make quite a few changes, most importantly
ACX_PROG_CC_WARNING_OPTS wasn't defined so it remained as is, had to adjust
aclocal.m4.  Also, split the cases that were adding -Wall -Werror
together to add -Wall if gcc and -Werror if gcc and not --disable-werror.
And the --help texts had really weird formatting, so had to tweak that too.

Jakub

Re: [PATCH] Speed up fixincludes.

[Jeff Law via Gcc-patches]

On 2/3/2022 7:56 AM, Martin Liška wrote:

In my case:
$ rm ./stmp-fixinc ; time make -j16

takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.

The scripts searches ~2500 folders in my case with total 20K header
files.

Ready to be installed?
Thanks,
Martin

fixincludes/ChangeLog:

* fixinc.in: Use mkdir -p rather that a loop.

Don't we run the risk of overflowing ARG_MAX with this style invocation?
jeff

Re: [PATCH] Speed up fixincludes.

[Martin Liška]

On 2/3/22 16:19, Jeff Law wrote:



On 2/3/2022 7:56 AM, Martin Liška wrote:

In my case:
$ rm ./stmp-fixinc ; time make -j16

takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.

The scripts searches ~2500 folders in my case with total 20K header
files.

Ready to be installed?
Thanks,
Martin

fixincludes/ChangeLog:

* fixinc.in: Use mkdir -p rather that a loop.

Don't we run the risk of overflowing ARG_MAX with this style invocation?
jeff



You are correct, fixed in the attached V2.

What do you think now?

Thanks,
MartinFrom 0ba77db8a29ad1d98937d1deedbe1ad86638fc23 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 3 Feb 2022 15:49:43 +0100
Subject: [PATCH] Speed up fixincludes.

In my case:
$ rm ./stmp-fixinc ; time make -j16

takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.

The scripts searches ~2500 folders in my case with total 20K header
files.

fixincludes/ChangeLog:

	* fixinc.in: Use mkdir -p rather that a loop.
---
 fixincludes/fixinc.in | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index de5a37f6acc..92f3dfc39a9 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -258,12 +258,23 @@ then echo "All directories (including links to directories):"
  echo $all_dirs
 fi
 
-for file in $all_dirs; do
-  rm -rf $LIB/$file
-  if [ ! -d $LIB/$file ]
-  then mkdir $LIB/$file
-  fi
-done
+ARG_MAX=`getconf ARG_MAX 2>/dev/null`
+LENGTH=`expr length "$all_dirs" + 10`
+
+if test -n "$ARG_MAX" && test $LENGTH -lt $ARG_MAX
+then
+  cd $LIB
+  mkdir -p $all_dirs
+  cd ..
+else
+  for file in $all_dirs; do
+rm -rf $LIB/$file
+if [ ! -d $LIB/$file ]
+then mkdir $LIB/$file
+fi
+  done
+fi
+
 mkdir $LIB/root
 
 # # # # # # # # # # # # # # # # # # # # #
-- 
2.35.1

[PATCH] c++, v2: Further address_compare fixes [PR89074]

[Jakub Jelinek via Gcc-patches]

On Tue, Jan 18, 2022 at 05:40:48PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > About the rest of the patch, I thought I had seen richi comment on IRC (but
> > can't find the comment now) that these cases where we could give a constant
> > answer but decide not to because of C++ rules should be handled in the front
> > end rather than generic code, which makes sense to me; that is, use
> > folding_initializer only for giving more constant results, not for giving
> > fewer constant results.  Maybe add another flag for limiting constant
> > results if we think it's significantly easier to recognize these cases in
> > fold?
> 
> I'm afraid avoiding the match.pd & fold-const code here would be a lot of
> work.

Sorry for dropping the ball on this.

Here is a patch that introduces folding_cxx_constexpr flag and documents
that folding_initializer should be used for enabling more folding
optimizations, while folding_cxx_constexpr should be used to prevent
optimizations C++ doesn't allow in the constant expression evaluation.

Ok for trunk if it passes bootstrap/regtest?

2022-02-03  Jakub Jelinek  

PR c++/89074
PR c++/104033
* fold-const.h (folding_initializer): Adjust comment.
(folding_cxx_constexpr): Declare.
* fold-const.cc (folding_initializer): Adjust comment.
(folding_cxx_constexpr): New variable.
(address_compare): Restrict the decl vs. STRING_CST
or vice versa or STRING_CST vs. STRING_CST or
is_global_var != is_global_var optimizations to !folding_cxx_constexpr.
Punt for FUNCTION_DECLs with non-zero offsets.  If folding_initializer,
assume non-aliased functions have non-zero size and have different
addresses.  For folding_cxx_constexpr, punt on comparisons of start
of some object and end of another one, regardless whether it is a decl
or string literal.  Also punt for folding_cxx_constexpr on
STRING_CST vs. STRING_CST comparisons if the two literals could be
overlapping.

* constexpr.cc (cxx_eval_binary_expression): Temporarily set
folding_cxx_constexpr.

* g++.dg/cpp1y/constexpr-89074-3.C: New test.

--- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100
+++ gcc/fold-const.h2022-02-03 15:02:02.700228631 +0100
@@ -20,9 +20,16 @@ along with GCC; see the file COPYING3.
 #ifndef GCC_FOLD_CONST_H
 #define GCC_FOLD_CONST_H
 
-/* Non-zero if we are folding constants inside an initializer; zero
-   otherwise.  */
+/* Nonzero if we are folding constants inside an initializer or a C++
+   manifestly-constant-evaluated context; zero otherwise.
+   Should be used when folding in initializer enables additional
+   optimizations.  */
 extern int folding_initializer;
+/* Nonzer of we are folding C++ manifestly-constant-evaluated context; zero
+   otherwise.
+   Should be used when certain constructs shouldn't be optimized
+   during folding in that context.  */
+extern bool folding_cxx_constexpr;
 
 /* Convert between trees and native memory representation.  */
 extern int native_encode_expr (const_tree, unsigned char *, int, int off = -1);
--- gcc/fold-const.cc.jj2022-02-03 14:31:32.243129408 +0100
+++ gcc/fold-const.cc   2022-02-03 16:25:27.541467112 +0100
@@ -86,9 +86,17 @@ along with GCC; see the file COPYING3.
 #include "gimple-range.h"
 
 /* Nonzero if we are folding constants inside an initializer or a C++
-   manifestly-constant-evaluated context; zero otherwise.  */
+   manifestly-constant-evaluated context; zero otherwise.
+   Should be used when folding in initializer enables additional
+   optimizations.  */
 int folding_initializer = 0;
 
+/* Nonzer of we are folding C++ manifestly-constant-evaluated context; zero
+   otherwise.
+   Should be used when certain constructs shouldn't be optimized
+   during folding in that context.  */
+bool folding_cxx_constexpr = false;
+
 /* The following constants represent a bit based encoding of GCC's
comparison operators.  This encoding simplifies transformations
on relational comparison operators, such as AND and OR.  */
@@ -16628,41 +16636,91 @@ address_compare (tree_code code, tree ty
   HOST_WIDE_INT ioff0 = -1, ioff1 = -1;
   off0.is_constant (&ioff0);
   off1.is_constant (&ioff1);
-  if ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST)
-   || (TREE_CODE (base0) == STRING_CST && DECL_P (base1))
-   || (TREE_CODE (base0) == STRING_CST
-  && TREE_CODE (base1) == STRING_CST
-  && ioff0 >= 0 && ioff1 >= 0
-  && ioff0 < TREE_STRING_LENGTH (base0)
-  && ioff1 < TREE_STRING_LENGTH (base1)
- /* This is a too conservative test that the STRING_CSTs
-will not end up being string-merged.  */
-  && strncmp (TREE_STRING_POINTER (base0) + ioff0,
-  TREE_STRING_POINTER (base1) + ioff1,
-  MIN (TREE_STRING_LENGTH (base0) - ioff0,
-   TREE_STRING_LENGTH (base1) - ioff1)) 

Re: [PATCH] Speed up fixincludes.

[Andreas Schwab]

On Feb 03 2022, Martin Liška wrote:

> -mkdir $LIB/root

Why did you remote that line?

-- 
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] Speed up fixincludes.

[Martin Liška]

On 2/3/22 17:06, Andreas Schwab wrote:

On Feb 03 2022, Martin Liška wrote:


-mkdir $LIB/root


Why did you remote that line?



That was an accidental removal, fixed in V2.

Martin

Re: [PATCH] Speed up fixincludes.

[Andreas Schwab]

On Feb 03 2022, Martin Liška wrote:

> What do you think now?

xargs?

-- 
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] Speed up fixincludes.

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 04:40:25PM +0100, Martin Liška wrote:
> --- a/fixincludes/fixinc.in
> +++ b/fixincludes/fixinc.in
> @@ -258,12 +258,23 @@ then echo "All directories (including links to 
> directories):"
>   echo $all_dirs
>  fi
>  
> -for file in $all_dirs; do
> -  rm -rf $LIB/$file
> -  if [ ! -d $LIB/$file ]
> -  then mkdir $LIB/$file
> -  fi
> -done
> +ARG_MAX=`getconf ARG_MAX 2>/dev/null`
> +LENGTH=`expr length "$all_dirs" + 10`
> +
> +if test -n "$ARG_MAX" && test $LENGTH -lt $ARG_MAX
> +then
> +  cd $LIB
> +  mkdir -p $all_dirs
> +  cd ..
> +else
> +  for file in $all_dirs; do
> +rm -rf $LIB/$file
> +if [ ! -d $LIB/$file ]
> +then mkdir $LIB/$file
> +fi
> +  done
> +fi

Is getconf and expr length sufficiently portable?
Can't you use
echo "$all_dirs" | xargs mkdir -p
instead?

Jakub

Re: [PATCH] Speed up fixincludes.

[Martin Liška]

On 2/3/22 17:12, Jakub Jelinek wrote:

On Thu, Feb 03, 2022 at 04:40:25PM +0100, Martin Liška wrote:

--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -258,12 +258,23 @@ then echo "All directories (including links to 
directories):"
   echo $all_dirs
  fi
  
-for file in $all_dirs; do

-  rm -rf $LIB/$file
-  if [ ! -d $LIB/$file ]
-  then mkdir $LIB/$file
-  fi
-done
+ARG_MAX=`getconf ARG_MAX 2>/dev/null`
+LENGTH=`expr length "$all_dirs" + 10`
+
+if test -n "$ARG_MAX" && test $LENGTH -lt $ARG_MAX
+then
+  cd $LIB
+  mkdir -p $all_dirs
+  cd ..
+else
+  for file in $all_dirs; do
+rm -rf $LIB/$file
+if [ ! -d $LIB/$file ]
+then mkdir $LIB/$file
+fi
+  done
+fi


Is getconf and expr length sufficiently portable?
Can't you use
echo "$all_dirs" | xargs mkdir -p
instead?


Oh, even better!

Ready to be installed?
Thanks,
Martin



Jakub

From 7f14710fff01aa0267020020d20014144939f038 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 3 Feb 2022 15:49:43 +0100
Subject: [PATCH] Speed up fixincludes.

In my case:
$ rm ./stmp-fixinc ; time make -j16

takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.

The scripts searches ~2500 folders in my case with total 20K header
files.

fixincludes/ChangeLog:

	* fixinc.in: Use mkdir -p rather that a loop.
---
 fixincludes/fixinc.in | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index de5a37f6acc..0c3066452c6 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -258,12 +258,10 @@ then echo "All directories (including links to directories):"
  echo $all_dirs
 fi
 
-for file in $all_dirs; do
-  rm -rf $LIB/$file
-  if [ ! -d $LIB/$file ]
-  then mkdir $LIB/$file
-  fi
-done
+cd $LIB
+echo "$all_dirs" | xargs mkdir -p
+cd ..
+
 mkdir $LIB/root
 
 # # # # # # # # # # # # # # # # # # # # #
-- 
2.35.1

Re: s390: Fix bootstrap -Wformat-diag errors

[Martin Sebor via Gcc-patches]

On 2/3/22 01:59, Martin Liška wrote:

On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:

Hi Martin,


Either this:

    error ("% is unknown", orig_p);

or this would be better:

    error ("attribute % is unknown", orig_p);

The %< %> directives will render it in single quotes like keywords and
identifiers.  Using %qs would render it in double quotes like a string,
which wouldn't be quite right.


the x86 backend will print the error message in a different format using
single quotes e.g.

   bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown


That's a bug in the i386 back end:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524


I don't find that better to be frank but maybe it would make sense for
us to also adopt this error message style and not use a different one?
They use %qs, though - or is there an intention to also change x86's
error messages?  I guess in general it's better to have similar error
messages across targets for the same problem.

Regards
  Robin


Hello.

I've just coincidentally fixed the issue with r12-7013-g0415470c8d6620
where I use the same error format as i386 does.


The change repeats the i386 mistake in the s360 back end.  If
the error is supposed to point out that orig_p is not a valid
argument to attribute target as I believe is the case then
the new call should be:

  error ("attribute % argument %qs is unknown", orig_p);

Martin

Re: s390: Fix bootstrap -Wformat-diag errors

[Martin Liška]

On 2/3/22 17:43, Martin Sebor wrote:

On 2/3/22 01:59, Martin Liška wrote:

On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:

Hi Martin,


Either this:

    error ("% is unknown", orig_p);

or this would be better:

    error ("attribute % is unknown", orig_p);

The %< %> directives will render it in single quotes like keywords and
identifiers.  Using %qs would render it in double quotes like a string,
which wouldn't be quite right.


the x86 backend will print the error message in a different format using
single quotes e.g.

   bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown


That's a bug in the i386 back end:
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524


I don't find that better to be frank but maybe it would make sense for
us to also adopt this error message style and not use a different one?
They use %qs, though - or is there an intention to also change x86's
error messages?  I guess in general it's better to have similar error
messages across targets for the same problem.

Regards
  Robin


Hello.

I've just coincidentally fixed the issue with r12-7013-g0415470c8d6620
where I use the same error format as i386 does.


The change repeats the i386 mistake in the s360 back end.  If
the error is supposed to point out that orig_p is not a valid
argument to attribute target as I believe is the case then
the new call should be:

   error ("attribute % argument %qs is unknown", orig_p);

Martin


Yeah, fixed with g:9db03cd0caf6bbde1de302bf3509dc26ca8bff2b.

Cheers,
Martin

[PATCH] c++: dependence of member's noexcept-spec [PR104079]

[Patrick Palka via Gcc-patches]

Here a stale value of TYPE_DEPENDENT_P/_P_VALID for f's function
type after replacing its DEFERRED_NOEXCEPT with its parsed (dependent)
noexcept-spec leads us to try to instantiate g's noexcept-spec (which
incorrectly appears non-dependent) ahead of time, causing an ICE.

This patch fixes this by clearing TYPE_DEPENDENT_P_VALID in
fixup_deferred_exception_variants appropriately, as is already done in
build_cp_fntype_variant.

This is sufficient for C++17, but not for earlier dialects, because
it's not until C++17 that the noexcept-spec influences dependence of a
function type, so even after this fix we still deem g's noexcept-spec to
be non-dependent and incorrectly try to instantiate it ahead of time.
Since dependence of NOEXCEPT_EXPR is defined in terms of instantiation
dependence, the most appropriate fix for earlier dialects seems to be to
consider dependence of a noexcept-spec for instantiation dependence.

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

PR c++/104079

gcc/cp/ChangeLog:

* pt.cc (value_dependent_noexcept_spec_p): New predicate split
out from ...
(dependent_type_p_r): ... here.
(instantiation_dependent_r): Consider dependence of a
noexcept-specifier
* tree.cc (fixup_deferred_exception_variants): Clear
TYPE_DEPENDENT_P_VALID.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept74.C: New test.
---
 gcc/cp/pt.cc | 39 ++--
 gcc/cp/tree.cc   |  4 +++
 gcc/testsuite/g++.dg/cpp0x/noexcept74.C  | 11 +++
 gcc/testsuite/g++.dg/cpp0x/noexcept74a.C | 12 
 4 files changed, 57 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept74.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept74a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index feee629f1dd..a7dc0bc5f86 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -26979,6 +26979,24 @@ invalid_nontype_parm_type_p (tree type, tsubst_flags_t 
complain)
   return true;
 }
 
+/* Returns true iff the noexcept-specifier for TYPE is value-dependent.  */
+
+static bool
+value_dependent_noexcept_spec_p (tree type)
+{
+  if (tree spec = TYPE_RAISES_EXCEPTIONS (type))
+if (tree noex = TREE_PURPOSE (spec))
+  /* Treat DEFERRED_NOEXCEPT as non-dependent, since it doesn't
+affect overload resolution and treating it as dependent breaks
+things.  Same for an unparsed noexcept expression.  */
+  if (TREE_CODE (noex) != DEFERRED_NOEXCEPT
+ && TREE_CODE (noex) != DEFERRED_PARSE
+ && value_dependent_expression_p (noex))
+   return true;
+
+  return false;
+}
+
 /* Returns TRUE if TYPE is dependent, in the sense of [temp.dep.type].
Assumes that TYPE really is a type, and not the ERROR_MARK_NODE.*/
 
@@ -27033,15 +27051,7 @@ dependent_type_p_r (tree type)
  return true;
   if (cxx_dialect >= cxx17)
/* A value-dependent noexcept-specifier makes the type dependent.  */
-   if (tree spec = TYPE_RAISES_EXCEPTIONS (type))
- if (tree noex = TREE_PURPOSE (spec))
-   /* Treat DEFERRED_NOEXCEPT as non-dependent, since it doesn't
-  affect overload resolution and treating it as dependent breaks
-  things.  Same for an unparsed noexcept expression.  */
-   if (TREE_CODE (noex) != DEFERRED_NOEXCEPT
-   && TREE_CODE (noex) != DEFERRED_PARSE
-   && value_dependent_expression_p (noex))
- return true;
+   return value_dependent_noexcept_spec_p (type);
   return false;
 }
   /* -- an array type constructed from any dependent type or whose
@@ -27850,6 +27860,17 @@ instantiation_dependent_r (tree *tp, int 
*walk_subtrees,
return *tp;
   break;
 
+case TEMPLATE_DECL:
+case FUNCTION_DECL:
+  /* Before C++17, the noexcept-specifier wasn't part of the function type
+so it doesn't affect type dependence, but we still want to consider it
+for instantiation dependence.  */
+  if (cxx_dialect < cxx17
+ && DECL_DECLARES_FUNCTION_P (*tp)
+ && value_dependent_noexcept_spec_p (TREE_TYPE (*tp)))
+   return *tp;
+  break;
+
 default:
   break;
 }
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index 056f10f13b4..2d8f2c551c0 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -2839,6 +2839,10 @@ fixup_deferred_exception_variants (tree type, tree 
raises)
  }
else
  TYPE_RAISES_EXCEPTIONS (variant) = raises;
+
+   if (!TYPE_DEPENDENT_P (variant))
+ /* We no longer know that it's not type-dependent.  */
+ TYPE_DEPENDENT_P_VALID (variant) = false;
   }
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept74.C 
b/gcc/testsuite/g++.dg/cpp0x/noexcept74.C
new file mode 100644
index 000..e43d21c201e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept74.C
@@ -0,0 +1,11 @@
+// 

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

[Patrick Palka via Gcc-patches]

On Wed, 2 Feb 2022, Jason Merrill wrote:

> On 2/2/22 12:09, Patrick Palka wrote:
> > The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
> > template arguments before calling iterative_hash_template_arg and
> > template_args_equal, which would otherwise crash.
> 
> Maybe we should handle ARGUMENT_PACK_SELECT in iterative_hash_template_arg and
> template_args_equal, rather than their callers?

Like so?  I can't think of a good reason not to handle ARGUMENT_PACK_SELECT
ther, but FWIW it looks like we had such handling in the past, until it
was removed in r7-2082.

-- >8 --

Subject: [PATCH] c++: lambda in pack expansion using outer pack in constraint
 [PR103706]

Here when expanding the pack expansion pattern, the template argument
for T is an ARGUMENT_PACK_SELECT, which during satisfaction of C the
satisfaction cache passes to iterative_hash_template_arg and
template_args_equal, which don't handle ARGUMENT_PACK_SELECT presumably
because at some point it became unnecessary to do so.  Since it now
appears necessary again, this patch reinstates the ARGUMENT_PACK_SELECT
handling that was removed by r7-2082.

PR c++/103706

gcc/cp/ChangeLog:

* pt.cc (iterative_hash_template_arg): Handle ARGUMENT_PACK_SELECT.
(template_args_equal): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda19.C: New test.
---
 gcc/cp/pt.cc   | 10 ++
 gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C | 11 +++
 2 files changed, 17 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index c62822d65f8..644f24b7c09 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -220,6 +220,7 @@ static tree make_argument_pack (tree);
 static void register_parameter_specializations (tree, tree);
 static tree enclosing_instantiation_of (tree tctx);
 static void instantiate_body (tree pattern, tree args, tree d, bool nested);
+static tree argument_pack_select_arg (tree t);
 
 /* Make the current scope suitable for access checking when we are
processing T.  T can be FUNCTION_DECL for instantiated function
@@ -1783,6 +1784,9 @@ iterative_hash_template_arg (tree arg, hashval_t val)
   if (arg == NULL_TREE)
 return iterative_hash_object (arg, val);
 
+  if (TREE_CODE (arg) == ARGUMENT_PACK_SELECT)
+arg = argument_pack_select_arg (arg);
+
   if (!TYPE_P (arg))
 /* Strip nop-like things, but not the same as STRIP_NOPS.  */
 while (CONVERT_EXPR_P (arg)
@@ -1796,9 +1800,6 @@ iterative_hash_template_arg (tree arg, hashval_t val)
 
   switch (code)
 {
-case ARGUMENT_PACK_SELECT:
-  gcc_unreachable ();
-
 case ERROR_MARK:
   return val;
 
@@ -9246,7 +9247,8 @@ template_args_equal (tree ot, tree nt, bool partial_order 
/* = false */)
   else if (ARGUMENT_PACK_P (ot) || ARGUMENT_PACK_P (nt))
 return cp_tree_equal (ot, nt);
   else if (TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
-gcc_unreachable ();
+return template_args_equal (argument_pack_select_arg (ot),
+   argument_pack_select_arg (nt));
   else if (TYPE_P (nt) || TYPE_P (ot))
 {
   if (!(TYPE_P (nt) && TYPE_P (ot)))
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
new file mode 100644
index 000..570e3596f1b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
@@ -0,0 +1,11 @@
+// PR c++/103706
+// { dg-do compile { target c++20 } }
+
+template concept C = __is_same(T, int);
+
+template void f() {
+  ([]() requires C { return T(); }(), ...); // { dg-error "no match" }
+}
+
+template void f(); // { dg-bogus "" }
+template void f(); // { dg-message "required from here" }
-- 
2.35.0

[Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Gcc-patches]

This patch has been an excessively long time in coming. Please accept my
apologies for that.

All but two of the PR37336 dependencies are fixed, The two exceptions are
PRs 59694 and 65347. The former involves lack of finalization of an
unreferenced entity declared in a block, which I am sure is trivial but I
cannot see where the missing trigger is, and the latter involves
finalization of function results within an array constructor, for which I
will submit an additional patch shortly.  PR104272 also remains, in which
finalization is occurring during allocation. I fixed this in one place but
it seems to have crept out in another :-)

Beyond this patch and ones for the three lagging PRs above, a thorough tidy
up and unification of finalization is needed. However, I will concentrate
on functionality in the first instance.

I have tried to interpret F2018 7.5.6.2 and 7.5.6.3 as well as possible.
This is not always straightforward and has involved a lot of head
scratching! I have used the Intel compiler as a litmus test for the
outcomes. This was largely motivated by the observation that, in the user
survey conducted by Steve Lionel, gfortran and ifort are often used
together . Therefore, quite aside from wishing to comply with the standard
as far as possible, it is more than reasonable that the two compilers
comply. On application of this patch, only exception to this is the
treatment of finalization of arrays of extended types, where the Intel
takes "If the entity is of extended type and the parent type is
finalizable, the parent component is finalized" such that the parent
component is finalized one element at a time, whereas gfortran finalises
the parent components as an array. I strongly suspect that, from reading
7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, this
is another issue to come back to in the future.

The work centred on three areas:
(i) Finalization on assignment:
This was required because finalization of the lhs was occurring at the
wrong time relative to evaluation of the rhs expression and was taking the
finalization of entities with finalizable components in the wrong order.
The changes in trans-array.cc (structure_alloc_comps) allow
gfc_deallocate_alloc_comp_no_caf to occur without finalization so that it
can be preceded by calls to the finalization wrapper. The other key change
in this area is the addition of trans-expr.cc
(gfc_assignment_finalizer_call), which manages the ordering of finalization
and deallocation.

(ii) Finalization of derived type function results.
Previously, finalization was not occuring at all for derived type results
but it did for class results. The former is now implemented in
trans-expr.cc (finalize_function_result), into which the treatment of class
finalization has been included. In order to handled complex expressions
correctly, an extra block has been included in gfc_se and is initialized in
gfc_init_se. This block accumulates the finalizations so that they can be
added at the right time. It is the way in which I will fix PR65347 (I have
already tested the principle).

(iii) Minor fixes
These include the changes in class.cc and the exclusion of artificial
entities from finalization.

There are some missing testcases (sorry Andrew and Sandro!), which might
not be necessary because the broken/missing features are already fixed. The
fact that the work correctly now is a strong indication that this is the
case.

Regtests OK on FC33/x86_64 - OK for mainline (and 11-branch)?

Best regards

Paul

Fortran:Implement missing finalization features [PR37336]

2022-02-02  Paul Thomas  

gcc/fortran
PR fortran/103854
* class.cc (has_finalizer_component): Do not return true for
procedure pointer components.

PR fortran/96122
* class.cc (finalize_component): Include the missing arguments
in the call to the component's finalizer wrapper.

PR fortran/37336
* class.cc (finalizer_insert_packed_call): Remove the redundant
argument in the call to the final subroutine.
* resolve.cc (resolve_where, gfc_resolve_where_code_in_forall,
gfc_resolve_forall_body, gfc_resolve_code): Check that the op
code is still EXEC_ASSIGN. If it is set lhs to must finalize.
* trans-array.cc (structure_alloc_comps): Add boolean argument
to suppress finalization and use it for calls from
gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to
false. Add a second, additional boolean argument to nullify
pointer components and use it in gfc_copy_alloc_comp_del_ptrs.
(gfc_alloc_allocatable_for_assignment): Suppress finalization
by setting new arg in call to gfc_deallocate_alloc_comp_no_caf.
(gfc_copy_alloc_comp_del_ptrs): New function.
* trans-array.h : Add the new boolean argument to the prototype
of gfc_deallocate_alloc_comp_no_caf with a default of false.
Add prototype for gfc_copy_alloc_comp_del_ptrs.
* trans-expr.cc (gfc_init_se): Initialize finalblock.
(finalize_function_result): New function that finalizes
function results in the correct order.
(gfc_conv_procedure_call): Use 

Re: [PATCH] c++: constrained auto in lambda using outer tparms [PR103706]

[Patrick Palka via Gcc-patches]

On Wed, 2 Feb 2022, Jason Merrill wrote:

> On 2/2/22 13:21, Patrick Palka wrote:
> > On Wed, 2 Feb 2022, Patrick Palka wrote:
> > 
> > > Here we're crashing during satisfaction of the lambda's placeholder type
> > > constraints because the constraints depend on the template arguments
> > > from the enclosing scope, which aren't a part of the lambda's
> > > DECL_TI_ARGS.  So when inside a lambda, do_auto_deduction needs to add
> > > the "regenerating" template arguments to the set of outer template
> > > arguments, like we already do in satisfy_declaration_constraints.
> > > 
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > trunk and perhaps 11?
> > > 
> > >   PR c++/103706
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > >   * constraint.cc (satisfy_declaration_constraints): Use
> > >   lambda_regenerating_args instead.
> > >   * cp-tree.h (lambda_regenerating_args): Declare.
> > >   * pt.cc (add_to_template_args): Handle NULL_TREE extra_args
> > >   gracefully.
> > >   (lambda_regenerating_args): Define, split out from
> > >   satisfy_declaration_constraints.
> > >   (do_auto_deduction): Use lambda_regenerating_args to obtain the
> > >   full set of outer template arguments when checking the
> > >   constraint on a placeholder type within a lambda.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > >   * g++.dg/cpp2a/concepts-lambda18.C: New test.
> > > ---
> > >   gcc/cp/constraint.cc  |  9 +
> > >   gcc/cp/cp-tree.h  |  1 +
> > >   gcc/cp/pt.cc  | 37 ---
> > >   .../g++.dg/cpp2a/concepts-lambda18.C  | 14 +++
> > >   4 files changed, 48 insertions(+), 13 deletions(-)
> > >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda18.C
> > > 
> > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > > index cc4df4216ef..c41ee02b910 100644
> > > --- a/gcc/cp/constraint.cc
> > > +++ b/gcc/cp/constraint.cc
> > > @@ -3148,18 +3148,13 @@ satisfy_declaration_constraints (tree t, sat_info
> > > info)
> > >   args = add_outermost_template_args (args, inh_ctor_targs);
> > >   }
> > >   -  if (regenerated_lambda_fn_p (t))
> > > +  if (LAMBDA_FUNCTION_P (t))
> > >   {
> > > /* The TI_ARGS of a regenerated lambda contains only the innermost
> > >set of template arguments.  Augment this with the outer 
> > > template
> > >arguments that were used to regenerate the lambda.  */
> > > gcc_assert (!args || TMPL_ARGS_DEPTH (args) == 1);
> > > -  tree lambda = CLASSTYPE_LAMBDA_EXPR (DECL_CONTEXT (t));
> > > -  tree outer_args = TI_ARGS (LAMBDA_EXPR_REGEN_INFO (lambda));
> > > -  if (args)
> > > - args = add_to_template_args (outer_args, args);
> > > -  else
> > > - args = outer_args;
> > > +  args = add_to_template_args (lambda_regenerating_args (t), args);
> > >   }
> > >   /* If any arguments depend on template parameters, we can't
> > > diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> > > index b9eb71fbc3a..7a7fe5ba599 100644
> > > --- a/gcc/cp/cp-tree.h
> > > +++ b/gcc/cp/cp-tree.h
> > > @@ -7715,6 +7715,7 @@ extern void finish_lambda_scope
> > > (void);
> > >   extern tree start_lambda_function   (tree fn, tree 
> > > lambda_expr);
> > >   extern void finish_lambda_function  (tree body);
> > >   extern bool regenerated_lambda_fn_p (tree);
> > > +extern tree lambda_regenerating_args (tree);
> > >   extern tree most_general_lambda (tree);
> > >   extern tree finish_omp_target   (location_t, tree,
> > > tree, bool);
> > >   extern void finish_omp_target_clauses   (location_t, tree,
> > > tree *);
> > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > > index 6e129da1d05..c919d2de68f 100644
> > > --- a/gcc/cp/pt.cc
> > > +++ b/gcc/cp/pt.cc
> > > @@ -573,6 +573,9 @@ add_to_template_args (tree args, tree extra_args)
> > > if (args == NULL_TREE || extra_args == error_mark_node)
> > >   return extra_args;
> > >   +  if (extra_args == NULL_TREE)
> > > +return args;
> > > +
> > 
> > Whoops, this last-minute change to add_to_template_args turned out to
> > be a bad idea as some callers apparently rely on add_to_template_args
> > treating NULL_TREE extra_args as a depth 1 targ vector (whereas for
> > the calls in satisfy_declaration_constraints and do_auto_deduction we
> > want NULL_TREE extra_args to be treated as a depth 0 targ vector).
> > 
> > Please consider the below patch instead, which doesn't attempt to change
> > the behavior of add_to_template_args:
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] c++: constrained auto in lambda using outer tparms
> > [PR103706]
> > 
> > Here we're crashing during satisfaction of the lambda's placeholder type
> > constraints because the constraints depend on the template arguments
> > from the enclosing scope, which aren't part of the lambda's DECL_TI_ARG

Re: [PATCH] Speed up fixincludes.

[Jeff Law via Gcc-patches]

On 2/3/2022 9:21 AM, Martin Liška wrote:

On 2/3/22 17:12, Jakub Jelinek wrote:

On Thu, Feb 03, 2022 at 04:40:25PM +0100, Martin Liška wrote:

--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -258,12 +258,23 @@ then echo "All directories (including links to 
directories):"

   echo $all_dirs
  fi
  -for file in $all_dirs; do
-  rm -rf $LIB/$file
-  if [ ! -d $LIB/$file ]
-  then mkdir $LIB/$file
-  fi
-done
+ARG_MAX=`getconf ARG_MAX 2>/dev/null`
+LENGTH=`expr length "$all_dirs" + 10`
+
+if test -n "$ARG_MAX" && test $LENGTH -lt $ARG_MAX
+then
+  cd $LIB
+  mkdir -p $all_dirs
+  cd ..
+else
+  for file in $all_dirs; do
+    rm -rf $LIB/$file
+    if [ ! -d $LIB/$file ]
+    then mkdir $LIB/$file
+    fi
+  done
+fi


Is getconf and expr length sufficiently portable?
Can't you use
echo "$all_dirs" | xargs mkdir -p
instead?


Oh, even better!
Definitely.  I suspect getconf wouldn't have worked across all the hosts 
we support.





Ready to be installed?

Yes, this version is much better :-)

jeff

Re: [PATCH] fortran: Unshare associate var charlen [PR104228]

[Paul Richard Thomas via Gcc-patches]

Hi Harald and Mikael,

This looks fine to me. OK for all the listed branches.

Thanks for the patch

Paul


On Wed, 2 Feb 2022 at 20:20, Harald Anlauf via Fortran 
wrote:

> Hi Mikael,
>
> Am 29.01.22 um 15:24 schrieb Mikael Morin:
> > Hello,
> >
> > the attached patch is a fix for PR104228.
> > Even if simple, I wouldn’t call it obvious, as it’s involving character
> > length and associate, so I don’t mind some extra review eyes.
>
> I am probably not experienced enough to review this.  Paul?
>
> Nevertheless, I looked at the commits that introduced the code
> you touched.  It appears that these did not cover, maybe even
> avoid the current case where the associate target is not a dummy.
> Your changes seem to make sense and fix the issue.
>
> > Tested on x86_64-pc-linux-gnu. Ok for master/11/10/9?
>
> OK, and thanks for the patch!
>
> Harald
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [PATCH] PR fortran/104311 - [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce

[Paul Richard Thomas via Gcc-patches]

Hi Harald,

Indeed, this is obvious, as you say. OK for the affected branches.

Regards

Paul


On Tue, 1 Feb 2022 at 22:38, Harald Anlauf via Fortran 
wrote:

> Dear Fortranners,
>
> a check in gfc_calculate_transfer_sizes had a bug in the logic:
> it did not trigger for MOLD having a storage size zero when
> arugment SIZE was present.  The attached obvious patch fixes this.
>
> Regtested on x86_64-pc-linux-gnu.  OK for mainline/11/10/9?
>
> Thanks,
> Harald
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: s390: Fix bootstrap -Wformat-diag errors

[Martin Sebor via Gcc-patches]

On 2/3/22 09:45, Martin Liška wrote:

On 2/3/22 17:43, Martin Sebor wrote:

On 2/3/22 01:59, Martin Liška wrote:

On 2/3/22 09:24, Robin Dapp via Gcc-patches wrote:

Hi Martin,


Either this:

    error ("% is unknown", orig_p);

or this would be better:

    error ("attribute % is unknown", orig_p);

The %< %> directives will render it in single quotes like keywords and
identifiers.  Using %qs would render it in double quotes like a 
string,

which wouldn't be quite right.


the x86 backend will print the error message in a different format 
using

single quotes e.g.

   bla.cc:2:5: error: attribute ‘bleh’ argument ‘target’ is unknown


That's a bug in the i386 back end:
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90524


I don't find that better to be frank but maybe it would make sense for
us to also adopt this error message style and not use a different one?
They use %qs, though - or is there an intention to also change x86's
error messages?  I guess in general it's better to have similar error
messages across targets for the same problem.

Regards
  Robin


Hello.

I've just coincidentally fixed the issue with r12-7013-g0415470c8d6620
where I use the same error format as i386 does.


The change repeats the i386 mistake in the s360 back end.  If
the error is supposed to point out that orig_p is not a valid
argument to attribute target as I believe is the case then
the new call should be:

   error ("attribute % argument %qs is unknown", orig_p);

Martin


Yeah, fixed with g:9db03cd0caf6bbde1de302bf3509dc26ca8bff2b.


Great, thank you!

Martin



Cheers,
Martin

Re: [PATCH] Speed up fixincludes.

[Andreas Schwab]

On Feb 03 2022, Martin Liška wrote:

> +cd $LIB
> +echo "$all_dirs" | xargs mkdir -p
> +cd ..
> +

$LIB always contains slashes.

-- 
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] Speed up fixincludes.

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 10:19:37AM -0700, Jeff Law wrote:
> > > Is getconf and expr length sufficiently portable?
> > > Can't you use
> > > echo "$all_dirs" | xargs mkdir -p
> > > instead?
> > 
> > Oh, even better!
> Definitely.  I suspect getconf wouldn't have worked across all the hosts we
> support.
> 
> 
> > 
> > Ready to be installed?
> Yes, this version is much better :-)

Looking at mkinstalldirs, there are comments like:
# Solaris 8's mkdir -p isn't thread-safe.  If you mkdir -p a/b and
# mkdir -p a/c at the same time, both will detect that a is missing,
# one will create a, then the other will try to create a and die with
# a "File exists" error.  This is a problem when calling mkinstalldirs
# from a parallel make.  We use --version in the probe to restrict
# ourselves to GNU mkdir, which is thread-safe.
case $dirmode in
  '')
if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
  echo "mkdir -p -- $*"
  exec mkdir -p -- "$@"
else
  # On NextStep and OpenStep, the 'mkdir' command does not
  # recognize any option.  It will interpret all options as
  # directories to create, and then abort because '.' already
  # exists.
  test -d ./-p && rmdir ./-p
  test -d ./--version && rmdir ./--version
fi
;;

I guess we don't need thread safety as hopefully we don't run this from
multiple jobs concurrently, NextStep/OpenStep are probably long time dead,
but does mkdir -p work now everywhere?

Jakub

[PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

[Patrick Palka via Gcc-patches]

When synthesizing a defaulted comparison op from
maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
noexcept-spec afterwards.

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

PR c++/96242

gcc/cp/ChangeLog:

* pt.cc (maybe_instantiate_noexcept): Keep going after
successfully synthesizing a DECL_MAYBE_DELETED fn.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth15.C: New test.
---
 gcc/cp/pt.cc  |  3 ++-
 .../g++.dg/cpp2a/spaceship-synth15.C  | 22 +++
 2 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 6dd64101ced..03345ed3ed3 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -25986,7 +25986,8 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t 
complain)
   ++function_depth;
   maybe_synthesize_method (fn);
   --function_depth;
-  return !DECL_MAYBE_DELETED (fn);
+  if (DECL_MAYBE_DELETED (fn))
+   return false;
 }
 
   tree fntype = TREE_TYPE (fn);
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C 
b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
new file mode 100644
index 000..00ea6c10474
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
@@ -0,0 +1,22 @@
+// PR c++/96242
+// { dg-do compile { target c++20 } }
+
+#include 
+
+template
+struct X {
+  auto operator<=>(const X&) const noexcept(B) = default;
+  bool operator==(const X&) const noexcept(!B) = default;
+};
+
+X x_t;
+static_assert(noexcept(x_t <=> x_t));
+static_assert(noexcept(x_t < x_t));
+static_assert(!noexcept(x_t == x_t));
+static_assert(!noexcept(x_t != x_t));
+
+X x_f;
+static_assert(!noexcept(x_f <=> x_f));
+static_assert(!noexcept(x_f < x_f));
+static_assert(noexcept(x_f == x_f));
+static_assert(noexcept(x_f != x_f));
-- 
2.35.0

Re: [PATCH] c++, v2: Further address_compare fixes [PR89074]

[Jason Merrill via Gcc-patches]

On 2/3/22 10:52, Jakub Jelinek wrote:

On Tue, Jan 18, 2022 at 05:40:48PM +0100, Jakub Jelinek via Gcc-patches wrote:

About the rest of the patch, I thought I had seen richi comment on IRC (but
can't find the comment now) that these cases where we could give a constant
answer but decide not to because of C++ rules should be handled in the front
end rather than generic code, which makes sense to me; that is, use
folding_initializer only for giving more constant results, not for giving
fewer constant results.  Maybe add another flag for limiting constant
results if we think it's significantly easier to recognize these cases in
fold?


I'm afraid avoiding the match.pd & fold-const code here would be a lot of
work.


Sorry for dropping the ball on this.

Here is a patch that introduces folding_cxx_constexpr flag and documents
that folding_initializer should be used for enabling more folding
optimizations, while folding_cxx_constexpr should be used to prevent
optimizations C++ doesn't allow in the constant expression evaluation.

Ok for trunk if it passes bootstrap/regtest?

2022-02-03  Jakub Jelinek  

PR c++/89074
PR c++/104033
* fold-const.h (folding_initializer): Adjust comment.
(folding_cxx_constexpr): Declare.
* fold-const.cc (folding_initializer): Adjust comment.
(folding_cxx_constexpr): New variable.
(address_compare): Restrict the decl vs. STRING_CST
or vice versa or STRING_CST vs. STRING_CST or
is_global_var != is_global_var optimizations to !folding_cxx_constexpr.
Punt for FUNCTION_DECLs with non-zero offsets.  If folding_initializer,
assume non-aliased functions have non-zero size and have different
addresses.  For folding_cxx_constexpr, punt on comparisons of start
of some object and end of another one, regardless whether it is a decl
or string literal.  Also punt for folding_cxx_constexpr on
STRING_CST vs. STRING_CST comparisons if the two literals could be
overlapping.

* constexpr.cc (cxx_eval_binary_expression): Temporarily set
folding_cxx_constexpr.

* g++.dg/cpp1y/constexpr-89074-3.C: New test.

--- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100
+++ gcc/fold-const.h2022-02-03 15:02:02.700228631 +0100
@@ -20,9 +20,16 @@ along with GCC; see the file COPYING3.
  #ifndef GCC_FOLD_CONST_H
  #define GCC_FOLD_CONST_H
  
-/* Non-zero if we are folding constants inside an initializer; zero

-   otherwise.  */
+/* Nonzero if we are folding constants inside an initializer or a C++
+   manifestly-constant-evaluated context; zero otherwise.
+   Should be used when folding in initializer enables additional
+   optimizations.  */
  extern int folding_initializer;
+/* Nonzer of we are folding C++ manifestly-constant-evaluated context; zero


"Nonzero if"


+   otherwise.
+   Should be used when certain constructs shouldn't be optimized
+   during folding in that context.  */
+extern bool folding_cxx_constexpr;
  
  /* Convert between trees and native memory representation.  */

  extern int native_encode_expr (const_tree, unsigned char *, int, int off = 
-1);
--- gcc/fold-const.cc.jj2022-02-03 14:31:32.243129408 +0100
+++ gcc/fold-const.cc   2022-02-03 16:25:27.541467112 +0100
@@ -86,9 +86,17 @@ along with GCC; see the file COPYING3.
  #include "gimple-range.h"
  
  /* Nonzero if we are folding constants inside an initializer or a C++

-   manifestly-constant-evaluated context; zero otherwise.  */
+   manifestly-constant-evaluated context; zero otherwise.
+   Should be used when folding in initializer enables additional
+   optimizations.  */
  int folding_initializer = 0;
  
+/* Nonzer of we are folding C++ manifestly-constant-evaluated context; zero


"Nonzero if"


+   otherwise.
+   Should be used when certain constructs shouldn't be optimized
+   during folding in that context.  */
+bool folding_cxx_constexpr = false;
+
  /* The following constants represent a bit based encoding of GCC's
 comparison operators.  This encoding simplifies transformations
 on relational comparison operators, such as AND and OR.  */
@@ -16628,41 +16636,91 @@ address_compare (tree_code code, tree ty
HOST_WIDE_INT ioff0 = -1, ioff1 = -1;
off0.is_constant (&ioff0);
off1.is_constant (&ioff1);
-  if ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST)
-   || (TREE_CODE (base0) == STRING_CST && DECL_P (base1))
-   || (TREE_CODE (base0) == STRING_CST
-  && TREE_CODE (base1) == STRING_CST
-  && ioff0 >= 0 && ioff1 >= 0
-  && ioff0 < TREE_STRING_LENGTH (base0)
-  && ioff1 < TREE_STRING_LENGTH (base1)
- /* This is a too conservative test that the STRING_CSTs
-will not end up being string-merged.  */
-  && strncmp (TREE_STRING_POINTER (base0) + ioff0,
-  TREE_STRING_POINTER (base1) + ioff1,
-  MIN (TREE_STRING_LENGTH (base0) - ioff0,
-   

Re: [PATCH] c++: dependence of member's noexcept-spec [PR104079]

[Jason Merrill via Gcc-patches]

On 2/3/22 11:49, Patrick Palka wrote:

Here a stale value of TYPE_DEPENDENT_P/_P_VALID for f's function
type after replacing its DEFERRED_NOEXCEPT with its parsed (dependent)
noexcept-spec leads us to try to instantiate g's noexcept-spec (which
incorrectly appears non-dependent) ahead of time, causing an ICE.

This patch fixes this by clearing TYPE_DEPENDENT_P_VALID in
fixup_deferred_exception_variants appropriately, as is already done in
build_cp_fntype_variant.

This is sufficient for C++17, but not for earlier dialects, because
it's not until C++17 that the noexcept-spec influences dependence of a
function type, so even after this fix we still deem g's noexcept-spec to
be non-dependent and incorrectly try to instantiate it ahead of time.
Since dependence of NOEXCEPT_EXPR is defined in terms of instantiation
dependence, the most appropriate fix for earlier dialects seems to be to
consider dependence of a noexcept-spec for instantiation dependence.

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


OK for trunk now, 11 in about a month.  Since it was reported against 
11, I'm not sure we need to backport further.



PR c++/104079

gcc/cp/ChangeLog:

* pt.cc (value_dependent_noexcept_spec_p): New predicate split
out from ...
(dependent_type_p_r): ... here.
(instantiation_dependent_r): Consider dependence of a
noexcept-specifier
* tree.cc (fixup_deferred_exception_variants): Clear
TYPE_DEPENDENT_P_VALID.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept74.C: New test.
---
  gcc/cp/pt.cc | 39 ++--
  gcc/cp/tree.cc   |  4 +++
  gcc/testsuite/g++.dg/cpp0x/noexcept74.C  | 11 +++
  gcc/testsuite/g++.dg/cpp0x/noexcept74a.C | 12 
  4 files changed, 57 insertions(+), 9 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept74.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept74a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index feee629f1dd..a7dc0bc5f86 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -26979,6 +26979,24 @@ invalid_nontype_parm_type_p (tree type, tsubst_flags_t 
complain)
return true;
  }
  
+/* Returns true iff the noexcept-specifier for TYPE is value-dependent.  */

+
+static bool
+value_dependent_noexcept_spec_p (tree type)
+{
+  if (tree spec = TYPE_RAISES_EXCEPTIONS (type))
+if (tree noex = TREE_PURPOSE (spec))
+  /* Treat DEFERRED_NOEXCEPT as non-dependent, since it doesn't
+affect overload resolution and treating it as dependent breaks
+things.  Same for an unparsed noexcept expression.  */
+  if (TREE_CODE (noex) != DEFERRED_NOEXCEPT
+ && TREE_CODE (noex) != DEFERRED_PARSE
+ && value_dependent_expression_p (noex))
+   return true;
+
+  return false;
+}
+
  /* Returns TRUE if TYPE is dependent, in the sense of [temp.dep.type].
 Assumes that TYPE really is a type, and not the ERROR_MARK_NODE.*/
  
@@ -27033,15 +27051,7 @@ dependent_type_p_r (tree type)

  return true;
if (cxx_dialect >= cxx17)
/* A value-dependent noexcept-specifier makes the type dependent.  */
-   if (tree spec = TYPE_RAISES_EXCEPTIONS (type))
- if (tree noex = TREE_PURPOSE (spec))
-   /* Treat DEFERRED_NOEXCEPT as non-dependent, since it doesn't
-  affect overload resolution and treating it as dependent breaks
-  things.  Same for an unparsed noexcept expression.  */
-   if (TREE_CODE (noex) != DEFERRED_NOEXCEPT
-   && TREE_CODE (noex) != DEFERRED_PARSE
-   && value_dependent_expression_p (noex))
- return true;
+   return value_dependent_noexcept_spec_p (type);
return false;
  }
/* -- an array type constructed from any dependent type or whose
@@ -27850,6 +27860,17 @@ instantiation_dependent_r (tree *tp, int 
*walk_subtrees,
return *tp;
break;
  
+case TEMPLATE_DECL:

+case FUNCTION_DECL:
+  /* Before C++17, the noexcept-specifier wasn't part of the function type
+so it doesn't affect type dependence, but we still want to consider it
+for instantiation dependence.  */
+  if (cxx_dialect < cxx17
+ && DECL_DECLARES_FUNCTION_P (*tp)
+ && value_dependent_noexcept_spec_p (TREE_TYPE (*tp)))
+   return *tp;
+  break;
+
  default:
break;
  }
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index 056f10f13b4..2d8f2c551c0 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -2839,6 +2839,10 @@ fixup_deferred_exception_variants (tree type, tree 
raises)
  }
else
  TYPE_RAISES_EXCEPTIONS (variant) = raises;
+
+   if (!TYPE_DEPENDENT_P (variant))
+ /* We no longer know that it's not type-dependent.  */
+ TYPE_DEPENDENT_P_VALID (variant) = false;
}
  }
  
diff --git a/gcc/testsuite/g++.dg/cpp0x/

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

[Jason Merrill via Gcc-patches]

On 2/3/22 12:04, Patrick Palka wrote:

On Wed, 2 Feb 2022, Jason Merrill wrote:


On 2/2/22 12:09, Patrick Palka wrote:

The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
template arguments before calling iterative_hash_template_arg and
template_args_equal, which would otherwise crash.


Maybe we should handle ARGUMENT_PACK_SELECT in iterative_hash_template_arg and
template_args_equal, rather than their callers?


Like so?  I can't think of a good reason not to handle ARGUMENT_PACK_SELECT
ther, but FWIW it looks like we had such handling in the past, until it
was removed in r7-2082.


Ah, right.  That came after my fix for 67164,

https://gcc.gnu.org/pipermail/gcc-patches/2016-March/443660.html

with that PR, we were seeing ARGUMENT_PACK_SELECT unexpectedly because 
of excessive sharing of template argument lists.  Why are we seeing it 
in satisfaction?


I should have commented the gcc_unreachables better.


-- >8 --

Subject: [PATCH] c++: lambda in pack expansion using outer pack in constraint
  [PR103706]

Here when expanding the pack expansion pattern, the template argument
for T is an ARGUMENT_PACK_SELECT, which during satisfaction of C the
satisfaction cache passes to iterative_hash_template_arg and
template_args_equal, which don't handle ARGUMENT_PACK_SELECT presumably
because at some point it became unnecessary to do so.  Since it now
appears necessary again, this patch reinstates the ARGUMENT_PACK_SELECT
handling that was removed by r7-2082.

PR c++/103706

gcc/cp/ChangeLog:

* pt.cc (iterative_hash_template_arg): Handle ARGUMENT_PACK_SELECT.
(template_args_equal): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda19.C: New test.
---
  gcc/cp/pt.cc   | 10 ++
  gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C | 11 +++
  2 files changed, 17 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index c62822d65f8..644f24b7c09 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -220,6 +220,7 @@ static tree make_argument_pack (tree);
  static void register_parameter_specializations (tree, tree);
  static tree enclosing_instantiation_of (tree tctx);
  static void instantiate_body (tree pattern, tree args, tree d, bool nested);
+static tree argument_pack_select_arg (tree t);
  
  /* Make the current scope suitable for access checking when we are

 processing T.  T can be FUNCTION_DECL for instantiated function
@@ -1783,6 +1784,9 @@ iterative_hash_template_arg (tree arg, hashval_t val)
if (arg == NULL_TREE)
  return iterative_hash_object (arg, val);
  
+  if (TREE_CODE (arg) == ARGUMENT_PACK_SELECT)

+arg = argument_pack_select_arg (arg);
+
if (!TYPE_P (arg))
  /* Strip nop-like things, but not the same as STRIP_NOPS.  */
  while (CONVERT_EXPR_P (arg)
@@ -1796,9 +1800,6 @@ iterative_hash_template_arg (tree arg, hashval_t val)
  
switch (code)

  {
-case ARGUMENT_PACK_SELECT:
-  gcc_unreachable ();
-
  case ERROR_MARK:
return val;
  
@@ -9246,7 +9247,8 @@ template_args_equal (tree ot, tree nt, bool partial_order /* = false */)

else if (ARGUMENT_PACK_P (ot) || ARGUMENT_PACK_P (nt))
  return cp_tree_equal (ot, nt);
else if (TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
-gcc_unreachable ();
+return template_args_equal (argument_pack_select_arg (ot),
+   argument_pack_select_arg (nt));
else if (TYPE_P (nt) || TYPE_P (ot))
  {
if (!(TYPE_P (nt) && TYPE_P (ot)))
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
new file mode 100644
index 000..570e3596f1b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
@@ -0,0 +1,11 @@
+// PR c++/103706
+// { dg-do compile { target c++20 } }
+
+template concept C = __is_same(T, int);
+
+template void f() {
+  ([]() requires C { return T(); }(), ...); // { dg-error "no match" }
+}
+
+template void f(); // { dg-bogus "" }
+template void f(); // { dg-message "required from here" }

Re: [PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

[Jason Merrill via Gcc-patches]

On 2/3/22 14:58, Patrick Palka wrote:

When synthesizing a defaulted comparison op from
maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
noexcept-spec afterwards.


Hmm, there shouldn't be any need to instantiate the noexcept-spec 
afterwards, it should have been set by ~comp_info.



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

PR c++/96242

gcc/cp/ChangeLog:

* pt.cc (maybe_instantiate_noexcept): Keep going after
successfully synthesizing a DECL_MAYBE_DELETED fn.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth15.C: New test.
---
  gcc/cp/pt.cc  |  3 ++-
  .../g++.dg/cpp2a/spaceship-synth15.C  | 22 +++
  2 files changed, 24 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 6dd64101ced..03345ed3ed3 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -25986,7 +25986,8 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t 
complain)
++function_depth;
maybe_synthesize_method (fn);
--function_depth;
-  return !DECL_MAYBE_DELETED (fn);
+  if (DECL_MAYBE_DELETED (fn))
+   return false;
  }
  
tree fntype = TREE_TYPE (fn);

diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C 
b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
new file mode 100644
index 000..00ea6c10474
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
@@ -0,0 +1,22 @@
+// PR c++/96242
+// { dg-do compile { target c++20 } }
+
+#include 
+
+template
+struct X {
+  auto operator<=>(const X&) const noexcept(B) = default;
+  bool operator==(const X&) const noexcept(!B) = default;
+};
+
+X x_t;
+static_assert(noexcept(x_t <=> x_t));
+static_assert(noexcept(x_t < x_t));
+static_assert(!noexcept(x_t == x_t));
+static_assert(!noexcept(x_t != x_t));
+
+X x_f;
+static_assert(!noexcept(x_f <=> x_f));
+static_assert(!noexcept(x_f < x_f));
+static_assert(noexcept(x_f == x_f));
+static_assert(noexcept(x_f != x_f));

Re: [PATCH] c++, v2: Further address_compare fixes [PR89074]

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 03:07:03PM -0500, Jason Merrill wrote:
> > --- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100
> > +++ gcc/fold-const.h2022-02-03 15:02:02.700228631 +0100
> > -/* Non-zero if we are folding constants inside an initializer; zero
> > -   otherwise.  */
> > +/* Nonzero if we are folding constants inside an initializer or a C++
> > +   manifestly-constant-evaluated context; zero otherwise.
> > +   Should be used when folding in initializer enables additional
> > +   optimizations.  */
> >   extern int folding_initializer;
> > +/* Nonzer of we are folding C++ manifestly-constant-evaluated context; zero
> 
> "Nonzero if"

Oops, thanks for catching it.

> > +  if (!folding_cxx_constexpr
> > +  && ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST)
> > + || (TREE_CODE (base0) == STRING_CST && DECL_P (base1))
> > + || (TREE_CODE (base0) == STRING_CST
> > + && TREE_CODE (base1) == STRING_CST
> > + && ioff0 >= 0 && ioff1 >= 0
> > + && ioff0 < TREE_STRING_LENGTH (base0)
> > + && ioff1 < TREE_STRING_LENGTH (base1)
> > + /* This is a too conservative test that the STRING_CSTs
> > +will not end up being string-merged.  */
> > + && strncmp (TREE_STRING_POINTER (base0) + ioff0,
> > + TREE_STRING_POINTER (base1) + ioff1,
> > + MIN (TREE_STRING_LENGTH (base0) - ioff0,
> > +  TREE_STRING_LENGTH (base1) - ioff1)) != 0)))
> >   ;
> > -  else if (!DECL_P (base0) || !DECL_P (base1))
> > +  /* Punt on non-zero offsets from functions.  */
> > +  else if ((TREE_CODE (base0) == FUNCTION_DECL && ioff0)
> > +  || (TREE_CODE (base1) == FUNCTION_DECL && ioff1))
> > +return 2;
> > +  else if ((!DECL_P (base0)
> > +   && (!folding_cxx_constexpr || TREE_CODE (base0) != STRING_CST))
> > +  || (!DECL_P (base1)
> > +  && (!folding_cxx_constexpr || TREE_CODE (base1) != STRING_CST)))
> 
> I think it would be clearer to leave the !DECL_P case alone and add
> 
> /* In C++ it is unspecified, and so non-constant, whether two
>equivalent strings have the same address.  */
> else if (folding_cxx_constexpr
>  && (TREE_CODE (base0) == STRING_CST
>  || TREE_CODE (base1) == STRING_CST)

The point was to let the first if handle for
!folding_cxx_constexpr the cases with STRING_CST
as one or both operands and if that falls through, return 2.

But I guess it could be rewritten as:
  if (!DECL_P (base0) && TREE_CODE (base0) != STRING_CST)
return 2;
  if (!DECL_P (base1) && TREE_CODE (base1) != STRING_CST)
return 2;
  /* Punt on non-zero offsets from functions.  */
  if ((TREE_CODE (base0) == FUNCTION_DECL && ioff0)
  || (TREE_CODE (base1) == FUNCTION_DECL && ioff1))
return 2;
  if (!folding_cxx_constexpr
  && (TREE_CODE (base0) == STRING_CST
  || TREE_CODE (base1) == STRING_CST))
{
  if (DECL_P (base0)
  || DECL_P (base1)
  || (TREE_CODE (base0) == TREE_CODE (base1)
  && ioff0 >= 0 && ioff1 >= 0
  && ioff0 < TREE_STRING_LENGTH (base0)
  && ioff1 < TREE_STRING_LENGTH (base1)
  /* This is a too conservative test that the STRING_CSTs
 will not end up being string-merged.  */
  && strncmp (TREE_STRING_POINTER (base0) + ioff0,
  TREE_STRING_POINTER (base1) + ioff1,
  MIN (TREE_STRING_LENGTH (base0) - ioff0,
   TREE_STRING_LENGTH (base1) - ioff1)) != 0))
;
  else
return 2;
}
  else
...

Jakub

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

[Patrick Palka via Gcc-patches]

On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill  wrote:
>
> On 2/3/22 12:04, Patrick Palka wrote:
> > On Wed, 2 Feb 2022, Jason Merrill wrote:
> >
> >> On 2/2/22 12:09, Patrick Palka wrote:
> >>> The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
> >>> template arguments before calling iterative_hash_template_arg and
> >>> template_args_equal, which would otherwise crash.
> >>
> >> Maybe we should handle ARGUMENT_PACK_SELECT in iterative_hash_template_arg 
> >> and
> >> template_args_equal, rather than their callers?
> >
> > Like so?  I can't think of a good reason not to handle ARGUMENT_PACK_SELECT
> > ther, but FWIW it looks like we had such handling in the past, until it
> > was removed in r7-2082.
>
> Ah, right.  That came after my fix for 67164,
>
> https://gcc.gnu.org/pipermail/gcc-patches/2016-March/443660.html
>
> with that PR, we were seeing ARGUMENT_PACK_SELECT unexpectedly because
> of excessive sharing of template argument lists.  Why are we seeing it
> in satisfaction?

When instantiating the lambda inside the pack expansion, we call
tsubst_lambda_expr with args={ARGUMENT_PACK_SELECT}, wherein we add
these args to the lambda's LAMBDA_EXPR_REGEN_INFO for use later during
satisfaction.  And during satisfaction we key the satisfaction cache
by those template arguments before any substitution happens.  So we
didn't get a chance to unwrap the ARGUMENT_PACK_SELECT arguments yet,
which IIUC happens transparently during substitution.

>
> I should have commented the gcc_unreachables better.
>
> > -- >8 --
> >
> > Subject: [PATCH] c++: lambda in pack expansion using outer pack in 
> > constraint
> >   [PR103706]
> >
> > Here when expanding the pack expansion pattern, the template argument
> > for T is an ARGUMENT_PACK_SELECT, which during satisfaction of C the
> > satisfaction cache passes to iterative_hash_template_arg and
> > template_args_equal, which don't handle ARGUMENT_PACK_SELECT presumably
> > because at some point it became unnecessary to do so.  Since it now
> > appears necessary again, this patch reinstates the ARGUMENT_PACK_SELECT
> > handling that was removed by r7-2082.
> >
> >   PR c++/103706
> >
> > gcc/cp/ChangeLog:
> >
> >   * pt.cc (iterative_hash_template_arg): Handle ARGUMENT_PACK_SELECT.
> >   (template_args_equal): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * g++.dg/cpp2a/concepts-lambda19.C: New test.
> > ---
> >   gcc/cp/pt.cc   | 10 ++
> >   gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C | 11 +++
> >   2 files changed, 17 insertions(+), 4 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
> >
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index c62822d65f8..644f24b7c09 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -220,6 +220,7 @@ static tree make_argument_pack (tree);
> >   static void register_parameter_specializations (tree, tree);
> >   static tree enclosing_instantiation_of (tree tctx);
> >   static void instantiate_body (tree pattern, tree args, tree d, bool 
> > nested);
> > +static tree argument_pack_select_arg (tree t);
> >
> >   /* Make the current scope suitable for access checking when we are
> >  processing T.  T can be FUNCTION_DECL for instantiated function
> > @@ -1783,6 +1784,9 @@ iterative_hash_template_arg (tree arg, hashval_t val)
> > if (arg == NULL_TREE)
> >   return iterative_hash_object (arg, val);
> >
> > +  if (TREE_CODE (arg) == ARGUMENT_PACK_SELECT)
> > +arg = argument_pack_select_arg (arg);
> > +
> > if (!TYPE_P (arg))
> >   /* Strip nop-like things, but not the same as STRIP_NOPS.  */
> >   while (CONVERT_EXPR_P (arg)
> > @@ -1796,9 +1800,6 @@ iterative_hash_template_arg (tree arg, hashval_t val)
> >
> > switch (code)
> >   {
> > -case ARGUMENT_PACK_SELECT:
> > -  gcc_unreachable ();
> > -
> >   case ERROR_MARK:
> > return val;
> >
> > @@ -9246,7 +9247,8 @@ template_args_equal (tree ot, tree nt, bool 
> > partial_order /* = false */)
> > else if (ARGUMENT_PACK_P (ot) || ARGUMENT_PACK_P (nt))
> >   return cp_tree_equal (ot, nt);
> > else if (TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
> > -gcc_unreachable ();
> > +return template_args_equal (argument_pack_select_arg (ot),
> > + argument_pack_select_arg (nt));
> > else if (TYPE_P (nt) || TYPE_P (ot))
> >   {
> > if (!(TYPE_P (nt) && TYPE_P (ot)))
> > diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C 
> > b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
> > new file mode 100644
> > index 000..570e3596f1b
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
> > @@ -0,0 +1,11 @@
> > +// PR c++/103706
> > +// { dg-do compile { target c++20 } }
> > +
> > +template concept C = __is_same(T, int);
> > +
> > +template void f() {
> > +  ([]() requires C { return T(); }(), ...); // { dg-error "no match" }
> > +}
> > +
> > 

[PATCH] PR target/104345: Use nvptx "set" instruction for cond ? -1 : 0.

[Roger Sayle]

This patch addresses the "increased register pressure" regression on
nvptx-none caused by my change to transition the backend to a
STORE_FLAG_VALUE = 1 target.  This improved code generation for the
more common case of producing 0/1 Boolean values, but unfortunately
made things marginally worse when a 0/-1 mask value is desired.
Unfortunately, nvptx kernels are extremely sensitive to changes in
register usage, which was observable in the reported PR.

This patch provides optimizations for -(cond ? 1 : 0), effectively
simplify this into cond ? -1 : 0, where these ternary operators are
provided by nvptx's selp instruction, and for the specific case of
SImode, using (restoring) nvptx's "set" instruction (which avoids
the need for a predicate register).

This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu
with a "make" and "make -k check" with no new failures.  Unfortunately,
the exact register usage of a nvptx kernel depends upon the version of
the Cuda drivers being used (and the hardware), but I believe this
change should resolve the PR (for Thomas) by improving code generation
for the cases that regressed.  Ok for mainline?


2022-02-03  Roger Sayle  

gcc/ChangeLog
PR target/104345
* config/nvptx/nvptx.md (sel_true): Fix indentation.
(sel_false): Likewise.
(define_code_iterator eqne): New code iterator for EQ and NE.
(*selp_neg_): New define_insn_and_split to optimize
the negation of a selp instruction.
(*selp_not_): New define_insn_and_split to optimize
the bitwise not of a selp instruction.
(*setcc_int): Use set instruction for neg:SI of a selp.

gcc/testsuite/ChangeLog
PR target/104345
* gcc.target/nvptx/neg-selp.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 92768dd..651ba20 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -892,7 +892,7 @@
 
 (define_insn "sel_true"
   [(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
-(if_then_else:HSDIM
+   (if_then_else:HSDIM
  (ne (match_operand:BI 1 "nvptx_register_operand" "R") (const_int 0))
  (match_operand:HSDIM 2 "nvptx_nonmemory_operand" "Ri")
  (match_operand:HSDIM 3 "nvptx_nonmemory_operand" "Ri")))]
@@ -901,7 +901,7 @@
 
 (define_insn "sel_true"
   [(set (match_operand:SDFM 0 "nvptx_register_operand" "=R")
-(if_then_else:SDFM
+   (if_then_else:SDFM
  (ne (match_operand:BI 1 "nvptx_register_operand" "R") (const_int 0))
  (match_operand:SDFM 2 "nvptx_nonmemory_operand" "RF")
  (match_operand:SDFM 3 "nvptx_nonmemory_operand" "RF")))]
@@ -910,7 +910,7 @@
 
 (define_insn "sel_false"
   [(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
-(if_then_else:HSDIM
+   (if_then_else:HSDIM
  (eq (match_operand:BI 1 "nvptx_register_operand" "R") (const_int 0))
  (match_operand:HSDIM 2 "nvptx_nonmemory_operand" "Ri")
  (match_operand:HSDIM 3 "nvptx_nonmemory_operand" "Ri")))]
@@ -919,13 +919,63 @@
 
 (define_insn "sel_false"
   [(set (match_operand:SDFM 0 "nvptx_register_operand" "=R")
-(if_then_else:SDFM
+   (if_then_else:SDFM
  (eq (match_operand:BI 1 "nvptx_register_operand" "R") (const_int 0))
  (match_operand:SDFM 2 "nvptx_nonmemory_operand" "RF")
  (match_operand:SDFM 3 "nvptx_nonmemory_operand" "RF")))]
   ""
   "%.\\tselp%t0\\t%0, %3, %2, %1;")
 
+(define_code_iterator eqne [eq ne])
+
+;; Split negation of a predicate into a conditional move.
+(define_insn_and_split "*selp_neg_"
+  [(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
+   (neg:HSDIM (eqne:HSDIM
+(match_operand:BI 1 "nvptx_register_operand" "R")
+(const_int 0]
+  ""
+  "#"
+  "&& 1"
+  [(set (match_dup 0)
+   (if_then_else:HSDIM
+ (eqne (match_dup 1) (const_int 0))
+ (const_int -1)
+ (const_int 0)))])
+
+;; Split bitwise not of a predicate into a conditional move.
+(define_insn_and_split "*selp_not_"
+  [(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
+   (not:HSDIM (eqne:HSDIM
+(match_operand:BI 1 "nvptx_register_operand" "R")
+(const_int 0]
+  ""
+  "#"
+  "&& 1"
+  [(set (match_dup 0)
+   (if_then_else:HSDIM
+ (eqne (match_dup 1) (const_int 0))
+ (const_int -2)
+ (const_int -1)))])
+
+(define_insn "*setcc_int"
+  [(set (match_operand:SI 0 "nvptx_register_operand" "=R")
+   (neg:SI
+ (match_operator:SI 1 "nvptx_comparison_operator"
+   [(match_operand:HSDIM 2 "nvptx_register_operand" "R")
+(match_operand:HSDIM 3 "nvptx_nonmemory_operand" "Ri")])))]
+  ""
+  "%.\\tset%t0%c1\\t%0, %2, %3;")
+
+(define_insn "*setcc_int"
+  [(set (match_operand:SI 0 "nvptx_register_operand" "=R")
+   (neg:SI
+ (match_operator:SI 1 "nvptx_float

Re: [PATCH] c++, v2: Further address_compare fixes [PR89074]

[Jason Merrill via Gcc-patches]

On 2/3/22 15:33, Jakub Jelinek wrote:

On Thu, Feb 03, 2022 at 03:07:03PM -0500, Jason Merrill wrote:

--- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100
+++ gcc/fold-const.h2022-02-03 15:02:02.700228631 +0100
-/* Non-zero if we are folding constants inside an initializer; zero
-   otherwise.  */
+/* Nonzero if we are folding constants inside an initializer or a C++
+   manifestly-constant-evaluated context; zero otherwise.
+   Should be used when folding in initializer enables additional
+   optimizations.  */
   extern int folding_initializer;
+/* Nonzer of we are folding C++ manifestly-constant-evaluated context; zero


"Nonzero if"


Oops, thanks for catching it.


+  if (!folding_cxx_constexpr
+  && ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST)
+ || (TREE_CODE (base0) == STRING_CST && DECL_P (base1))
+ || (TREE_CODE (base0) == STRING_CST
+ && TREE_CODE (base1) == STRING_CST
+ && ioff0 >= 0 && ioff1 >= 0
+ && ioff0 < TREE_STRING_LENGTH (base0)
+ && ioff1 < TREE_STRING_LENGTH (base1)
+ /* This is a too conservative test that the STRING_CSTs
+will not end up being string-merged.  */
+ && strncmp (TREE_STRING_POINTER (base0) + ioff0,
+ TREE_STRING_POINTER (base1) + ioff1,
+ MIN (TREE_STRING_LENGTH (base0) - ioff0,
+  TREE_STRING_LENGTH (base1) - ioff1)) != 0)))
   ;
-  else if (!DECL_P (base0) || !DECL_P (base1))
+  /* Punt on non-zero offsets from functions.  */
+  else if ((TREE_CODE (base0) == FUNCTION_DECL && ioff0)
+  || (TREE_CODE (base1) == FUNCTION_DECL && ioff1))
+return 2;
+  else if ((!DECL_P (base0)
+   && (!folding_cxx_constexpr || TREE_CODE (base0) != STRING_CST))
+  || (!DECL_P (base1)
+  && (!folding_cxx_constexpr || TREE_CODE (base1) != STRING_CST)))


I think it would be clearer to leave the !DECL_P case alone and add

/* In C++ it is unspecified, and so non-constant, whether two
equivalent strings have the same address.  */
else if (folding_cxx_constexpr
  && (TREE_CODE (base0) == STRING_CST
  || TREE_CODE (base1) == STRING_CST)


The point was to let the first if handle for
!folding_cxx_constexpr the cases with STRING_CST
as one or both operands and if that falls through, return 2.


Ah, I see.  And then for folding_cxx_constexpr you have your new code 
toward the bottom of the function that can say they're unequal in some 
cases.  Can you combine the STRING_CST handling for both values of 
folding_cxx_constexpr instead of having them so far apart?


Jason

Re: [PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

[Patrick Palka via Gcc-patches]

On Thu, 3 Feb 2022, Jason Merrill wrote:

> On 2/3/22 14:58, Patrick Palka wrote:
> > When synthesizing a defaulted comparison op from
> > maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
> > noexcept-spec afterwards.
> 
> Hmm, there shouldn't be any need to instantiate the noexcept-spec afterwards,
> it should have been set by ~comp_info.

It appears the comp_info class sets the noexcept-spec only if the
comparison function hasn't been declared with an explicit noexcept-spec.
Otherwise the class doesn't touch the noexcept-spec, and it remains a
DEFERRED_NOEXCEPT with non-NULL DEFERRED_NOEXCEPT_PATTERN.

> 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk and perhaps 11?
> > 
> > PR c++/96242
> > 
> > gcc/cp/ChangeLog:
> > 
> > * pt.cc (maybe_instantiate_noexcept): Keep going after
> > successfully synthesizing a DECL_MAYBE_DELETED fn.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp2a/spaceship-synth15.C: New test.
> > ---
> >   gcc/cp/pt.cc  |  3 ++-
> >   .../g++.dg/cpp2a/spaceship-synth15.C  | 22 +++
> >   2 files changed, 24 insertions(+), 1 deletion(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
> > 
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 6dd64101ced..03345ed3ed3 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -25986,7 +25986,8 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t
> > complain)
> > ++function_depth;
> > maybe_synthesize_method (fn);
> > --function_depth;
> > -  return !DECL_MAYBE_DELETED (fn);
> > +  if (DECL_MAYBE_DELETED (fn))
> > +   return false;
> >   }
> >   tree fntype = TREE_TYPE (fn);
> > diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
> > b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
> > new file mode 100644
> > index 000..00ea6c10474
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
> > @@ -0,0 +1,22 @@
> > +// PR c++/96242
> > +// { dg-do compile { target c++20 } }
> > +
> > +#include 
> > +
> > +template
> > +struct X {
> > +  auto operator<=>(const X&) const noexcept(B) = default;
> > +  bool operator==(const X&) const noexcept(!B) = default;
> > +};
> > +
> > +X x_t;
> > +static_assert(noexcept(x_t <=> x_t));
> > +static_assert(noexcept(x_t < x_t));
> > +static_assert(!noexcept(x_t == x_t));
> > +static_assert(!noexcept(x_t != x_t));
> > +
> > +X x_f;
> > +static_assert(!noexcept(x_f <=> x_f));
> > +static_assert(!noexcept(x_f < x_f));
> > +static_assert(noexcept(x_f == x_f));
> > +static_assert(noexcept(x_f != x_f));
> 
> 

Re: [PATCH] Speed up fixincludes.

[Martin Liška]

On 2/3/22 19:44, Andreas Schwab wrote:

On Feb 03 2022, Martin Liška wrote:


+cd $LIB
+echo "$all_dirs" | xargs mkdir -p
+cd ..
+


$LIB always contains slashes.



And what is the problem? You're too brief..

Martin

Re: [PATCH] c++, v2: Further address_compare fixes [PR89074]

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote:
> > > I think it would be clearer to leave the !DECL_P case alone and add
> > > 
> > > /* In C++ it is unspecified, and so non-constant, whether two
> > > equivalent strings have the same address.  */
> > > else if (folding_cxx_constexpr
> > >   && (TREE_CODE (base0) == STRING_CST
> > >   || TREE_CODE (base1) == STRING_CST)
> > 
> > The point was to let the first if handle for
> > !folding_cxx_constexpr the cases with STRING_CST
> > as one or both operands and if that falls through, return 2.
> 
> Ah, I see.  And then for folding_cxx_constexpr you have your new code toward
> the bottom of the function that can say they're unequal in some cases.  Can
> you combine the STRING_CST handling for both values of folding_cxx_constexpr
> instead of having them so far apart?

Not easily, because for the folding_cxx_constexpr case it primarily reuses
the code from the last else if - computing sizes of objects and checking
if one is at a start of one and another at the end of the other.

One further option would be to compute early flags like
  enum { OFF_POS_START, OFF_POS_MIDDLE, OFF_POS_END } pos0, pos1;
and then just use them or ignore them in the decisions later.

Jakub

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

[Jason Merrill via Gcc-patches]

On 2/3/22 15:55, Patrick Palka wrote:

On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill  wrote:


On 2/3/22 12:04, Patrick Palka wrote:

On Wed, 2 Feb 2022, Jason Merrill wrote:


On 2/2/22 12:09, Patrick Palka wrote:

The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
template arguments before calling iterative_hash_template_arg and
template_args_equal, which would otherwise crash.


Maybe we should handle ARGUMENT_PACK_SELECT in iterative_hash_template_arg and
template_args_equal, rather than their callers?


Like so?  I can't think of a good reason not to handle ARGUMENT_PACK_SELECT
ther, but FWIW it looks like we had such handling in the past, until it
was removed in r7-2082.


Ah, right.  That came after my fix for 67164,

https://gcc.gnu.org/pipermail/gcc-patches/2016-March/443660.html

with that PR, we were seeing ARGUMENT_PACK_SELECT unexpectedly because
of excessive sharing of template argument lists.  Why are we seeing it
in satisfaction?


When instantiating the lambda inside the pack expansion, we call
tsubst_lambda_expr with args={ARGUMENT_PACK_SELECT}, wherein we add
these args to the lambda's LAMBDA_EXPR_REGEN_INFO for use later during
satisfaction.


Yes, that seems like the problem: We're remembering a transient artifact 
in LAMBDA_EXPR_REGEN_INFO.  Presumably if the pack is longer than 1, the 
lambdas for all elements of the expansion will have the same 
ARGUMENT_PACK_SELECT in their LAMBDA_EXPR_REGEN_INFO, so they will all 
think they're in the final element.


I guess tsubst_lambda_expr needs to replace an 'args' with 
ARGUMENT_PACK_SELECT in it with a copy.  Or we could do away with 
ARGUMENT_PACK_SELECT entirely in favor of tsubst_pack_expansion using 
separate TREE_VECs for each element substitution.



And during satisfaction we key the satisfaction cache
by those template arguments before any substitution happens.  So we
didn't get a chance to unwrap the ARGUMENT_PACK_SELECT arguments yet,
which IIUC happens transparently during substitution.



I should have commented the gcc_unreachables better.


-- >8 --

Subject: [PATCH] c++: lambda in pack expansion using outer pack in constraint
   [PR103706]

Here when expanding the pack expansion pattern, the template argument
for T is an ARGUMENT_PACK_SELECT, which during satisfaction of C the
satisfaction cache passes to iterative_hash_template_arg and
template_args_equal, which don't handle ARGUMENT_PACK_SELECT presumably
because at some point it became unnecessary to do so.  Since it now
appears necessary again, this patch reinstates the ARGUMENT_PACK_SELECT
handling that was removed by r7-2082.

   PR c++/103706

gcc/cp/ChangeLog:

   * pt.cc (iterative_hash_template_arg): Handle ARGUMENT_PACK_SELECT.
   (template_args_equal): Likewise.

gcc/testsuite/ChangeLog:

   * g++.dg/cpp2a/concepts-lambda19.C: New test.
---
   gcc/cp/pt.cc   | 10 ++
   gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C | 11 +++
   2 files changed, 17 insertions(+), 4 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index c62822d65f8..644f24b7c09 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -220,6 +220,7 @@ static tree make_argument_pack (tree);
   static void register_parameter_specializations (tree, tree);
   static tree enclosing_instantiation_of (tree tctx);
   static void instantiate_body (tree pattern, tree args, tree d, bool nested);
+static tree argument_pack_select_arg (tree t);

   /* Make the current scope suitable for access checking when we are
  processing T.  T can be FUNCTION_DECL for instantiated function
@@ -1783,6 +1784,9 @@ iterative_hash_template_arg (tree arg, hashval_t val)
 if (arg == NULL_TREE)
   return iterative_hash_object (arg, val);

+  if (TREE_CODE (arg) == ARGUMENT_PACK_SELECT)
+arg = argument_pack_select_arg (arg);
+
 if (!TYPE_P (arg))
   /* Strip nop-like things, but not the same as STRIP_NOPS.  */
   while (CONVERT_EXPR_P (arg)
@@ -1796,9 +1800,6 @@ iterative_hash_template_arg (tree arg, hashval_t val)

 switch (code)
   {
-case ARGUMENT_PACK_SELECT:
-  gcc_unreachable ();
-
   case ERROR_MARK:
 return val;

@@ -9246,7 +9247,8 @@ template_args_equal (tree ot, tree nt, bool partial_order 
/* = false */)
 else if (ARGUMENT_PACK_P (ot) || ARGUMENT_PACK_P (nt))
   return cp_tree_equal (ot, nt);
 else if (TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
-gcc_unreachable ();
+return template_args_equal (argument_pack_select_arg (ot),
+ argument_pack_select_arg (nt));
 else if (TYPE_P (nt) || TYPE_P (ot))
   {
 if (!(TYPE_P (nt) && TYPE_P (ot)))
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
new file mode 100644
index 000..570e3596f1b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
@@ -0

Re: [PATCH] Speed up fixincludes.

[Marek Polacek via Gcc-patches]

On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote:
> On 2/3/22 19:44, Andreas Schwab wrote:
> > On Feb 03 2022, Martin Liška wrote:
> > 
> > > +cd $LIB
> > > +echo "$all_dirs" | xargs mkdir -p
> > > +cd ..
> > > +
> > 
> > $LIB always contains slashes.
> > 
> 
> And what is the problem? You're too brief..

I guess his point is that if you do
cd a/b/c/
then
cd ..
will not get you back to where you started.  Perhaps you could use
pushd/popd instead.

Marek

Re: [PATCH] c++, v2: Further address_compare fixes [PR89074]

[Jason Merrill via Gcc-patches]

On 2/3/22 16:18, Jakub Jelinek wrote:

On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote:

I think it would be clearer to leave the !DECL_P case alone and add

/* In C++ it is unspecified, and so non-constant, whether two
 equivalent strings have the same address.  */
else if (folding_cxx_constexpr
   && (TREE_CODE (base0) == STRING_CST
   || TREE_CODE (base1) == STRING_CST)


The point was to let the first if handle for
!folding_cxx_constexpr the cases with STRING_CST
as one or both operands and if that falls through, return 2.


Ah, I see.  And then for folding_cxx_constexpr you have your new code toward
the bottom of the function that can say they're unequal in some cases.  Can
you combine the STRING_CST handling for both values of folding_cxx_constexpr
instead of having them so far apart?


Not easily, because for the folding_cxx_constexpr case it primarily reuses
the code from the last else if - computing sizes of objects and checking
if one is at a start of one and another at the end of the other.


And the !folding_cxx_constexpr case shouldn't also use that code?


One further option would be to compute early flags like
   enum { OFF_POS_START, OFF_POS_MIDDLE, OFF_POS_END } pos0, pos1;
and then just use them or ignore them in the decisions later.


If that helps to refactor a bit, sure.

Jason

[PATCH] i386: Do not use %ecx DRAP for functions that use __builtin_eh_return [PR104362]

[Uros Bizjak via Gcc-patches]

%ecx can't be used for both DRAP register and eh_return.  Adjust find_drap_reg
to choose %edi for functions that uses __builtin_eh_return to avoid the assert
in ix86_expand_epilogue that enforces this rule.

2022-02-03  Uroš Bizjak  

gcc/ChangeLog:

PR target/104362
* config/i386/i386.cc (find_drap_reg): For 32bit targets
return DI_REG if function uses __builtin_eh_return.

gcc/testsuite/ChangeLog:

PR target/104362
* gcc.target/i386/pr104362.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Pushed to master, will be backported to gcc-11.

Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index ad5a5caa413..dd5584fb8ed 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -7400,7 +7400,8 @@ find_drap_reg (void)
 register in such case.  */
   if (DECL_STATIC_CHAIN (decl)
  || cfun->machine->no_caller_saved_registers
- || crtl->tail_call_emit)
+ || crtl->tail_call_emit
+ || crtl->calls_eh_return)
return DI_REG;
 
   /* Reuse static chain register if it isn't used for parameter
diff --git a/gcc/testsuite/gcc.target/i386/pr104362.c 
b/gcc/testsuite/gcc.target/i386/pr104362.c
new file mode 100644
index 000..5e5422e2679
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr104362.c
@@ -0,0 +1,24 @@
+/* PR target/104362 */
+/* { dg-do compile } */
+/* { dg-options "-mavx512f" } */
+
+struct _Unwind_Context
+{
+  void *ra;
+  char array[48];
+};
+
+extern long uw_install_context_1 (struct _Unwind_Context *);
+
+void
+_Unwind_RaiseException (void)
+{
+  struct _Unwind_Context this_context, cur_context;
+  __builtin_memset(&this_context, 55, sizeof(this_context));
+  long offset = uw_install_context_1 (&this_context);
+  __builtin_memcpy (&this_context, &cur_context,
+sizeof (struct _Unwind_Context));
+  void *handler = __builtin_frob_return_addr ((&cur_context)->ra);
+  uw_install_context_1 (&cur_context);
+  __builtin_eh_return (offset, handler);
+}

Re: [PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

[Jason Merrill via Gcc-patches]

On 2/3/22 16:06, Patrick Palka wrote:

On Thu, 3 Feb 2022, Jason Merrill wrote:


On 2/3/22 14:58, Patrick Palka wrote:

When synthesizing a defaulted comparison op from
maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
noexcept-spec afterwards.


Hmm, there shouldn't be any need to instantiate the noexcept-spec afterwards,
it should have been set by ~comp_info.


It appears the comp_info class sets the noexcept-spec only if the
comparison function hasn't been declared with an explicit noexcept-spec.
Otherwise the class doesn't touch the noexcept-spec, and it remains a
DEFERRED_NOEXCEPT with non-NULL DEFERRED_NOEXCEPT_PATTERN.


Ah, I see.  So perhaps we should entirely skip the current 
DECL_MAYBE_DELETED handling in maybe_instantiate_noexcept if we have 
DEFERRED_NOEXCEPT with non-null DEFERRED_NOEXCEPT_PATTERN (which seems 
to want another macro)?



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

PR c++/96242

gcc/cp/ChangeLog:

* pt.cc (maybe_instantiate_noexcept): Keep going after
successfully synthesizing a DECL_MAYBE_DELETED fn.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth15.C: New test.
---
   gcc/cp/pt.cc  |  3 ++-
   .../g++.dg/cpp2a/spaceship-synth15.C  | 22 +++
   2 files changed, 24 insertions(+), 1 deletion(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 6dd64101ced..03345ed3ed3 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -25986,7 +25986,8 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t
complain)
 ++function_depth;
 maybe_synthesize_method (fn);
 --function_depth;
-  return !DECL_MAYBE_DELETED (fn);
+  if (DECL_MAYBE_DELETED (fn))
+   return false;
   }
   tree fntype = TREE_TYPE (fn);
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
new file mode 100644
index 000..00ea6c10474
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth15.C
@@ -0,0 +1,22 @@
+// PR c++/96242
+// { dg-do compile { target c++20 } }
+
+#include 
+
+template
+struct X {
+  auto operator<=>(const X&) const noexcept(B) = default;
+  bool operator==(const X&) const noexcept(!B) = default;
+};
+
+X x_t;
+static_assert(noexcept(x_t <=> x_t));
+static_assert(noexcept(x_t < x_t));
+static_assert(!noexcept(x_t == x_t));
+static_assert(!noexcept(x_t != x_t));
+
+X x_f;
+static_assert(!noexcept(x_f <=> x_f));
+static_assert(!noexcept(x_f < x_f));
+static_assert(noexcept(x_f == x_f));
+static_assert(noexcept(x_f != x_f));

Re: [PATCH] Speed up fixincludes.

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 03, 2022 at 04:29:39PM -0500, Marek Polacek wrote:
> On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote:
> > On 2/3/22 19:44, Andreas Schwab wrote:
> > > On Feb 03 2022, Martin Liška wrote:
> > > 
> > > > +cd $LIB
> > > > +echo "$all_dirs" | xargs mkdir -p
> > > > +cd ..
> > > > +
> > > 
> > > $LIB always contains slashes.
> > > 
> > 
> > And what is the problem? You're too brief..
> 
> I guess his point is that if you do
> cd a/b/c/
> then
> cd ..
> will not get you back to where you started.  Perhaps you could use
> pushd/popd instead.

Or a subshell.

Jakub