[PATCH] c/99275 - fix missing space in diagnostic

[Richard Biener]

This fixes a missing space as reported by translators.

Pused as obvious.

2021-02-26  Richard Biener  

PR c/99275
* builtins.c (warn_string_no_nul): Fix diagnostic formatting.
---
 gcc/builtins.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index d804b0e6617..18be93c0f3b 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -1178,7 +1178,7 @@ warn_string_no_nul (location_t loc, tree expr, const char 
*fname,
}
   else
warned = warning_at (loc, OPT_Wstringop_overread,
-"%qsargument missing terminating nul",
+"%qs argument missing terminating nul",
 fname);
 }
 
-- 
2.26.2

[PATCH] Honor --disable-decimal-float in building _Float128 support.

[Michael Meissner via Gcc-patches]

Honor --disable-decimal-float in building _Float128 support.

Joseph Myers reported that my previous patch to add conversions between
_Float128 and the Decimal types was still being built even if GCC was
configured with the --disable-decimal-float option.  This patch fixes that by
only building the conversion functions if both _Float128 and Decimal support
are built into GCC.

In addition, I removed the dependency on the target having a valid stdio.h file
to declare sprintf in building _sprintfkf.c.

Finally I noticed I had a mismatch in the _sprintfkf.h include file, and I
fixed that.

Joseph, does this patch fix your problem?

I have built cross compilers on the x86 with/without --disable-decimal-float
and the conversion functions are not built if --disable-decimal-float was used.
I have built stage1 compilers with all three long double formats on the native
little endian system, and I verified that they conversions are only built if
Decimal support is eabled.

As I post this, the bootstrap builds are going on.  Assuming the bootstrap
builds are successful, can I check this patch into the master branch?

libgcc/
2021-02-26  Michael Meissner  

* config.host (powerpc*-*-linux): Move the Decimal/_Float128
* conversions into t-float128-dec.
* config/rs6000/_sprintfkf.c: Do not include stdio.h.  Include
_sprintfkf.h.
* config/rs6000/_sprintfkf.h (__sprintfkf): Update calling
signature.
(sprintf): Add declaration.
* config/rs6000/t-float128 (fp128_dec_funcs): Move to
t-float128-dec.
(fp128_decstr_funcs): Move to t-float128-dec.
(ibm128_dec_funcs): Move to t-float128-dec.
(fp128_dec_objs): Move to t-float128-dec.
(fp128_decstr_objs): Move to t-float128-dec.
(ibm128_dec_objs): Move to t-float128-dec.
(FP128_CFLAGS_DECIMAL): Move to t-float128-dec.
(IBM128_CFLAGS_DECIMAL): Move to t-float128-dec.
* config/rs6000/t-float128-dec: New file.
* configure.ac (libgcc_cv_powerpc_float128_dec): New variable, set
to yes if both _Float128 and Decimal support are available.
* configure: Regenerate.

---
 libgcc/config.host  |  4 +++
 libgcc/config/rs6000/_sprintfkf.c   |  4 ++-
 libgcc/config/rs6000/_sprintfkf.h   |  2 +-
 libgcc/config/rs6000/t-float128 | 42 +
 libgcc/config/rs6000/t-float128-dec | 37 +
 libgcc/configure| 22 ++-
 libgcc/configure.ac |  8 ++
 7 files changed, 80 insertions(+), 39 deletions(-)
 create mode 100644 libgcc/config/rs6000/t-float128-dec

diff --git a/libgcc/config.host b/libgcc/config.host
index f808b61be70..b5b4b0b3ba0 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1220,6 +1220,10 @@ powerpc*-*-linux*)
tmake_file="${tmake_file} rs6000/t-float128"
fi
 
+   if test $libgcc_cv_powerpc_float128_dec = yes; then
+   tmake_file="${tmake_file} rs6000/t-float128-dec"
+   fi
+
if test $libgcc_cv_powerpc_float128_hw = yes; then
tmake_file="${tmake_file} rs6000/t-float128-hw"
fi
diff --git a/libgcc/config/rs6000/_sprintfkf.c 
b/libgcc/config/rs6000/_sprintfkf.c
index a7fdfb483c9..b367861fcc3 100644
--- a/libgcc/config/rs6000/_sprintfkf.c
+++ b/libgcc/config/rs6000/_sprintfkf.c
@@ -27,7 +27,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #include 
 #include 
 #include 
-#include 
+#include <_sprintfkf.h>
+
+extern int sprintf (char *restrict, const char *restrict, ...);
 
 /* This function must be built with IBM 128-bit as long double, so that we can
access the strfroml function if do not have an IEEE 128-bit version, and if
diff --git a/libgcc/config/rs6000/_sprintfkf.h 
b/libgcc/config/rs6000/_sprintfkf.h
index 637d104c882..22b245d2cbb 100644
--- a/libgcc/config/rs6000/_sprintfkf.h
+++ b/libgcc/config/rs6000/_sprintfkf.h
@@ -24,5 +24,5 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 /* Declaration of the conversion function to IEEE 128-bit floating point from
string using snprintf.  */
 
-extern int __sprintfkf (char *restrict, const char *restrict, ...);
+extern int __sprintfkf (char *restrict, const char *restrict, _Float128);
 
diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
index 6fb1a3d871b..bbc66465050 100644
--- a/libgcc/config/rs6000/t-float128
+++ b/libgcc/config/rs6000/t-float128
@@ -22,18 +22,6 @@ fp128_softfp_static_obj  = $(addsuffix 
-sw$(objext),$(fp128_softfp_funcs))
 fp128_softfp_shared_obj= $(addsuffix 
-sw_s$(objext),$(fp128_softfp_funcs))
 fp128_softfp_obj   = $(fp128_softfp_static_obj) $(fp128_softfp_shared_obj)
 
-# Decimal <-> _Float128 conversions
-fp128_dec_funcs= _kf_to_sd _kf_to_dd _kf_to_td \
- _sd_to_kf _dd_to_kf _td_to_kf
-
-# _Float128 to/from string 

[pushed] c++: Fix class NTTP constness handling [PR98810]

[Jason Merrill via Gcc-patches]

Here, when substituting still-dependent args into an alias template, we see
a non-const type because the default argument is non-const, and is not a
template parm object because it's still dependent.

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

gcc/cp/ChangeLog:

PR c++/98810
* pt.c (tsubst_copy) [VIEW_CONVERT_EXPR]: Add const
to a class non-type template argument that needs it.

gcc/testsuite/ChangeLog:

PR c++/98810
* g++.dg/cpp2a/nontype-class-defarg1.C: New test.
---
 gcc/cp/pt.c   | 27 ---
 .../g++.dg/cpp2a/nontype-class-defarg1.C  |  6 +
 2 files changed, 24 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class-defarg1.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3576e0effb6..5fafee472a5 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -16826,18 +16826,27 @@ tsubst_copy (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
{
  /* Wrapper to make a C++20 template parameter object const.  */
  op = tsubst_copy (op, args, complain, in_decl);
- if (TREE_CODE (op) == TEMPLATE_PARM_INDEX)
+ if (!CP_TYPE_CONST_P (TREE_TYPE (op)))
{
+ /* The template argument is not const, presumably because
+it is still dependent, and so not the const template parm
+object.  */
  tree type = tsubst (TREE_TYPE (t), args, complain, in_decl);
- return build1 (code, type, op);
-   }
- else
-   {
- gcc_assert (CP_TYPE_CONST_P (TREE_TYPE (op))
- || (TREE_CODE (op) == IMPLICIT_CONV_EXPR
- && IMPLICIT_CONV_EXPR_NONTYPE_ARG (op)));
- return op;
+ gcc_checking_assert (same_type_ignoring_top_level_qualifiers_p
+  (type, TREE_TYPE (op)));
+ if (TREE_CODE (op) == CONSTRUCTOR
+ || TREE_CODE (op) == IMPLICIT_CONV_EXPR)
+   {
+ /* Don't add a wrapper to these.  */
+ op = copy_node (op);
+ TREE_TYPE (op) = type;
+   }
+ else
+   /* Do add a wrapper otherwise (in particular, if op is
+  another TEMPLATE_PARM_INDEX).  */
+   op = build1 (code, type, op);
}
+ return op;
}
  /* force_paren_expr can also create a VIEW_CONVERT_EXPR.  */
  else if (code == VIEW_CONVERT_EXPR && REF_PARENTHESIZED_P (t))
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class-defarg1.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class-defarg1.C
new file mode 100644
index 000..85e50ff8069
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class-defarg1.C
@@ -0,0 +1,6 @@
+// PR c++/98810
+// { dg-do compile { target c++20 } }
+
+template  struct a {};
+template  s = a  {}> using b = a ;
+template  constexpr auto g (const b  &) { return true; };

base-commit: 28af4b9a7c5ee9f6c6fc111210639eb2f64bddcd
-- 
2.27.0

Re: PING [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)

[Jason Merrill via Gcc-patches]

On 2/25/21 6:47 PM, Jeff Law wrote:



On 2/23/21 2:52 PM, Jason Merrill wrote:


I don't see how the issue here depends on the artificiality of the vptr;

That's what I was trying to get at -- is DECL_ARTIFICIAL really a good
way to detect these kinds of cases.  It sounds like it likely isn't, but
it may also be the best we can do.  I'm not sure yet.





I'd expect to see the same problem with a data member.  The problem is
that a D base subobject is smaller than a complete D object, and in
this case the base subobject is allocated such that if it were a full
D object, it would overlap the end of E.  And we're checking the
MEM_REF as though accessing a full D object, so we get a warning.

The general issue about the confusion between complete and as-base
types is PR 22488; I have various thoughts about a proper fix, but
there have always been higher-priority things to work on.

One possible approach to this PR is that we don't need to check an
intermediate _REF; in

MEM[(struct D *) + 24B]._vptr.D

we aren't loading a whole D, we're only looking at the _vptr, which is
within the bounds of E.



That raises a really interesting question.  What's the right bounds to
use with these kinds of constructs.  Should we be looking at D's type
(struct E) or struct D?  I'm not sure there's a one-size-fits-all answer
here and I don't think we have any other context go help guide us.


struct E, definitely; the actual bounds of the struct D object are 
unknown here.  Unless, I suppose, we were to work harder to find the D 
FIELD_DECL in E that corresponds to this offset and get its DECL_SIZE, but:


We know the bounds of the E object, and we can determine that _vptr.D is 
within those bounds; that seems sufficient to decide not to warn.


Jason

Re: [PATCH] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

[Jason Merrill via Gcc-patches]

On 2/25/21 5:41 PM, Marek Polacek wrote:

On Thu, Feb 25, 2021 at 10:59:49AM -0500, Jason Merrill wrote:

On 2/12/21 6:12 PM, Marek Polacek wrote:

We represent deduction guides with FUNCTION_DECLs, but they are built
without DECL_CONTEXT


Hmm, that seems wrong: "A deduction-guide shall be declared in the
same scope as the corresponding class template and, for a member class
template, with the same access."  But it probably isn't necessary to change
this:


leading to an ICE in type_dependent_expression_p
on the assert that the type of a function template with no dependent
(innermost!) template arguments must be non-dependent.  Consider the
attached class-deduction79.C: we create a deduction guide:

template G(T)-> E::G

we deduce T and create a partial instantiation:

G(T) -> E::G [with T = int]

And then do_class_deduction wants to create a CALL_EXPR from the above
using build_new_function_call -> build_over_call which calls mark_used
-> maybe_instantiate_noexcept -> type_dependent_expression_p.

There, the innermost template arguments are non-dependent (), but
the fntype is dependent -- the return type is a TYPENAME_TYPE, and
since we have no DECL_CONTEXT, this check holds:

/* Otherwise, if the function decl isn't from a dependent scope, it can't be
   type-dependent.  Checking this is important for functions with auto 
return
   type, which looks like a dependent type.  */
if (TREE_CODE (expression) == FUNCTION_DECL
&& !(DECL_CLASS_SCOPE_P (expression)
 && dependent_type_p (DECL_CONTEXT (expression)))

whereupon we ICE.

Experiments with setting DECL_CONTEXT didn't pan out.


In c8 of the PR it looks like you were using the class itself as
DECL_CONTEXT; the quote above says that the right context is the enclosing
scope of the class.


Sadly, using CP_TYPE_CONTEXT (type) would result in a crash in
retrieve_specialization:

   /* There should be as many levels of arguments as there are
  levels of parameters.  */
   gcc_assert (TMPL_ARGS_DEPTH (args)
   == (TREE_CODE (tmpl) == TEMPLATE_DECL
   ? TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (tmpl))
   : template_class_depth (DECL_CONTEXT (tmpl;


Yeah, probably simpler not to bother.


So perhaps we
just want to skip the assert for deduction guides, because they are
a little special.  Better ideas solicited.


In c3 you mention that one of the variants broke with r269093; this is
because my change to check CLASSTYPE_TEMPLATE_INSTANTIATION is false for the
template pattern itself (E).


And the original test started with my r11-1713 because using TREE_TYPE
directly instead of decltype (which is a non-deduced context) means we
can deduced from the argument.
  

But I think probably the right answer is to defer this deduction until the
enclosing scope is non-dependent, i.e. (untested)


Thanks.  That mostly works, except the new class-deduction-aggr[89].C
tests.  Consider 8:

namespace N {
template  struct S {
   template  S(T, U);
};
} // namespace N
template  struct E {
   template  struct G { T t; };
   void fn() { G{N::S{'a', 1}}; }
};

void
g ()
{
   E<1> e;
   e.fn ();
}

With your patch, when in do_class_deduction when processing_template_decl,
we just return.  When we call do_class_deduction again when p_t_d is 0,
maybe_aggr_guide returns early here:

   if (!CP_AGGREGATE_TYPE_P (type))
 return NULL_TREE

because G is not complete (and rightly so, we didn't instantiate it).  So
we aren't able to deduce the template parameters.  I'm not sure if I should
pursue this direction further.  :(


I think so; we just need to test CP_AGGREGATE_TYPE_P on the original 
template pattern instead of the instantiation E<1>::G.


Jason

Re: rs6000: Fix ICE in rs6000_init_builtins when compiling with -mcpu=440 [PR99279]

[Peter Bergner via Gcc-patches]

On 2/25/21 7:08 PM, David Edelsohn wrote:
> On Thu, Feb 25, 2021 at 8:05 PM Peter Bergner  wrote:
>>
>> The initialization of compat builtins assumes the builtin we are creating
>> a compatible builtin for exists and ICEs if it doesn't.  However, there are
>> valid reasons why some builtins are disabled for a particular compile.
>> In this case, the MMA builtins are disabled for -mcpu=440 (and other cpus),
>> so instead of ICEing, we should just skip adding the MMA compat builtin.
>>
>> This passed bootstrap and regtesting on powerpc64-linux, with running the
>> testsuite in both 32-bit and 64-bit modes, with no regressions.
>> Ok for mainline?
> 
> Okay.

Thanks, pushed.



On 2/25/21 7:09 PM, Segher Boessenkool wrote:
> On Thu, Feb 25, 2021 at 07:05:26PM -0600, Peter Bergner wrote:
>> The compat builtin patch was approved for backporting to GCC10, so we'll
>> need this fix to go along with it.
> 
> Okay for that as well of course.

Thanks, I'll give this a day or two and then push the two to gcc10.
Do you want them committed separately or squashed into one commit
since the 2nd patch fixes the issue in the first patch?

Peter

Re: [PATCH v4 1/2] MIPS: unaligned load: use SImode for SUBREG if OK (PR98996)

[YunQiang Su via Gcc-patches]

Jeff Law via Gcc-patches  于2021年2月26日周五 上午10:57写道：
>
>
>
> On 2/23/21 3:05 AM, YunQiang Su wrote:
> > It is found by ada s-pack96.adb ftbfs, due to 96bit load: 96 = 64 + 32.
> > While the 32bit pair of l r is mark as SUBREG, so they are
> > not in SImode, make it fail to find suitable insn.
> >
> > gcc/ChangeLog:
> >
> >   PR target/98996
> >   * config/mips/mips.c (mips_expand_ext_as_unaligned_load):
> >   If TARGET_64BIT and dest is SUBREG, we check the width, if it
> >   equal to SImode, we use SImode operation, just like what we are
> >   doing for REG one.
> Thanks.  I fixed some minor whitespace issues and installed both patches
> in this series.

Thank you so much.

> jeff
>


-- 
YunQiang Su

Re: [PATCH v4 1/2] MIPS: unaligned load: use SImode for SUBREG if OK (PR98996)

[Jeff Law via Gcc-patches]

On 2/23/21 3:05 AM, YunQiang Su wrote:
> It is found by ada s-pack96.adb ftbfs, due to 96bit load: 96 = 64 + 32.
> While the 32bit pair of l r is mark as SUBREG, so they are
> not in SImode, make it fail to find suitable insn.
>
> gcc/ChangeLog:
>
>   PR target/98996
>   * config/mips/mips.c (mips_expand_ext_as_unaligned_load):
>   If TARGET_64BIT and dest is SUBREG, we check the width, if it
>   equal to SImode, we use SImode operation, just like what we are
>   doing for REG one.
Thanks.  I fixed some minor whitespace issues and installed both patches
in this series.
jeff

[pushed] builtins: Fix typos in warn_for_access [PR99278]

[Marek Polacek via Gcc-patches]

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

gcc/ChangeLog:

* builtins.c (warn_for_access): Fix typos.
---
 gcc/builtins.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 42150cee0bd..d804b0e6617 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4282,7 +4282,7 @@ warn_for_access (location_t loc, tree func, tree exp, int 
opt, tree range[2],
  ? warning_n (loc, OPT_Wstringop_overread,
   tree_to_uhwi (range[0]),
   (maybe
-   ? G_("%K%qD may reade %E byte from a region "
+   ? G_("%K%qD may read %E byte from a region "
 "of size %E")
: G_("%K%qD reading %E byte from a region "
 "of size %E")),
@@ -4352,7 +4352,7 @@ warn_for_access (location_t loc, tree func, tree exp, int 
opt, tree range[2],
 warned = (func
  ? warning_n (loc, OPT_Wstringop_overread,
   tree_to_uhwi (range[0]),
-  "%K%qD epecting %E byte in a region of size %E",
+  "%K%qD expecting %E byte in a region of size %E",
   "%K%qD expecting %E bytes in a region of size %E",
   exp, func, range[0], size)
  : warning_n (loc, OPT_Wstringop_overread,
@@ -4380,7 +4380,7 @@ warn_for_access (location_t loc, tree func, tree exp, int 
opt, tree range[2],
"a region of size %E",
exp, func, range[0], range[1], size)
  : warning_at (loc, OPT_Wstringop_overread,
-   "%Kexpectting between %E and %E bytes in "
+   "%Kexpecting between %E and %E bytes in "
"a region of size %E",
exp, range[0], range[1], size));
 

base-commit: 2fbed0dc6c4dffcfd586a990fc3d2aeb7e00d521
-- 
2.29.2

Re: rs6000: Fix ICE in rs6000_init_builtins when compiling with -mcpu=440 [PR99279]

[Segher Boessenkool]

On Thu, Feb 25, 2021 at 07:05:26PM -0600, Peter Bergner wrote:
> The initialization of compat builtins assumes the builtin we are creating
> a compatible builtin for exists and ICEs if it doesn't.  However, there are
> valid reasons why some builtins are disabled for a particular compile.
> In this case, the MMA builtins are disabled for -mcpu=440 (and other cpus),
> so instead of ICEing, we should just skip adding the MMA compat builtin.
> 
> This passed bootstrap and regtesting on powerpc64-linux, with running the
> testsuite in both 32-bit and 64-bit modes, with no regressions.
> Ok for mainline?

Okay, thank you!

> The compat builtin patch was approved for backporting to GCC10, so we'll
> need this fix to go along with it.

Okay for that as well of course.


Segher


>   PR target/99279
>   * config/rs6000/rs6000-call.c (rs6000_init_builtins): Replace assert
>   with an "if" test.

Re: rs6000: Fix ICE in rs6000_init_builtins when compiling with -mcpu=440 [PR99279]

[David Edelsohn via Gcc-patches]

On Thu, Feb 25, 2021 at 8:05 PM Peter Bergner  wrote:
>
> The initialization of compat builtins assumes the builtin we are creating
> a compatible builtin for exists and ICEs if it doesn't.  However, there are
> valid reasons why some builtins are disabled for a particular compile.
> In this case, the MMA builtins are disabled for -mcpu=440 (and other cpus),
> so instead of ICEing, we should just skip adding the MMA compat builtin.
>
> This passed bootstrap and regtesting on powerpc64-linux, with running the
> testsuite in both 32-bit and 64-bit modes, with no regressions.
> Ok for mainline?

Okay.

Thanks, David

>
> The compat builtin patch was approved for backporting to GCC10, so we'll
> need this fix to go along with it.
>
> Peter
>
>
> 2021-02-25  Peter Bergner  
>
> gcc/
> PR target/99279
> * config/rs6000/rs6000-call.c (rs6000_init_builtins): Replace assert
> with an "if" test.
>
> diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
> index d2bd03e..f567625 100644
> --- a/gcc/config/rs6000/rs6000-call.c
> +++ b/gcc/config/rs6000/rs6000-call.c
> @@ -13468,9 +13468,9 @@ rs6000_init_builtins (void)
>for (i = 0; i < ARRAY_SIZE (bdesc_compat); i++, d++)
>  {
>tree decl = rs6000_builtin_decls[(int)d->code];
> -  gcc_assert (decl != NULL);
> -  add_builtin_function (d->name, TREE_TYPE (decl), (int)d->code,
> -   BUILT_IN_MD, NULL, NULL_TREE);
> +  if (decl != NULL)
> +   add_builtin_function (d->name, TREE_TYPE (decl), (int)d->code,
> + BUILT_IN_MD, NULL, NULL_TREE);
>  }
>  }
>

rs6000: Fix ICE in rs6000_init_builtins when compiling with -mcpu=440 [PR99279]

[Peter Bergner via Gcc-patches]

The initialization of compat builtins assumes the builtin we are creating
a compatible builtin for exists and ICEs if it doesn't.  However, there are
valid reasons why some builtins are disabled for a particular compile.
In this case, the MMA builtins are disabled for -mcpu=440 (and other cpus),
so instead of ICEing, we should just skip adding the MMA compat builtin.

This passed bootstrap and regtesting on powerpc64-linux, with running the
testsuite in both 32-bit and 64-bit modes, with no regressions.
Ok for mainline?

The compat builtin patch was approved for backporting to GCC10, so we'll
need this fix to go along with it.

Peter


2021-02-25  Peter Bergner  

gcc/
PR target/99279
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Replace assert
with an "if" test.

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index d2bd03e..f567625 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -13468,9 +13468,9 @@ rs6000_init_builtins (void)
   for (i = 0; i < ARRAY_SIZE (bdesc_compat); i++, d++)
 {
   tree decl = rs6000_builtin_decls[(int)d->code];
-  gcc_assert (decl != NULL);
-  add_builtin_function (d->name, TREE_TYPE (decl), (int)d->code,
-   BUILT_IN_MD, NULL, NULL_TREE);
+  if (decl != NULL)
+   add_builtin_function (d->name, TREE_TYPE (decl), (int)d->code,
+ BUILT_IN_MD, NULL, NULL_TREE);
 }
 }
 

[committed] analyzer: eliminate dedupe_candidate [PR96374]

[David Malcolm via Gcc-patches]

In gcc/analyzer/diagnostic-manager.cc the code partitions
saved_diagnostic instances by dedupe_key, and tries to find the "best"
saved_diagnostic for each dedupe_key.

Ideally we would find the shortest feasible path for each
saved_diagnostic and pick the winner in each deduplication set.

Currently we merely approximate that by finding the shortest path for
each saved_diagnostic, and checking to see if it feasible, rejecting
the saved_diagnostic if it is not.  The "shortest path, or nothing if
it's infeasible" is not the same as the "shortest feasible path", and
this leads to false negatives, where we reject valid diagnostics,
tracked as PR analyzer/96374.

I have been attempting various fixes for this, but in doing so I
found that the existing structure of the code makes things unnecessarily
awkward: each dedupe_set had a a dedupe_candidate which stored the
best epath for that set, creating it from the shortest path when that
dedupe_candidate was constructed.

This patch eliminates the dedupe_candidate, instead storing the best
epath for each saved_diagnostic within the saved_diagnostic itself,
along with any feasibility_problem, and eliminating a redundant "status"
field.  The logic for finding the best epath is moved to a new
epath_finder::get_best_epath subroutine, introducing an epath_finder
class to give a place to cache state.

This patch merely copies over the existing logic to
epath_finder::get_best_epath, so no functional change is intended,
but the patch simplifies the logic and makes it much easier to
experiment with alternate implementations as I try to fix
PR analyzer/96374.

I attempted another version of this patch in which I added a dedupe_set
class and partitioned saved_diagnostics into them as the diagnostics were
added, but in this earlier iteration of the patch there were regressions
e.g. from gcc.dg/analyzer/zlib-4.c where 4 deduplication sets became 3.
The issue was that the deduplication logic needs source locations, which
need gimple statements, and the stmt_finder needs epaths to run.  Finding
the epaths needs the full egraph (as opposed to the egraph in its state
at the time when the diagnostic is saved).  Hence the partitioning needs to
happen after the egraph is fully explored.  I backed up the earlier patch
kit to:
  
https://dmalcolm.fedorapeople.org/gcc/2021-02-23/feasibility-v0.3-relative-to-72d78655a91bb2f89ac4432cfd6374380d6f9987/

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7410-ga505fad4dd4d93b6d642995d7df320aa40949568.

gcc/analyzer/ChangeLog:
PR analyzer/96374
* diagnostic-manager.cc (class epath_finder): New.
(epath_finder::get_best_epath): New.
(saved_diagnostic::saved_diagnostic): Update for replacement of
m_state and m_epath_length with m_best_epath.
(saved_diagnostic::~saved_diagnostic): Delete m_best_epath.
(saved_diagnostic::to_json): Update "path_length" to be optional.
(saved_diagnostic::calc_best_epath): New, based on
dedupe_winners::add and parts of dedupe_key::dedupe_key.
(saved_diagnostic::get_epath_length): New.
(saved_diagnostic::add_duplicate): New.
(dedupe_key::dedupe_key): Drop epath param.  Move invocation of
stmt_finder to saved_diagnostic::calc_best_epath.
(class dedupe_candidate): Delete.
(class dedupe_hash_map_traits): Update to use saved_diagnotic *
rather than dedupe_candidate * as the value_type/compare_type.
(dedupe_winners::~dedupe_winners): Don't delete the values.
(dedupe_winners::add): Convert param from shortest_exploded_paths to
epath_finder.  Drop "eg" param.  Drop dedupe_candidate, moving
path generation and feasiblity checking to
epath_finder::get_best_epath.  Update winner-selection for move
of epaths from dedupe_candidate to saved_diagnostic.
(dedupe_winners::emit_best):  Update for removal of class
dedupe_candidate.
(dedupe_winners::map_t): Update to use saved_diagnotic * rather
than dedupe_candidate * as the value_type/compare_type.
(diagnostic_manager::emit_saved_diagnostics): Move
shortest_exploded_paths instance into epath_finder and pass that
around instead.
(diagnostic_manager::emit_saved_diagnostic): Drop epath, stmt
and num_dupes params, instead getting these from the
saved_diagnostic.  Use correct location in inform_n call.
* diagnostic-manager.h (class epath_finder): New forward decl.
(saved_diagnostic::status): Drop enum.
(saved_diagnostic::set_feasible): Drop.
(saved_diagnostic::set_infeasible): Drop.
(saved_diagnostic::get_status): Drop.
(saved_diagnostic::calc_best_epath): New decl.
(saved_diagnostic::get_best_epath): New decl.
(saved_diagnostic::get_epath_length): New decl.
(saved_diagnostic::set_epath_length): Drop.

libgo patch committed: Ensure 8 byte atomicity on ppc64

[Ian Lance Taylor via Gcc-patches]

This libgo patch by Lynn Boger ensures 8 byte atomicity in memmove and
memset on ppc64.

Go requires that pointer moves are done 8 bytes at a time, so that the
concurrent garbage collector always sees an entire pointer value.
gccgo uses libc's memmove and memset which does not require that, and
there are some cases where an 8 byte move might be done as 4+4.

To enforce 8 byte moves for memmove and memset, this adds a C
implementation in libgo/runtime for memmove and memset to be used on
ppc64le and ppc64.  Asm implementations were considered but discarded
to avoid different implementations for different target ISAs.

This fixes https://golang.org/issue/41428.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
0689d6198ac4f1c00ba4722e0321f0cedfdd6d16
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 217bdd55f1d..9806b9da1e1 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-78a840e4940159a66072237f6b002ab79f441b79
+56cf388da8d04bbd3824c4df34d77a8afa69749b
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index eea7ff15aed..dec98756673 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -454,6 +454,7 @@ runtime_files = \
runtime/go-fieldtrack.c \
runtime/go-matherr.c \
runtime/go-memclr.c \
+   runtime/go-memmove.c \
runtime/go-memequal.c \
runtime/go-nanotime.c \
runtime/go-now.c \
diff --git a/libgo/go/runtime/stubs.go b/libgo/go/runtime/stubs.go
index 6d20c384330..dea7234b3ad 100644
--- a/libgo/go/runtime/stubs.go
+++ b/libgo/go/runtime/stubs.go
@@ -106,9 +106,7 @@ func reflect_memclrNoHeapPointers(ptr unsafe.Pointer, n 
uintptr) {
memclrNoHeapPointers(ptr, n)
 }
 
-// memmove copies n bytes from "from" to "to".
 //go:noescape
-//extern __builtin_memmove
 func memmove(to, from unsafe.Pointer, n uintptr)
 
 //go:linkname reflect_memmove reflect.memmove
diff --git a/libgo/runtime/go-memclr.c b/libgo/runtime/go-memclr.c
index b5d4975e57d..53b81178539 100644
--- a/libgo/runtime/go-memclr.c
+++ b/libgo/runtime/go-memclr.c
@@ -13,5 +13,48 @@ void memclrNoHeapPointers(void *, uintptr)
 void
 memclrNoHeapPointers (void *p1, uintptr len)
 {
-  __builtin_memset (p1, 0, len);
+
+#if !defined(__PPC64__)
+  __builtin_memset(p1, 0, len);
+#else
+  int64 rem,drem,i;
+  uint64 offset;
+  volatile uint64 *vp;
+
+  if (len == 0) {
+return;
+  }
+  rem = len;
+
+  offset = (uint64)p1 % 8;
+  // This memset is OK since it can't contain
+  // an 8 byte aligned pointer.
+  if ((rem < 8) || (offset > 0 && offset+rem <= 16)) {
+__builtin_memset(p1, 0, rem);
+return;
+  }
+  // Move initial bytes to get to 8 byte boundary
+  if (offset > 0) {
+__builtin_memset(p1, 0, 8-offset);
+p1 = (void*)((char*)p1+8-offset);
+rem -= 8-offset;
+  }
+
+  // If at least 8 bytes left, clear
+  drem = rem>>3;
+
+  vp = (volatile uint64*)(p1);
+  // Without the use of volatile here, the compiler
+  // might convert the loop into a memset.
+  for (i=0; i 0) {
+__builtin_memset (p1, 0, rem);
+  }
+#endif
 }
diff --git a/libgo/runtime/go-memmove.c b/libgo/runtime/go-memmove.c
new file mode 100644
index 000..1ca3f4822b7
--- /dev/null
+++ b/libgo/runtime/go-memmove.c
@@ -0,0 +1,89 @@
+/* go-memmove.c -- memmove
+
+   Copyright 2021 The Go Authors. All rights reserved.
+   Use of this source code is governed by a BSD-style
+   license that can be found in the LICENSE file.  */
+
+#include "runtime.h"
+
+void gomemmove(void *, void *, uintptr)
+  __asm__ (GOSYM_PREFIX "runtime.memmove")
+  __attribute__ ((no_split_stack));
+
+// This implementation is necessary since
+// the __builtin_memmove might use __libc_memmove
+// which doesn't require atomicity of 8 byte
+// moves.
+
+void
+gomemmove (void *dst, void *src, uintptr len)
+{
+#if !defined(__PPC64__)
+  __builtin_memmove(dst, src, len);
+#else
+  uint64 offset, tail;
+  int64 rem;
+  uint64 dwords;
+  uint64 i;
+  char *bdst,*bsrc;
+
+  rem = len;
+
+  if (len == 0) {
+   return;
+  }
+
+  // If src and dst don't have the same 8 byte alignment then
+  // there is no issue with copying pointer atomicity. Use the
+  // builtin.
+  if (((uint64)dst % 8) != ((uint64)src % 8) || len < 8) {
+   __builtin_memmove(dst, src, len);
+   return;
+  }
+
+  // Length >= 8 && same ptr alignment
+  offset = (uint64)dst % 8;
+
+  // If not 8 byte alignment, move the intial bytes.
+  if (offset > 0) {
+   __builtin_memmove(dst, src, 8-offset);
+   dst += (8-offset);
+   src += (8-offset);
+   rem -= (8-offset);
+  }
+
+  // Move the tail bytes to make the backward move
+  // easier.
+  tail = rem % 8;
+  if (tail > 0) {
+   __builtin_memmove(dst+rem-tail, src+rem-tail, tail);
+   rem -= tail;
+  }
+
+  if (rem == 0) {
+   return;
+  }
+
+  // Must now be 8 byte alignment and 

New German PO file for 'gcc' (version 11.1-b20210207)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

https://translationproject.org/latest/gcc/de.po

(This file, 'gcc-11.1-b20210207.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao via Gcc-patches]

Hi, Kees,

Just noticed that you didn’t add -fauto-var-init-approach=D to the command line.
[qinzhao@localhost uninit]$ cat t8.c
a() { char b[1]; }
[qinzhao@localhost uninit]$ sh t
/home/qinzhao/Install/latest/bin/gcc -ftrivial-auto-var-init=pattern 
-fauto-var-init-approach=D t8.c -S
t8.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | a() { char b[1]; }
  | ^

Without -fauto-var-init-approach=D, I have the same error as yours. 

(This option is just temporary, its purpose is to compare two different 
implementations for “zero” initialization,
Since “pattern” initialization is added later after the comparison, “pattern” 
initialization does not support the 
Default “A” approach. I plan to make the default as “D” in the final version of 
the patch).

So, please add “-fauto-var-init-approach=D” along with 
“-ftrivial-auto-var-init=pattern/zero” for the testing.

Sorry for the confusion.


> On Feb 25, 2021, at 2:00 PM, Kees Cook  wrote:
> 
> On Thu, Feb 25, 2021 at 12:15:01PM -0600, Qing Zhao wrote:
>>> On Feb 24, 2021, at 10:41 PM, Kees Cook  wrote:
>>> [...]
>>> test_stackinit: trailing_hole_none ok
>>> test_stackinit: packed_none ok
>>> test_stackinit: user ok
>>> test_stackinit: failures: 8
>> 
>> Does the above testing include “pattern initialization” in addition to “zero 
>> initialization”?
> 
> This was from the zero-init case. I've just tested pattern-init now and
> it actually crashes GCC. I minimized the test case to this:
> 
> $ cat main.i
> a() { char b[1]; }
> $ gcc -ftrivial-auto-var-init=pattern -c /dev/null main.i
> main.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
>1 | a() { char b[1]; }
>  | ^
> main.i: In function ‘a’:
> main.i:1:12: internal compiler error: in gimplify_init_ctor_eval, at
> gimplify.c:4873
>1 | a() { char b[1]; }
>  |^
> 0x69740d gimplify_init_ctor_eval
>../../../gcc/gcc/gimplify.c:4873
> 0xb5ac8f gimplify_init_constructor
>../../../gcc/gcc/gimplify.c:5320
> 0xb6b68a gimplify_modify_expr
>../../../gcc/gcc/gimplify.c:5952
> 0xb533ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), 
> int)
>../../../gcc/gcc/gimplify.c:14262
> 0xb56b26 gimplify_stmt(tree_node**, gimple**)
>../../../gcc/gcc/gimplify.c:7056
> 0xb68e6e gimplify_and_add(tree_node*, gimple**)
>../../../gcc/gcc/gimplify.c:489
> 0xb68e6e gimple_add_init_for_auto_var
>../../../gcc/gcc/gimplify.c:1892
> 0xb68e6e gimplify_decl_expr
>../../../gcc/gcc/gimplify.c:2010
> 0xb53bd6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), 
> int)
>../../../gcc/gcc/gimplify.c:14459
> 0xb56b26 gimplify_stmt(tree_node**, gimple**)
>../../../gcc/gcc/gimplify.c:7056
> 0xb5727d gimplify_bind_expr
>../../../gcc/gcc/gimplify.c:1421
> 0xb536f0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), 
> int)
>../../../gcc/gcc/gimplify.c:14463
> 0xb6ccc9 gimplify_stmt(tree_node**, gimple**)
>../../../gcc/gcc/gimplify.c:7056
> 0xb6ccc9 gimplify_body(tree_node*, bool)
>../../../gcc/gcc/gimplify.c:15498
> 0xb6d0ed gimplify_function_tree(tree_node*)
>../../../gcc/gcc/gimplify.c:15652
> 0x9ae8d7 cgraph_node::analyze()
>../../../gcc/gcc/cgraphunit.c:670
> 0x9b13a7 analyze_functions
>../../../gcc/gcc/cgraphunit.c:1233
> 0x9b1f9d symbol_table::finalize_compilation_unit()
>../../../gcc/gcc/cgraphunit.c:2511
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> 
>>> struct test_..._hole instance = { .two = ..., };
>>> 
>>> or
>>> 
>>> struct test_..._hole instance = { .one = ...,
>>>   .two = ...,
>>>   .three = ...,
>>>   .four = ...,
>>> 
>>> };
>> 
>> So, when the structure variables are not statically initialized, all the 
>> paddings are initialized correctly by the compiler?
> 
> For the zero case, yes. (Usually such happen via copies into stack from from 
> .rodata
> sections, or accidentally from already-initialized copies.)
> 
>> In the current implementation, when the auto variable is explicitly 
>> initialized, compiler will do nothing.
>> Looks like for structure variables we need some special handling to 
>> initialize the paddings.
>> Need to study this a little bit and see how to fix it.
> 
> Deterministic padding init is a big part of this defense since that's
> where the bulk of the really hard-to-find problems have existed (i.e. in
> padding holes in structures that got copied around).

Okay, I will try to fix this. 
Clang doesn’t have this issue, right? 
> 
>>> The last case is for switch variables outside of case statements, like
>>> "var" here:
>>> 
>>> switch (path) {
>>> unsigned long var;
>>> 
>>> 

Re: [RFC] ldist: Recognize rawmemchr loop patterns

[Jeff Law via Gcc-patches]

On 2/25/21 10:01 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> Ping
Given this is not a regression it needs to wait for gcc-12.
jeff

Re: PING [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)

[Jeff Law via Gcc-patches]

On 2/23/21 2:52 PM, Jason Merrill wrote:
>
> I don't see how the issue here depends on the artificiality of the vptr;
That's what I was trying to get at -- is DECL_ARTIFICIAL really a good
way to detect these kinds of cases.  It sounds like it likely isn't, but
it may also be the best we can do.  I'm not sure yet.




> I'd expect to see the same problem with a data member.  The problem is
> that a D base subobject is smaller than a complete D object, and in
> this case the base subobject is allocated such that if it were a full
> D object, it would overlap the end of E.  And we're checking the
> MEM_REF as though accessing a full D object, so we get a warning.
>
> The general issue about the confusion between complete and as-base
> types is PR 22488; I have various thoughts about a proper fix, but
> there have always been higher-priority things to work on.
>
> One possible approach to this PR is that we don't need to check an
> intermediate _REF; in
>
> MEM[(struct D *) + 24B]._vptr.D
>
> we aren't loading a whole D, we're only looking at the _vptr, which is
> within the bounds of E.
That raises a really interesting question.  What's the right bounds to
use with these kinds of constructs.  Should we be looking at D's type
(struct E) or struct D?  I'm not sure there's a one-size-fits-all answer
here and I don't think we have any other context go help guide us.

Jeff

Re: [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)

[Jeff Law via Gcc-patches]

On 2/8/21 3:44 PM, Martin Sebor wrote:
>
> I think the underlying problem is the same.  We're getting a size
> that doesn't correspond to what's actually being accessed, and it
> happens because of the virtual inheritance.  In pr97595 Jason
> suggested to use the decl/type size inequality to identify this
> case but I think we could have just as well used DECL_ARTIFICIAL
> instead.  At least the test cases from pr97595 both pass with
> this change.
OK.  I guess it's a minor question of semantics between pr97595 and
pr98266  being the same.  But I think we can put that behind us now.

I think the big question is whether or not DECL_ARTIFICIAL is the right
way to detect these cases, or if there simply isn't a way as one message
from Jason seems to imply.

Jeff

Re: [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266)

[Jeff Law via Gcc-patches]

On 2/8/21 2:56 PM, Martin Sebor wrote:
> On 2/8/21 12:59 PM, Jeff Law wrote:
>>
>>
>> On 1/19/21 5:56 PM, Martin Sebor via Gcc-patches wrote:
>>> Similar to the problem reported for -Wstringop-overflow in pr98266
>>> and already fixed, -Warray-bounds is also susceptible to false
>>> positives in assignments and copies involving virtual inheritance.
>>> Because the two warnings don't share code yet (hopefully in GCC 12)
>>> the attached patch adds its own workaround for this problem to
>>> gimple-array-bounds.cc, this one slightly more crude because of
>>> the limited insight the array bounds checking has into the checked
>>> expressions.
>>>
>>> Tested on x86_64-linux.
>>>
>>> Martin
>>>
>>> gcc-98266.diff
>>>
>>> PR middle-end/98266 - bogus array subscript is partly outside array
>>> bounds on virtual inheritance
>>>
>>> gcc/ChangeLog:
>>>
>>> PR middle-end/98266
>>> * gimple-array-bounds.cc
>>> (array_bounds_checker::check_array_bounds):
>>> Avoid checking references involving artificial members.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR middle-end/98266
>>> * g++.dg/warn/Warray-bounds-15.C: New test.
>> It seems to me that we've got the full statement at some point  and thus
>> the full expression so at some point couldn't we detect when
>> TYPE_SIZE_UNIT!= DECL_SIZE_UNIT?  Or should we be using TYPE_SIZE_UNIT
>> rather than DECL_SIZE_UNIT in gimple-array-bounds.cc
>>
>> Am I missing something?
>
> The expression we're looking at when the false positive is issued
> is the MEM_REF in the LHS of:
>
> MEM[(struct D *) + 24B]._vptr.D =   [(void
> *)&_ZTC1E24_1D + 24B];
>
> TREE_TYPE(LHS) is D, DECL_SIZE_UNIT (D.2652) is 24, and
> TYPE_SIZE_UNIT(D) is also 24, so there's no discrepancy between
> DECL_SIZE and TYPE_SIZE.
So it's a related, but not necessary exactly the same as pr97595 where
we do have the discrepancy between DECL_SIZE and TYPE_SIZE.

I think Jason's comment in pr97595 is the key here.  For a base subject
with virtual bases the offset is bounded by the most-derived object size
-- which runs a bit counter to some of the concepts we rely on.

So I think that raises two key questions.

First, can we detect when we've got an access to a base subobject with
virtual bases.  I think that's what you're trying to do with the
DECL_ARTIFICIAL check.  I don't know offhand if that's the best way to
detect these kinds of accesses or not.  That's probably the most
important question here, particularly for gcc-11.

Second, if we can detect those kinds of accesses, do we have any way to
get the most derived object size?  If so, obviously we'd want to use it
(gcc-12 perhaps), if not, we'd punt like your patch does.

Jeff

Re: [PATCH] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

[Marek Polacek via Gcc-patches]

On Thu, Feb 25, 2021 at 10:59:49AM -0500, Jason Merrill wrote:
> On 2/12/21 6:12 PM, Marek Polacek wrote:
> > We represent deduction guides with FUNCTION_DECLs, but they are built
> > without DECL_CONTEXT
> 
> Hmm, that seems wrong: "A deduction-guide shall be declared in the
> same scope as the corresponding class template and, for a member class
> template, with the same access."  But it probably isn't necessary to change
> this:
> 
> > leading to an ICE in type_dependent_expression_p
> > on the assert that the type of a function template with no dependent
> > (innermost!) template arguments must be non-dependent.  Consider the
> > attached class-deduction79.C: we create a deduction guide:
> > 
> >template G(T)-> E::G
> > 
> > we deduce T and create a partial instantiation:
> > 
> >G(T) -> E::G [with T = int]
> > 
> > And then do_class_deduction wants to create a CALL_EXPR from the above
> > using build_new_function_call -> build_over_call which calls mark_used
> > -> maybe_instantiate_noexcept -> type_dependent_expression_p.
> > 
> > There, the innermost template arguments are non-dependent (), but
> > the fntype is dependent -- the return type is a TYPENAME_TYPE, and
> > since we have no DECL_CONTEXT, this check holds:
> > 
> >/* Otherwise, if the function decl isn't from a dependent scope, it 
> > can't be
> >   type-dependent.  Checking this is important for functions with auto 
> > return
> >   type, which looks like a dependent type.  */
> >if (TREE_CODE (expression) == FUNCTION_DECL
> >&& !(DECL_CLASS_SCOPE_P (expression)
> > && dependent_type_p (DECL_CONTEXT (expression)))
> > 
> > whereupon we ICE.
> > 
> > Experiments with setting DECL_CONTEXT didn't pan out.
> 
> In c8 of the PR it looks like you were using the class itself as
> DECL_CONTEXT; the quote above says that the right context is the enclosing
> scope of the class.

Sadly, using CP_TYPE_CONTEXT (type) would result in a crash in
retrieve_specialization:

  /* There should be as many levels of arguments as there are
 levels of parameters.  */
  gcc_assert (TMPL_ARGS_DEPTH (args)
  == (TREE_CODE (tmpl) == TEMPLATE_DECL
  ? TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (tmpl))
  : template_class_depth (DECL_CONTEXT (tmpl;

> > So perhaps we
> > just want to skip the assert for deduction guides, because they are
> > a little special.  Better ideas solicited.
> 
> In c3 you mention that one of the variants broke with r269093; this is
> because my change to check CLASSTYPE_TEMPLATE_INSTANTIATION is false for the
> template pattern itself (E).

And the original test started with my r11-1713 because using TREE_TYPE
directly instead of decltype (which is a non-deduced context) means we
can deduced from the argument.
 
> But I think probably the right answer is to defer this deduction until the
> enclosing scope is non-dependent, i.e. (untested)

Thanks.  That mostly works, except the new class-deduction-aggr[89].C
tests.  Consider 8:

namespace N {
template  struct S {
  template  S(T, U);
};
} // namespace N
template  struct E {
  template  struct G { T t; };
  void fn() { G{N::S{'a', 1}}; }
};

void
g ()
{
  E<1> e;
  e.fn ();
}

With your patch, when in do_class_deduction when processing_template_decl,
we just return.  When we call do_class_deduction again when p_t_d is 0,
maybe_aggr_guide returns early here:

  if (!CP_AGGREGATE_TYPE_P (type))
return NULL_TREE

because G is not complete (and rightly so, we didn't instantiate it).  So
we aren't able to deduce the template parameters.  I'm not sure if I should
pursue this direction further.  :(

Marek

Re: [PATCH] c++: abbreviated function template return type rewriting [PR98990]

[Jason Merrill via Gcc-patches]

On 2/25/21 5:09 PM, Patrick Palka wrote:

On Tue, 9 Feb 2021, Patrick Palka wrote:


When an abbreviated function template has a complex placeholder return
type such auto& or auto**, the level adjustment performed by
splice_late_return_type directly replaces the 'auto' inside the original
return type with the level-adjusted 'auto', but that breaks
TYPE_CANONICAL caching.  Instead, we should rebuild the entire return
type using the adjusted 'auto'.

This patch makes this happen by tsubsting the original return type with
an argument vector that maps the original 'auto' to the adjusted 'auto'.
In passing, this patch also reverts the misguided changes to
find_type_usage in r10-6571 that made find_type_usage return a tree*
instead of a tree so as to discourage this kind of in-place type
modification.

It occurred to me that the constraint also needs to be rebuilt so that
it refers to the adjusted 'auto', but this oversight doesn't seem to
cause any issues at the moment due to how do_auto_deduction "manually"
substitutes the 'auto' inside the constraint before performing
satisfaction.  So this will instead be fixed as part of a broader rework
of placeholder type constraint checking.

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


Ping.  Note that this patch will cause a merge conflict with the
uncommitted patch at
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565205.html,
so I plan to address the FIXME below as part of a new version of
that patch.



gcc/cp/ChangeLog:

PR c++/98990
* pt.c (splice_late_return_type): Rebuild the entire return type
if we have to adjust the level of the auto.  Use
TEMPLATE_TYPE_LEVEL for brevity.
(type_uses_auto): Adjust call to find_type_usage.
* type-utils.h (find_type_usage): Revert r10-6571 change that
made this function return a pointer to the auto node.

gcc/testsuite/ChangeLog:

PR c++/98990
* g++.dg/concepts/abbrev8.C: New test.
---
  gcc/cp/pt.c | 39 +
  gcc/cp/type-utils.h | 23 +++
  gcc/testsuite/g++.dg/concepts/abbrev8.C | 22 ++
  3 files changed, 53 insertions(+), 31 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev8.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index c5b0a9292db..46cd322fbf4 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29601,22 +29601,25 @@ splice_late_return_type (tree type, tree 
late_return_type)
return late_return_type;
  }
  
-  if (tree *auto_node = find_type_usage (, is_auto))

-{
-  tree idx = get_template_parm_index (*auto_node);
-  if (TEMPLATE_PARM_LEVEL (idx) <= processing_template_decl)
-   {
- /* In an abbreviated function template we didn't know we were dealing
-with a function template when we saw the auto return type, so 
update
-it to have the correct level.  */
- tree new_auto = make_auto_1 (TYPE_IDENTIFIER (*auto_node), false);
- PLACEHOLDER_TYPE_CONSTRAINTS (new_auto)
-   = PLACEHOLDER_TYPE_CONSTRAINTS (*auto_node);
- TYPE_CANONICAL (new_auto) = canonical_type_parameter (new_auto);
- new_auto = cp_build_qualified_type (new_auto, TYPE_QUALS 
(*auto_node));
- *auto_node = new_auto;
-   }
-}
+  if (tree auto_node = find_type_usage (type, is_auto))
+if (TEMPLATE_TYPE_LEVEL (auto_node) <= processing_template_decl)
+  {
+   /* In an abbreviated function template we didn't know we were dealing
+  with a function template when we saw the auto return type, so rebuild
+  the return type using an auto with the correct level.  */
+   tree new_auto = make_auto_1 (TYPE_IDENTIFIER (auto_node), false);
+   tree auto_vec = make_tree_vec (1);
+   TREE_VEC_ELT (auto_vec, 0) = new_auto;
+   tree targs = add_outermost_template_args (current_template_args (),
+ auto_vec);
+   /* FIXME: We should also rebuild the constraint to refer to the new
+  auto.  */
+   PLACEHOLDER_TYPE_CONSTRAINTS (new_auto)
+ = PLACEHOLDER_TYPE_CONSTRAINTS (auto_node);
+   TYPE_CANONICAL (new_auto) = canonical_type_parameter (new_auto);


For the FIXME it would be nice to adjust 
make_constrained_auto/_placeholder_type to handle this for you.



+   new_auto = cp_build_qualified_type (new_auto, TYPE_QUALS (auto_node));


I'd expect this to be taken care of by the tsubst now.  OK without this 
line.



+   return tsubst (type, targs, tf_none, NULL_TREE);
+  }
return type;
  }
  
@@ -29661,10 +29664,8 @@ type_uses_auto (tree type)

else
return NULL_TREE;
  }
-  else if (tree *tp = find_type_usage (, is_auto))
-return *tp;
else
-return NULL_TREE;
+return find_type_usage (type, is_auto);
  }
  
  /* Report ill-formed occurrences of auto types in ARGUMENTS.  If

diff 

Re: [PATCH] c++: abbreviated function template return type rewriting [PR98990]

[Patrick Palka via Gcc-patches]

On Tue, 9 Feb 2021, Patrick Palka wrote:

> When an abbreviated function template has a complex placeholder return
> type such auto& or auto**, the level adjustment performed by
> splice_late_return_type directly replaces the 'auto' inside the original
> return type with the level-adjusted 'auto', but that breaks
> TYPE_CANONICAL caching.  Instead, we should rebuild the entire return
> type using the adjusted 'auto'.
> 
> This patch makes this happen by tsubsting the original return type with
> an argument vector that maps the original 'auto' to the adjusted 'auto'.
> In passing, this patch also reverts the misguided changes to
> find_type_usage in r10-6571 that made find_type_usage return a tree*
> instead of a tree so as to discourage this kind of in-place type
> modification.
> 
> It occurred to me that the constraint also needs to be rebuilt so that
> it refers to the adjusted 'auto', but this oversight doesn't seem to
> cause any issues at the moment due to how do_auto_deduction "manually"
> substitutes the 'auto' inside the constraint before performing
> satisfaction.  So this will instead be fixed as part of a broader rework
> of placeholder type constraint checking.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk/10?

Ping.  Note that this patch will cause a merge conflict with the
uncommitted patch at
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565205.html,
so I plan to address the FIXME below as part of a new version of
that patch.

> 
> gcc/cp/ChangeLog:
> 
>   PR c++/98990
>   * pt.c (splice_late_return_type): Rebuild the entire return type
>   if we have to adjust the level of the auto.  Use
>   TEMPLATE_TYPE_LEVEL for brevity.
>   (type_uses_auto): Adjust call to find_type_usage.
>   * type-utils.h (find_type_usage): Revert r10-6571 change that
>   made this function return a pointer to the auto node.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/98990
>   * g++.dg/concepts/abbrev8.C: New test.
> ---
>  gcc/cp/pt.c | 39 +
>  gcc/cp/type-utils.h | 23 +++
>  gcc/testsuite/g++.dg/concepts/abbrev8.C | 22 ++
>  3 files changed, 53 insertions(+), 31 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev8.C
> 
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index c5b0a9292db..46cd322fbf4 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -29601,22 +29601,25 @@ splice_late_return_type (tree type, tree 
> late_return_type)
>return late_return_type;
>  }
>  
> -  if (tree *auto_node = find_type_usage (, is_auto))
> -{
> -  tree idx = get_template_parm_index (*auto_node);
> -  if (TEMPLATE_PARM_LEVEL (idx) <= processing_template_decl)
> - {
> -   /* In an abbreviated function template we didn't know we were dealing
> -  with a function template when we saw the auto return type, so 
> update
> -  it to have the correct level.  */
> -   tree new_auto = make_auto_1 (TYPE_IDENTIFIER (*auto_node), false);
> -   PLACEHOLDER_TYPE_CONSTRAINTS (new_auto)
> - = PLACEHOLDER_TYPE_CONSTRAINTS (*auto_node);
> -   TYPE_CANONICAL (new_auto) = canonical_type_parameter (new_auto);
> -   new_auto = cp_build_qualified_type (new_auto, TYPE_QUALS 
> (*auto_node));
> -   *auto_node = new_auto;
> - }
> -}
> +  if (tree auto_node = find_type_usage (type, is_auto))
> +if (TEMPLATE_TYPE_LEVEL (auto_node) <= processing_template_decl)
> +  {
> + /* In an abbreviated function template we didn't know we were dealing
> +with a function template when we saw the auto return type, so rebuild
> +the return type using an auto with the correct level.  */
> + tree new_auto = make_auto_1 (TYPE_IDENTIFIER (auto_node), false);
> + tree auto_vec = make_tree_vec (1);
> + TREE_VEC_ELT (auto_vec, 0) = new_auto;
> + tree targs = add_outermost_template_args (current_template_args (),
> +   auto_vec);
> + /* FIXME: We should also rebuild the constraint to refer to the new
> +auto.  */
> + PLACEHOLDER_TYPE_CONSTRAINTS (new_auto)
> +   = PLACEHOLDER_TYPE_CONSTRAINTS (auto_node);
> + TYPE_CANONICAL (new_auto) = canonical_type_parameter (new_auto);
> + new_auto = cp_build_qualified_type (new_auto, TYPE_QUALS (auto_node));
> + return tsubst (type, targs, tf_none, NULL_TREE);
> +  }
>return type;
>  }
>  
> @@ -29661,10 +29664,8 @@ type_uses_auto (tree type)
>else
>   return NULL_TREE;
>  }
> -  else if (tree *tp = find_type_usage (, is_auto))
> -return *tp;
>else
> -return NULL_TREE;
> +return find_type_usage (type, is_auto);
>  }
>  
>  /* Report ill-formed occurrences of auto types in ARGUMENTS.  If
> diff --git a/gcc/cp/type-utils.h b/gcc/cp/type-utils.h
> index 5551e8f5ef1..138fed6c51e 100644
> --- a/gcc/cp/type-utils.h
> 

Re: [PATCH v2] c++: const_cast of null pointer in constant expr [PR99176]

[Jason Merrill via Gcc-patches]

On 2/25/21 4:20 PM, Marek Polacek wrote:

On Wed, Feb 24, 2021 at 10:32:59PM -0500, Jason Merrill wrote:

On 2/24/21 5:34 PM, Marek Polacek wrote:

Here we reject

constexpr const int *p = nullptr;
constexpr int *q = const_cast(p);

with "conversion of 'const int*' null pointer to 'int*' is not a
constant expression", which seems bogus.  This code has been rejected
since r238909 which added the can_convert check when converting a null
pointer.  I'm not finding any standard rule that this check was supposed
to enforce.  The original discussion was here

and here
.

Since can_convert never assumes a C-style cast, it rejects casting
away constness as in the test above and in:

constexpr int *q = (int *)(const int *) nullptr;

Removing the check only breaks constexpr-nullptr-2.C by not giving any
diagnostic for line 229:

constexpr B *pb2 = static_cast(pa0);  // { dg-error "not a constant 
expression" }

but the cast seems to be valid: we do [expr.static.cast]/7, and
[expr.const] only says that a reinterpreter_cast and converting from
void* is invalid in constexpr.  The can_convert check rejected convering
from void *, but only when converting from a null pointer, so it's not
good enough.  So I've added a check to catch conversions from cv void*.
I realize it's not a great time to be adding additional checking, but
removing the can_convert check would then technically be a regression.
(I could perhaps limit the new check to only trigger for integer_zerop
and then remove it in GCC 12.)


That sounds safest.


Done then.


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


OK.


gcc/cp/ChangeLog:

DR 1312
PR c++/99176
* constexpr.c (cxx_eval_constant_expression): Reject casting
from void * as per DR 1312.  Don't check can_convert.

gcc/testsuite/ChangeLog:

DR 1312
PR c++/99176
* g++.dg/cpp0x/constexpr-nullptr-2.C: Adjust dg-error.
* g++.dg/cpp0x/constexpr-cast2.C: New test.
* g++.dg/cpp0x/constexpr-cast3.C: New test.
---
   gcc/cp/constexpr.c| 49 ---
   gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C  | 16 ++
   gcc/testsuite/g++.dg/cpp0x/constexpr-cast3.C  | 14 ++
   .../g++.dg/cpp0x/constexpr-nullptr-2.C|  4 +-
   4 files changed, 64 insertions(+), 19 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-cast3.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 377fe322ee8..adf575d3dc6 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -6653,6 +6653,37 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
return t;
  }
+   /* [expr.const]: a conversion from type cv void* to a pointer-to-object
+  type cannot be part of a core constant expression as a resolution to
+  DR 1312.  */
+   if (TYPE_PTROB_P (type)
+   && TYPE_PTR_P (TREE_TYPE (op))
+   && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (op)))
+   /* Inside a call to std::construct_at or to
+  std::allocator::{,de}allocate, we permit casting from void*
+  because that is compiler-generated code.  */
+   && !(ctx->call
+&& ctx->call->fundef
+&& (is_std_construct_at (ctx->call->fundef->decl)
+|| is_std_allocator_allocate (ctx->call->fundef->decl


I wonder about adding overloads that take constexpr_call* so you don't need
the non-null checks here.  Up to you.


That seems convenient.  The downside is that then we'll check
ctx->call and ctx->call->fundef twice, but I guess that's not too bad.

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

-- >8 --
Here we reject

   constexpr const int *p = nullptr;
   constexpr int *q = const_cast(p);

with "conversion of 'const int*' null pointer to 'int*' is not a
constant expression", which seems bogus.  This code has been rejected
since r238909 which added the can_convert check when converting a null
pointer.  I'm not finding any standard rule that this check was supposed
to enforce.  The original discussion was here

and here
.

Since can_convert never assumes a C-style cast, it rejects casting
away constness as in the test above and in:

   constexpr int *q = (int *)(const int *) nullptr;

Removing the check only breaks constexpr-nullptr-2.C by not giving any
diagnostic for line 229:

   constexpr B *pb2 = static_cast(pa0);  // { dg-error "not a constant 
expression" }

but the cast seems to be valid: we do [expr.static.cast]/7, and
[expr.const] only says that a reinterpreter_cast and converting from
void* is invalid in constexpr.  

Re: [PATCH] c++: Implement P1102R2 - Down with ()!

[Jason Merrill via Gcc-patches]

On 2/25/21 1:44 PM, Jakub Jelinek wrote:

Hi!

The following patch implements P1102R2.
For attributes, we have already attribute parsing before the parameter
declarations and so when that is omitted, if the attributes are first we
already accept it.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or defer for GCC 12?

2021-02-25  Jakub Jelinek  

P1102R2 - Down with ()!
* parser.c (cp_parser_lambda_declarator_opt): Make ()s
optional before lambda specifiers for -std={c,gnu}++2b or
with pedwarn in earlier versions.

* g++.dg/cpp23/lambda-specifiers1.C: New test.

--- gcc/cp/parser.c.jj  2021-02-12 09:58:25.341506456 +0100
+++ gcc/cp/parser.c 2021-02-25 14:28:37.525431561 +0100
@@ -11223,12 +11223,12 @@ cp_parser_lambda_introducer (cp_parser*
  /* Parse the (optional) middle of a lambda expression.
  
 lambda-declarator:

- ( parameter-declaration-clause )
-   decl-specifier-seq [opt]
-   noexcept-specifier [opt]
-   attribute-specifier-seq [opt]
-   trailing-return-type [opt]
-   requires-clause [opt]
+ ( parameter-declaration-clause ) lambda-specifiers requires-clause [opt]
+ lambda-specifiers (C++23)
+
+   lambda-specifiers:
+ decl-specifier-seq [opt] noexcept-specifier [opt]
+   attribute-specifier-seq [opt] trailing-return-type [opt]
  
 LAMBDA_EXPR is the current representation of the lambda expression.  */
  
@@ -11248,6 +11248,8 @@ cp_parser_lambda_declarator_opt (cp_pars

tree tx_qual = NULL_TREE;
tree return_type = NULL_TREE;
tree trailing_requires_clause = NULL_TREE;
+  bool has_param_list = false;
+  location_t lambda_specifiers_loc = UNKNOWN_LOCATION;


Let's call this omitted_parms_loc, since that's what it's used for.


cp_decl_specifier_seq lambda_specs;
clear_decl_specs (_specs);
/* A lambda op() is const unless explicitly 'mutable'.  */
@@ -11334,47 +11336,88 @@ cp_parser_lambda_declarator_opt (cp_pars
 "default argument specified for lambda parameter");
  
parens.require_close (parser);

+  has_param_list = true;
+}
+  else if (cxx_dialect < cxx23)
+lambda_specifiers_loc = cp_lexer_peek_token (parser->lexer)->location;
  
-  /* In the decl-specifier-seq of the lambda-declarator, each

-decl-specifier shall either be mutable or constexpr.  */
-  int declares_class_or_enum;
-  if (cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
- && !cp_next_tokens_can_be_gnu_attribute_p (parser))
-   cp_parser_decl_specifier_seq (parser,
- CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR,
- _specs, _class_or_enum);
-  if (lambda_specs.storage_class == sc_mutable)
-   {
- LAMBDA_EXPR_MUTABLE_P (lambda_expr) = 1;
- quals = TYPE_UNQUALIFIED;
- if (lambda_specs.conflicting_specifiers_p)
-   error_at (lambda_specs.locations[ds_storage_class],
- "duplicate %");
-   }
+  /* In the decl-specifier-seq of the lambda-declarator, each
+ decl-specifier shall either be mutable or constexpr.  */
+  int declares_class_or_enum;
+  if (cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
+  && !cp_next_tokens_can_be_gnu_attribute_p (parser))
+cp_parser_decl_specifier_seq (parser,
+ CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR,
+ _specs, _class_or_enum);
+
+  if (lambda_specifiers_loc
+  && (lambda_specs.storage_class == sc_mutable
+ || lambda_specs.locations[ds_constexpr]
+ || lambda_specs.locations[ds_consteval]))


Maybe lambda_specs.any_specifiers_p instead of checking them individually?


+{
+  pedwarn (lambda_specifiers_loc, 0,
+  "parameter declaration before lambda declaration "
+  "specifiers only optional with %<-std=c++2b%> or "
+  "%<-std=gnu++2b%>");
+  lambda_specifiers_loc = UNKNOWN_LOCATION;
+}
+
+  if (lambda_specs.storage_class == sc_mutable)
+{
+  LAMBDA_EXPR_MUTABLE_P (lambda_expr) = 1;
+  quals = TYPE_UNQUALIFIED;
+  if (lambda_specs.conflicting_specifiers_p)
+   error_at (lambda_specs.locations[ds_storage_class],
+ "duplicate %");
+}
+
+  tx_qual = cp_parser_tx_qualifier_opt (parser);
+  if (lambda_specifiers_loc && tx_qual)
+{
+  pedwarn (lambda_specifiers_loc, 0,
+  "parameter declaration before lambda transaction "
+  "qualifier only optional with %<-std=c++2b%> or "
+  "%<-std=gnu++2b%>");
+  lambda_specifiers_loc = UNKNOWN_LOCATION;
+}
+
+  /* Parse optional exception specification.  */
+  exception_spec
+= cp_parser_exception_specification_opt (parser, CP_PARSER_FLAGS_NONE);
+
+  if (lambda_specifiers_loc && exception_spec)
+{
+  pedwarn (lambda_specifiers_loc, 0,
+  "parameter 

Re: [PATCH v2] c++: const_cast of null pointer in constant expr [PR99176]

[Marek Polacek via Gcc-patches]

On Wed, Feb 24, 2021 at 10:32:59PM -0500, Jason Merrill wrote:
> On 2/24/21 5:34 PM, Marek Polacek wrote:
> > Here we reject
> > 
> >constexpr const int *p = nullptr;
> >constexpr int *q = const_cast(p);
> > 
> > with "conversion of 'const int*' null pointer to 'int*' is not a
> > constant expression", which seems bogus.  This code has been rejected
> > since r238909 which added the can_convert check when converting a null
> > pointer.  I'm not finding any standard rule that this check was supposed
> > to enforce.  The original discussion was here
> > 
> > and here
> > .
> > 
> > Since can_convert never assumes a C-style cast, it rejects casting
> > away constness as in the test above and in:
> > 
> >constexpr int *q = (int *)(const int *) nullptr;
> > 
> > Removing the check only breaks constexpr-nullptr-2.C by not giving any
> > diagnostic for line 229:
> > 
> >constexpr B *pb2 = static_cast(pa0);  // { dg-error "not a constant 
> > expression" }
> > 
> > but the cast seems to be valid: we do [expr.static.cast]/7, and
> > [expr.const] only says that a reinterpreter_cast and converting from
> > void* is invalid in constexpr.  The can_convert check rejected convering
> > from void *, but only when converting from a null pointer, so it's not
> > good enough.  So I've added a check to catch conversions from cv void*.
> > I realize it's not a great time to be adding additional checking, but
> > removing the can_convert check would then technically be a regression.
> > (I could perhaps limit the new check to only trigger for integer_zerop
> > and then remove it in GCC 12.)
> 
> That sounds safest.

Done then.

> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > gcc/cp/ChangeLog:
> > 
> > DR 1312
> > PR c++/99176
> > * constexpr.c (cxx_eval_constant_expression): Reject casting
> > from void * as per DR 1312.  Don't check can_convert.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > DR 1312
> > PR c++/99176
> > * g++.dg/cpp0x/constexpr-nullptr-2.C: Adjust dg-error.
> > * g++.dg/cpp0x/constexpr-cast2.C: New test.
> > * g++.dg/cpp0x/constexpr-cast3.C: New test.
> > ---
> >   gcc/cp/constexpr.c| 49 ---
> >   gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C  | 16 ++
> >   gcc/testsuite/g++.dg/cpp0x/constexpr-cast3.C  | 14 ++
> >   .../g++.dg/cpp0x/constexpr-nullptr-2.C|  4 +-
> >   4 files changed, 64 insertions(+), 19 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-cast2.C
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-cast3.C
> > 
> > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > index 377fe322ee8..adf575d3dc6 100644
> > --- a/gcc/cp/constexpr.c
> > +++ b/gcc/cp/constexpr.c
> > @@ -6653,6 +6653,37 @@ cxx_eval_constant_expression (const constexpr_ctx 
> > *ctx, tree t,
> > return t;
> >   }
> > +   /* [expr.const]: a conversion from type cv void* to a pointer-to-object
> > +  type cannot be part of a core constant expression as a resolution to
> > +  DR 1312.  */
> > +   if (TYPE_PTROB_P (type)
> > +   && TYPE_PTR_P (TREE_TYPE (op))
> > +   && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (op)))
> > +   /* Inside a call to std::construct_at or to
> > +  std::allocator::{,de}allocate, we permit casting from void*
> > +  because that is compiler-generated code.  */
> > +   && !(ctx->call
> > +&& ctx->call->fundef
> > +&& (is_std_construct_at (ctx->call->fundef->decl)
> > +|| is_std_allocator_allocate (ctx->call->fundef->decl
> 
> I wonder about adding overloads that take constexpr_call* so you don't need
> the non-null checks here.  Up to you.

That seems convenient.  The downside is that then we'll check
ctx->call and ctx->call->fundef twice, but I guess that's not too bad.

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

-- >8 --
Here we reject

  constexpr const int *p = nullptr;
  constexpr int *q = const_cast(p);

with "conversion of 'const int*' null pointer to 'int*' is not a
constant expression", which seems bogus.  This code has been rejected
since r238909 which added the can_convert check when converting a null
pointer.  I'm not finding any standard rule that this check was supposed
to enforce.  The original discussion was here

and here
.

Since can_convert never assumes a C-style cast, it rejects casting
away constness as in the test above and in:

  constexpr int *q = (int *)(const int *) nullptr;

Removing the check only breaks constexpr-nullptr-2.C by not giving any
diagnostic for line 229:

  constexpr B *pb2 = static_cast(pa0);  // { dg-error "not a constant 
expression" }

Re: [PATCH, V2] Add conversions between _Float128 and Decimal.

[Segher Boessenkool]

On Thu, Feb 25, 2021 at 02:23:01AM +, Joseph Myers wrote:
> On Wed, 24 Feb 2021, Segher Boessenkool wrote:
> 
> > The other option, which we need for correctness *anyway*, is to have
> > libgcc do the conversion without using any specific libc.
> 
> Which ends up being quite complicated (see e.g. 
> https://www.cl.cam.ac.uk/~jrh13/papers/decimal.pdf for a more detailed 
> discussion of how to do such conversions and how to determine the worst 
> cases for correct rounding of them).

It may be tricky to get right, but since we need to have it, it is not
like there is much choice but to implement it.


Segher

Re: [PATCH] c++: Fix operator() lookup in lambdas [PR95451]

[Jason Merrill via Gcc-patches]

On 2/25/21 1:48 PM, Jakub Jelinek wrote:

Hi!

During name lookup, name-lookup.c uses:
 if (!(!iter->type && HIDDEN_TYPE_BINDING_P (iter))
 && (bool (want & LOOK_want::HIDDEN_LAMBDA)
 || !is_lambda_ignored_entity (iter->value))
 && qualify_lookup (iter->value, want))
   binding = iter->value;
Unfortunately as the following testcase shows, this doesn't work in
generic lambdas, where we on the auto b = ... lambda ICE and on the
auto d = lambda reject it even when it should be valid.  The problem
is that the binding doesn't have a FUNCTION_DECL with
LAMBDA_FUNCTION_P for the operator(), but an OVERLOAD with
TEMPLATE_DECL for such FUNCTION_DECL.

The following patch fixes that in is_lambda_ignored_entity, other
possibility would be to do that before calling is_lambda_ignored_entity
in name-lookup.c.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2021-02-25  Jakub Jelinek  

PR c++/95451
* lambda.c (is_lambda_ignored_entity): Before checking for
FUNCTION_DECL LAMBDA_FUNCTION_P, use OVL_FIRST and STRIP_TEMPLATE.

* g++.dg/cpp1y/lambda-generic-95451.C: New test.

--- gcc/cp/lambda.c.jj  2021-01-04 10:25:48.940119380 +0100
+++ gcc/cp/lambda.c 2021-02-25 17:03:40.099087470 +0100
@@ -1352,6 +1352,8 @@ is_lambda_ignored_entity (tree val)
  
/* None of the lookups that use qualify_lookup want the op() from the

   lambda; they want the one from the enclosing class.  */
+  val = OVL_FIRST (val);
+  val = STRIP_TEMPLATE (val);


I think we can drop the STRIP_TEMPLATE and the FUNCTION_DECL check in 
the next line; LAMBDA_FUNCTION_P already checks 
DECL_DECLARES_FUNCTION_P.  OK with that change.



if (TREE_CODE (val) == FUNCTION_DECL && LAMBDA_FUNCTION_P (val))
  return true;
  
--- gcc/testsuite/g++.dg/cpp1y/lambda-generic-95451.C.jj	2021-02-25 17:11:42.267673666 +0100

+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-95451.C   2021-02-25 
17:10:53.009226742 +0100
@@ -0,0 +1,35 @@
+// PR c++/95451
+// { dg-do run { target c++14 } }
+
+extern "C" void abort ();
+
+struct A {
+  template 
+  void foo ()
+  {
+auto b = [this] (auto) { return operator () (); } (0);
+if (b != 3)
+  abort ();
+auto c = [this] (int) { return operator () (); } (0);
+if (c != 3)
+  abort ();
+  }
+  void bar ()
+  {
+auto d = [this] (auto) { return operator () (); } (0);
+if (d != 3)
+  abort ();
+auto e = [this] (int) { return operator () (); } (0);
+if (e != 3)
+  abort ();
+  }
+  int operator () () { return 3; }
+};
+
+int
+main ()
+{
+  A a;
+  a.foo ();
+  a.bar ();
+}

Jakub

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Kees Cook via Gcc-patches]

On Thu, Feb 25, 2021 at 12:15:01PM -0600, Qing Zhao wrote:
> > On Feb 24, 2021, at 10:41 PM, Kees Cook  wrote:
> > [...]
> > test_stackinit: trailing_hole_none ok
> > test_stackinit: packed_none ok
> > test_stackinit: user ok
> > test_stackinit: failures: 8
> 
> Does the above testing include “pattern initialization” in addition to “zero 
> initialization”?

This was from the zero-init case. I've just tested pattern-init now and
it actually crashes GCC. I minimized the test case to this:

$ cat main.i
a() { char b[1]; }
$ gcc -ftrivial-auto-var-init=pattern -c /dev/null main.i
main.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | a() { char b[1]; }
  | ^
main.i: In function ‘a’:
main.i:1:12: internal compiler error: in gimplify_init_ctor_eval, at
gimplify.c:4873
1 | a() { char b[1]; }
  |^
0x69740d gimplify_init_ctor_eval
../../../gcc/gcc/gimplify.c:4873
0xb5ac8f gimplify_init_constructor
../../../gcc/gcc/gimplify.c:5320
0xb6b68a gimplify_modify_expr
../../../gcc/gcc/gimplify.c:5952
0xb533ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), 
int)
../../../gcc/gcc/gimplify.c:14262
0xb56b26 gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7056
0xb68e6e gimplify_and_add(tree_node*, gimple**)
../../../gcc/gcc/gimplify.c:489
0xb68e6e gimple_add_init_for_auto_var
../../../gcc/gcc/gimplify.c:1892
0xb68e6e gimplify_decl_expr
../../../gcc/gcc/gimplify.c:2010
0xb53bd6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), 
int)
../../../gcc/gcc/gimplify.c:14459
0xb56b26 gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7056
0xb5727d gimplify_bind_expr
../../../gcc/gcc/gimplify.c:1421
0xb536f0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), 
int)
../../../gcc/gcc/gimplify.c:14463
0xb6ccc9 gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7056
0xb6ccc9 gimplify_body(tree_node*, bool)
../../../gcc/gcc/gimplify.c:15498
0xb6d0ed gimplify_function_tree(tree_node*)
../../../gcc/gcc/gimplify.c:15652
0x9ae8d7 cgraph_node::analyze()
../../../gcc/gcc/cgraphunit.c:670
0x9b13a7 analyze_functions
../../../gcc/gcc/cgraphunit.c:1233
0x9b1f9d symbol_table::finalize_compilation_unit()
../../../gcc/gcc/cgraphunit.c:2511
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


> > struct test_..._hole instance = { .two = ..., };
> > 
> > or
> > 
> > struct test_..._hole instance = { .one = ...,
> >   .two = ...,
> >   .three = ...,
> >   .four = ...,
> > 
> > };
> 
> So, when the structure variables are not statically initialized, all the 
> paddings are initialized correctly by the compiler?

For the zero case, yes. (Usually such happen via copies into stack from from 
.rodata
sections, or accidentally from already-initialized copies.)

> In the current implementation, when the auto variable is explicitly 
> initialized, compiler will do nothing.
> Looks like for structure variables we need some special handling to 
> initialize the paddings.
> Need to study this a little bit and see how to fix it.

Deterministic padding init is a big part of this defense since that's
where the bulk of the really hard-to-find problems have existed (i.e. in
padding holes in structures that got copied around).

> > The last case is for switch variables outside of case statements, like
> > "var" here:
> > 
> > switch (path) {
> > unsigned long var;
> > 
> > case ..:
> > ...
> > case ..:
> > ...
> > ...
> > }
> > 
> 
> Will study this case more.

For the kernel, this is a low priority, since I purged the code of all
variable declarations outside of an execution path[1]. For reference,
here's the Clang bug for the same problem[2] (though latest Clang git
appears to no longer exhibit this issue, so they may have fixed it).

-Kees

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep=Distribute+switch+variables+for+initialization
[2] https://bugs.llvm.org/show_bug.cgi?id=44916

-- 
Kees Cook

Re: [PATCH] c++: Fix call to push_tinst_level during satisfaction [PR99214]

[Patrick Palka via Gcc-patches]

On Thu, 25 Feb 2021, Jason Merrill wrote:

> On 2/25/21 1:37 AM, Patrick Palka wrote:
> > In-Reply-To: <20210225063712.3725111-1-ppa...@redhat.com>
> 
> BTW, This patch doesn't seem in any way a reply to your previous patch, so
> it's confusing for the mail headers (and thus MUA threading) to say that it
> is.  Maybe you want git send-email --no-thread or
> git config sendemail.thread false ?

Ah, thanks for the heads up.  Out of convenience I sent these two
unrelated patches via a single "git send-email" command, which
unknowingly caused the second patch to get sent as reply to the first.
I'll make sure to send unrelated patches via separate send-email
commands, or via a single command but with --no-thread.

> 
> > In the three-parameter version of satisfy_declaration_constraints, when
> > 't' isn't the most general template, then 't' doesn't correspond with
> > the augmented template arguments 'args', and so the instantiation
> > context that we push via push_tinst_level isn't quite correct.  This
> > manifests as misleading diagnostic context lines during satisfaction
> > failure as in the testcase below for which without this patch we emit
> >In substitution of '... static void A::f() [with U = int]'
> > and with this patch we emit
> >In substitution of '... static void A::f() [with U = char; T =
> > int]'.
> > 
> > This patch fixes this by passing the most general template to
> > push_tinst_level.
> > 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/99214
> > * constraint.cc (get_normalized_constraints_from_decl): Fix
> > formatting.
> > (satisfy_declaration_constraints): Be lazy about augmenting
> > 'args'.  Pass the most general template to push_tinst_level.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/99214
> > * g++.dg/concepts/diagnostic16.C: New test.
> > ---
> >   gcc/cp/constraint.cc | 16 
> >   gcc/testsuite/g++.dg/concepts/diagnostic16.C | 15 +++
> >   2 files changed, 23 insertions(+), 8 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic16.C
> > 
> > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > index 31e0fb5079a..88963e687a7 100644
> > --- a/gcc/cp/constraint.cc
> > +++ b/gcc/cp/constraint.cc
> > @@ -910,11 +910,9 @@ get_normalized_constraints_from_decl (tree d, bool diag
> > = false)
> >accepting the latter causes the template parameter level of U
> >to be reduced in a way that makes it overly difficult substitute
> >concrete arguments (i.e., eventually {int, int} during satisfaction.
> > */
> > -  if (tmpl)
> > -  {
> > -if (DECL_LANG_SPECIFIC(tmpl) && !DECL_TEMPLATE_SPECIALIZATION (tmpl))
> > -  tmpl = most_general_template (tmpl);
> > -  }
> > +  if (tmpl && DECL_LANG_SPECIFIC (tmpl)
> > +  && !DECL_TEMPLATE_SPECIALIZATION (tmpl))
> > +tmpl = most_general_template (tmpl);
> 
> Can we use template_for_substitution instead of checking
> DECL_TEMPLATE_SPECIALIZATION and most_general_template?  That seems to be the
> semantic we want.

That sounds promising.  I tried (roughly)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 88963e687a7..1d974c52911 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -910,9 +910,7 @@ get_normalized_constraints_from_decl (tree d, bool diag = 
false)
  accepting the latter causes the template parameter level of U
  to be reduced in a way that makes it overly difficult substitute
  concrete arguments (i.e., eventually {int, int} during satisfaction.  */
-  if (tmpl && DECL_LANG_SPECIFIC (tmpl)
-  && !DECL_TEMPLATE_SPECIALIZATION (tmpl))
-tmpl = most_general_template (tmpl);
+  tmpl = template_for_substitution (decl);
 
   /* If we're not diagnosing errors, use cached constraints, if any.  */
   if (!diag)

which breaks a lot of tests due to trivial reasons (e.g. DECL_LANG_SPECIFIC
being empty), but in particular it breaks g++.dg/cpp2a/concepts-partial-spec2.C
in a non-trivial way.  In this testcase, the TEMPLATE_DECL for the
partial specialization

  template 
requires True && (T() == 0)
  constexpr bool p = true;

has as its DECL_TEMPLATE_RESULT a VAR_DECL whose DECL_TI_TEMPLATE is
the TEMPLATE_DECL not for the above partial specialization but for
the primary template for p.

So in short, when calling get_normalized_constraints_from_decl on the
above TEMPLATE_DECL we have

  tmpl = d
  decl = DECL_TEMPLATE_RESULT(tmpl)
  most_general_template(tmpl) == tmpl == the partial specialization
  template_for_substitution(decl) == decl == the primary template

and hence using template_for_substitution instead of
most_general_template here would cause us to normalize the wrong
constraints.

> 
> > /* If we're not diagnosing errors, use cached constraints, if any.  */
> > if (!diag)
> > @@ -3157,12 +3155,14 @@ satisfy_declaration_constraints (tree t, tree 

[PATCH] c++: Fix operator() lookup in lambdas [PR95451]

[Jakub Jelinek via Gcc-patches]

Hi!

During name lookup, name-lookup.c uses:
if (!(!iter->type && HIDDEN_TYPE_BINDING_P (iter))
&& (bool (want & LOOK_want::HIDDEN_LAMBDA)
|| !is_lambda_ignored_entity (iter->value))
&& qualify_lookup (iter->value, want))
  binding = iter->value;
Unfortunately as the following testcase shows, this doesn't work in
generic lambdas, where we on the auto b = ... lambda ICE and on the
auto d = lambda reject it even when it should be valid.  The problem
is that the binding doesn't have a FUNCTION_DECL with
LAMBDA_FUNCTION_P for the operator(), but an OVERLOAD with
TEMPLATE_DECL for such FUNCTION_DECL.

The following patch fixes that in is_lambda_ignored_entity, other
possibility would be to do that before calling is_lambda_ignored_entity
in name-lookup.c.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2021-02-25  Jakub Jelinek  

PR c++/95451
* lambda.c (is_lambda_ignored_entity): Before checking for
FUNCTION_DECL LAMBDA_FUNCTION_P, use OVL_FIRST and STRIP_TEMPLATE.

* g++.dg/cpp1y/lambda-generic-95451.C: New test.

--- gcc/cp/lambda.c.jj  2021-01-04 10:25:48.940119380 +0100
+++ gcc/cp/lambda.c 2021-02-25 17:03:40.099087470 +0100
@@ -1352,6 +1352,8 @@ is_lambda_ignored_entity (tree val)
 
   /* None of the lookups that use qualify_lookup want the op() from the
  lambda; they want the one from the enclosing class.  */
+  val = OVL_FIRST (val);
+  val = STRIP_TEMPLATE (val);
   if (TREE_CODE (val) == FUNCTION_DECL && LAMBDA_FUNCTION_P (val))
 return true;
 
--- gcc/testsuite/g++.dg/cpp1y/lambda-generic-95451.C.jj2021-02-25 
17:11:42.267673666 +0100
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-95451.C   2021-02-25 
17:10:53.009226742 +0100
@@ -0,0 +1,35 @@
+// PR c++/95451
+// { dg-do run { target c++14 } }
+
+extern "C" void abort ();
+
+struct A {
+  template 
+  void foo ()
+  {
+auto b = [this] (auto) { return operator () (); } (0);
+if (b != 3)
+  abort ();
+auto c = [this] (int) { return operator () (); } (0);
+if (c != 3)
+  abort ();
+  }
+  void bar ()
+  {
+auto d = [this] (auto) { return operator () (); } (0);
+if (d != 3)
+  abort ();
+auto e = [this] (int) { return operator () (); } (0);
+if (e != 3)
+  abort ();
+  }
+  int operator () () { return 3; }
+};
+
+int
+main ()
+{
+  A a;
+  a.foo ();
+  a.bar ();
+}

Jakub

[PATCH] c++: Implement P1102R2 - Down with ()!

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch implements P1102R2.
For attributes, we have already attribute parsing before the parameter
declarations and so when that is omitted, if the attributes are first we
already accept it.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or defer for GCC 12?

2021-02-25  Jakub Jelinek  

P1102R2 - Down with ()!
* parser.c (cp_parser_lambda_declarator_opt): Make ()s
optional before lambda specifiers for -std={c,gnu}++2b or
with pedwarn in earlier versions.

* g++.dg/cpp23/lambda-specifiers1.C: New test.

--- gcc/cp/parser.c.jj  2021-02-12 09:58:25.341506456 +0100
+++ gcc/cp/parser.c 2021-02-25 14:28:37.525431561 +0100
@@ -11223,12 +11223,12 @@ cp_parser_lambda_introducer (cp_parser*
 /* Parse the (optional) middle of a lambda expression.
 
lambda-declarator:
- ( parameter-declaration-clause )
-   decl-specifier-seq [opt]
-   noexcept-specifier [opt]
-   attribute-specifier-seq [opt]
-   trailing-return-type [opt]
-   requires-clause [opt]
+ ( parameter-declaration-clause ) lambda-specifiers requires-clause [opt]
+ lambda-specifiers (C++23)
+
+   lambda-specifiers:
+ decl-specifier-seq [opt] noexcept-specifier [opt]
+   attribute-specifier-seq [opt] trailing-return-type [opt]
 
LAMBDA_EXPR is the current representation of the lambda expression.  */
 
@@ -11248,6 +11248,8 @@ cp_parser_lambda_declarator_opt (cp_pars
   tree tx_qual = NULL_TREE;
   tree return_type = NULL_TREE;
   tree trailing_requires_clause = NULL_TREE;
+  bool has_param_list = false;
+  location_t lambda_specifiers_loc = UNKNOWN_LOCATION;
   cp_decl_specifier_seq lambda_specs;
   clear_decl_specs (_specs);
   /* A lambda op() is const unless explicitly 'mutable'.  */
@@ -11334,47 +11336,88 @@ cp_parser_lambda_declarator_opt (cp_pars
 "default argument specified for lambda parameter");
 
   parens.require_close (parser);
+  has_param_list = true;
+}
+  else if (cxx_dialect < cxx23)
+lambda_specifiers_loc = cp_lexer_peek_token (parser->lexer)->location;
 
-  /* In the decl-specifier-seq of the lambda-declarator, each
-decl-specifier shall either be mutable or constexpr.  */
-  int declares_class_or_enum;
-  if (cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
- && !cp_next_tokens_can_be_gnu_attribute_p (parser))
-   cp_parser_decl_specifier_seq (parser,
- CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR,
- _specs, _class_or_enum);
-  if (lambda_specs.storage_class == sc_mutable)
-   {
- LAMBDA_EXPR_MUTABLE_P (lambda_expr) = 1;
- quals = TYPE_UNQUALIFIED;
- if (lambda_specs.conflicting_specifiers_p)
-   error_at (lambda_specs.locations[ds_storage_class],
- "duplicate %");
-   }
+  /* In the decl-specifier-seq of the lambda-declarator, each
+ decl-specifier shall either be mutable or constexpr.  */
+  int declares_class_or_enum;
+  if (cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
+  && !cp_next_tokens_can_be_gnu_attribute_p (parser))
+cp_parser_decl_specifier_seq (parser,
+ CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR,
+ _specs, _class_or_enum);
+
+  if (lambda_specifiers_loc
+  && (lambda_specs.storage_class == sc_mutable
+ || lambda_specs.locations[ds_constexpr]
+ || lambda_specs.locations[ds_consteval]))
+{
+  pedwarn (lambda_specifiers_loc, 0,
+  "parameter declaration before lambda declaration "
+  "specifiers only optional with %<-std=c++2b%> or "
+  "%<-std=gnu++2b%>");
+  lambda_specifiers_loc = UNKNOWN_LOCATION;
+}
+
+  if (lambda_specs.storage_class == sc_mutable)
+{
+  LAMBDA_EXPR_MUTABLE_P (lambda_expr) = 1;
+  quals = TYPE_UNQUALIFIED;
+  if (lambda_specs.conflicting_specifiers_p)
+   error_at (lambda_specs.locations[ds_storage_class],
+ "duplicate %");
+}
+
+  tx_qual = cp_parser_tx_qualifier_opt (parser);
+  if (lambda_specifiers_loc && tx_qual)
+{
+  pedwarn (lambda_specifiers_loc, 0,
+  "parameter declaration before lambda transaction "
+  "qualifier only optional with %<-std=c++2b%> or "
+  "%<-std=gnu++2b%>");
+  lambda_specifiers_loc = UNKNOWN_LOCATION;
+}
+
+  /* Parse optional exception specification.  */
+  exception_spec
+= cp_parser_exception_specification_opt (parser, CP_PARSER_FLAGS_NONE);
+
+  if (lambda_specifiers_loc && exception_spec)
+{
+  pedwarn (lambda_specifiers_loc, 0,
+  "parameter declaration before lambda exception "
+  "specification only optional with %<-std=c++2b%> or "
+  "%<-std=gnu++2b%>");
+  lambda_specifiers_loc = UNKNOWN_LOCATION;
+}
 
-  tx_qual = 

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao via Gcc-patches]

Hi, Kees,

Thanks a lot for your testings on linux kernel.
I am happy to know that the initial implementation works fine. 
I will study the padding case and the switch case to fix the issues there.


> On Feb 24, 2021, at 10:41 PM, Kees Cook  wrote:
> 
> (please keep me in CC, I'm not subscribed...)

Yes, I will.

> 
> On Thu Feb 18, 2021 Qing Zhao said:
>> Initialize automatic variables with new first class option 
>> -ftrivial-auto-var-init=[uninitialized|pattern|zero]
> 
> Yay! I'm really excited to see this. Thank you for working on
> it! I've built GCC with this applied, and it works out of the box
> for a Linux kernel build, which correctly detects the availability
> of -ftrivial-auto-var-init=[pattern|zero] for the respective
> CONFIG_INIT_STACK_ALL_PATTERN and CONFIG_INIT_STACK_ALL_ZERO options.
> 
> The output from the kernel's CONFIG_TEST_STACKINIT module shows coverage
> for most uninitialized cases. Yay! :)
> 
> It looks like there is still some issues with padding and pre-case
> switch variables. Here's the test output, FWIW:
> 
> test_stackinit: u8_zero ok
> test_stackinit: u16_zero ok
> test_stackinit: u32_zero ok
> test_stackinit: u64_zero ok
> test_stackinit: char_array_zero ok
> test_stackinit: small_hole_zero ok
> test_stackinit: big_hole_zero ok
> test_stackinit: trailing_hole_zero ok
> test_stackinit: packed_zero ok
> test_stackinit: small_hole_dynamic_partial ok
> test_stackinit: big_hole_dynamic_partial ok
> test_stackinit: trailing_hole_dynamic_partial ok
> test_stackinit: packed_dynamic_partial ok
> test_stackinit: small_hole_static_partial ok
> test_stackinit: big_hole_static_partial ok
> test_stackinit: trailing_hole_static_partial ok
> test_stackinit: packed_static_partial ok
> test_stackinit: small_hole_static_all FAIL (uninit bytes: 3)
> test_stackinit: big_hole_static_all FAIL (uninit bytes: 61)
> test_stackinit: trailing_hole_static_all FAIL (uninit bytes: 7)
> test_stackinit: packed_static_all ok
> test_stackinit: small_hole_dynamic_all FAIL (uninit bytes: 3)
> test_stackinit: big_hole_dynamic_all FAIL (uninit bytes: 61)
> test_stackinit: trailing_hole_dynamic_all FAIL (uninit bytes: 7)
> test_stackinit: packed_dynamic_all ok
> test_stackinit: small_hole_runtime_partial ok
> test_stackinit: big_hole_runtime_partial ok
> test_stackinit: trailing_hole_runtime_partial ok
> test_stackinit: packed_runtime_partial ok
> test_stackinit: small_hole_runtime_all ok
> test_stackinit: big_hole_runtime_all ok
> test_stackinit: trailing_hole_runtime_all ok
> test_stackinit: packed_runtime_all ok
> test_stackinit: u8_none ok
> test_stackinit: u16_none ok
> test_stackinit: u32_none ok
> test_stackinit: u64_none ok
> test_stackinit: char_array_none ok
> test_stackinit: switch_1_none FAIL (uninit bytes: 8)
> test_stackinit: switch_2_none FAIL (uninit bytes: 8)
> test_stackinit: small_hole_none ok
> test_stackinit: big_hole_none ok
> test_stackinit: trailing_hole_none ok
> test_stackinit: packed_none ok
> test_stackinit: user ok
> test_stackinit: failures: 8

Does the above testing include “pattern initialization” in addition to “zero 
initialization”?
> 
> The kernel's test for this is a mess[1] of macros I used to avoid losing
> my sanity from cut/pasting, but it makes the tests hard to read. To
> break it out, the failing cases are due to padding, as seen with the
> "test_small_hole", "test_big_hole", and "test_trailing_hole" structures:
> 
> /* Simple structure with padding likely to be covered by compiler. */
> struct test_small_hole {
>   size_t one;
>   char two;
>   /* 3 byte padding hole here. */
>   int three;
>   unsigned long four;
> };
> 
> /* Try to trigger unhandled padding in a structure. */
> struct test_aligned {
>   u32 internal1;
>   u64 internal2;
> } __aligned(64);
> 
> struct test_big_hole {
>   u8 one;
>   u8 two;
>   u8 three;
>   /* 61 byte padding hole here. */
>   struct test_aligned four;
> } __aligned(64);
> 
> struct test_trailing_hole {
>   char *one;
>   char *two;
>   char *three;
>   char four;
>   /* "sizeof(unsigned long) - 1" byte padding hole here. */
> };
> 
> They fail when they're statically initialized (either fully or
> partially), for example:
> 
> struct test_..._hole instance = { .two = ..., };
> 
> or
> 
> struct test_..._hole instance = { .one = ...,
> .two = ...,
> .three = ...,
> .four = ...,
>   
>   };

So, when the structure variables are not statically initialized, all the 
paddings are initialized correctly by the compiler?

In the current implementation, when the auto variable is explicitly 
initialized, compiler will do nothing.
Looks like for structure variables we need some special handling to initialize 
the paddings.
Need to study this a little bit and see how to fix it.


> 
> The last case is for switch variables outside of case statements, like

Re: [PATCH, V2] Add conversions between _Float128 and Decimal.

[Michael Meissner via Gcc-patches]

On Wed, Feb 24, 2021 at 11:12:54PM +, Joseph Myers wrote:
> This change appears to have broken builds for powerpc in a configuration 
> that bootstraps a cross toolchain starting with a GCC build with no libc 
> available.
> 
> Specifically, such a bootstrap build uses --disable-decimal-float among 
> other options (in the first GCC build before libc has been built), to 
> disable GCC target library code that has any dependence on libc or libc 
> headers - dfp-bit.c uses libc headers, without an inhibit_libc 
> conditional, so cannot be used in such a bootstrap configuration.  Most of 
> the DFP code in libgcc is disabled by --disable-decimal-float, but it 
> seems the new conversions are not.  This results in errors of the form:
> 
> In file included from 
> /scratch/jmyers/glibc-bot/src/gcc/libgcc/config/rs6000/_kf_to_sd.c:37:
> /scratch/jmyers/glibc-bot/src/gcc/libgcc/dfp-bit.c:32:10: fatal error: 
> stdio.h: No such file or directory
>32 | #include 
>   |  ^
> compilation terminated.
> 
> The appropriate fix is not to build any of these new conversions in the 
> --disable-decimal-float case.  (That clearly makes sense anyway, even in 
> the absence of the bootstrap issue.)
> 
> https://sourceware.org/pipermail/libc-testresults/2021q1/007576.html

Thanks.  I agree if --disable-decimal-float is used we should not build the
conversions.  And we want to eliminate the stdio.h dependency.  I will look at
it unless somebody has already fixed it.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] arm: force use of r4 for __gnu_cmse_nonsecure_call when !FPCXT [PR99271]

[Richard Earnshaw (lists) via Gcc-patches]

Commit r10-6017 relaxed the constraint on thumb2 calls to
__gnu_cmse_nonsecure_call to allow any register for the call address.
Although the initial code expansion continues to use r4 with the FPCXT
extension is not enabled, the change was unsafe because subsequent
optimizations could use the additional freedom to change which
register was being used.

To fix this we need to split the output patterns in the machine
description to use distinct recognizers: one with the additional
freedom when FPCXT is enabled an another that retains the original
restrictions when the extension is not available.

gcc:
PR target/99271
* config/arm/thumb2.md (nonsecure_call_reg_thumb2_fpcxt): New pattern.
(nonsecure_call_value_reg_thumb2_fpcxt): Likewise.
(nonsecure_call_reg_thumb2): Restrict to using r4 for the callee
address and disable when the FPCXT is not available.
(nonsecure_call_value_reg_thumb2): Likewise.

gcc/testsuite:
* gcc.target/arm/cmse/cmse-18.c: New test.
---
 gcc/config/arm/thumb2.md| 47 ++---
 gcc/testsuite/gcc.target/arm/cmse/cmse-18.c | 11 +
 2 files changed, 42 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/cmse/cmse-18.c


diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index d7fd96c270e..5772f4d0b76 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -536,19 +536,26 @@ (define_insn "*call_reg_thumb2"
   [(set_attr "type" "call")]
 )
 
-(define_insn "*nonsecure_call_reg_thumb2"
+(define_insn "*nonsecure_call_reg_thumb2_fpcxt"
   [(call (unspec:SI [(mem:SI (match_operand:SI 0 "s_register_operand" "l*r"))]
 		UNSPEC_NONSECURE_MEM)
 	 (match_operand 1 "" ""))
(use (match_operand 2 "" ""))
(clobber (reg:SI LR_REGNUM))]
-  "TARGET_THUMB2 && use_cmse"
-  {
-if (TARGET_HAVE_FPCXT_CMSE)
-  return "blxns\\t%0";
-else
-  return "bl\\t__gnu_cmse_nonsecure_call";
-  }
+  "TARGET_THUMB2 && use_cmse && TARGET_HAVE_FPCXT_CMSE"
+  "blxns\\t%0"
+  [(set_attr "length" "4")
+   (set_attr "type" "call")]
+)
+
+(define_insn "*nonsecure_call_reg_thumb2"
+  [(call (unspec:SI [(mem:SI (reg:SI R4_REGNUM))]
+		UNSPEC_NONSECURE_MEM)
+	 (match_operand 0 "" ""))
+   (use (match_operand 1 "" ""))
+   (clobber (reg:SI LR_REGNUM))]
+  "TARGET_THUMB2 && use_cmse && !TARGET_HAVE_FPCXT_CMSE"
+  "bl\\t__gnu_cmse_nonsecure_call"
   [(set_attr "length" "4")
(set_attr "type" "call")]
 )
@@ -564,7 +571,7 @@ (define_insn "*call_value_reg_thumb2"
   [(set_attr "type" "call")]
 )
 
-(define_insn "*nonsecure_call_value_reg_thumb2"
+(define_insn "*nonsecure_call_value_reg_thumb2_fpcxt"
   [(set (match_operand 0 "" "")
 	(call
 	 (unspec:SI [(mem:SI (match_operand:SI 1 "register_operand" "l*r"))]
@@ -572,13 +579,21 @@ (define_insn "*nonsecure_call_value_reg_thumb2"
 	 (match_operand 2 "" "")))
(use (match_operand 3 "" ""))
(clobber (reg:SI LR_REGNUM))]
-  "TARGET_THUMB2 && use_cmse"
-  {
-if (TARGET_HAVE_FPCXT_CMSE)
-  return "blxns\\t%1";
-else
-  return "bl\\t__gnu_cmse_nonsecure_call";
-  }
+  "TARGET_THUMB2 && use_cmse && TARGET_HAVE_FPCXT_CMSE"
+  "blxns\\t%1"
+  [(set_attr "length" "4")
+   (set_attr "type" "call")]
+)
+
+(define_insn "*nonsecure_call_value_reg_thumb2"
+  [(set (match_operand 0 "" "")
+	(call
+	 (unspec:SI [(mem:SI (reg:SI R4_REGNUM))] UNSPEC_NONSECURE_MEM)
+	 (match_operand 1 "" "")))
+   (use (match_operand 2 "" ""))
+   (clobber (reg:SI LR_REGNUM))]
+  "TARGET_THUMB2 && use_cmse && !TARGET_HAVE_FPCXT_CMSE"
+  "bl\\t__gnu_cmse_nonsecure_call"
   [(set_attr "length" "4")
(set_attr "type" "call")]
 )
diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c b/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
new file mode 100644
index 000..e1ff09257b7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-18.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-mcmse -fdump-rtl-final-slim" } */
+
+typedef void (*f)(int) __attribute__((cmse_nonsecure_call));
+
+void bar(f func, int a)
+{
+  func(a);
+}
+
+/* { dg-final { scan-rtl-dump "call unspec\\\[\\\[r4:SI\\\]\\\]" "final" } } */

Re: [RFC] ldist: Recognize rawmemchr loop patterns

[Stefan Schulze Frielinghaus via Gcc-patches]

Ping

On Sun, Feb 14, 2021 at 11:27:40AM +0100, Stefan Schulze Frielinghaus wrote:
> On Tue, Feb 09, 2021 at 09:57:58AM +0100, Richard Biener wrote:
> > On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielinghaus via
> > Gcc-patches  wrote:
> > >
> > > This patch adds support for recognizing loops which mimic the behaviour
> > > of function rawmemchr, and replaces those with an internal function call
> > > in case a target provides them.  In contrast to the original rawmemchr
> > > function, this patch also supports different instances where the memory
> > > pointed to and the pattern are interpreted as 8, 16, and 32 bit sized,
> > > respectively.
> > >
> > > This patch is not final and I'm looking for some feedback:
> > >
> > > Previously, only loops which mimic the behaviours of functions memset,
> > > memcpy, and memmove have been detected and replaced by corresponding
> > > function calls.  One characteristic of those loops/partitions is that
> > > they don't have a reduction.  In contrast, loops which mimic the
> > > behaviour of rawmemchr compute a result and therefore have a reduction.
> > > My current attempt is to ensure that the reduction statement is not used
> > > in any other partition and only in that case ignore the reduction and
> > > replace the loop by a function call.  We then only need to replace the
> > > reduction variable of the loop which contained the loop result by the
> > > variable of the lhs of the internal function call.  This should ensure
> > > that the transformation is correct independently of how partitions are
> > > fused/distributed in the end.  Any thoughts about this?
> > 
> > Currently we're forcing reduction partitions last (and force to have a 
> > single
> > one by fusing all partitions containing a reduction) because code-generation
> > does not properly update SSA form for the reduction results.  ISTR that
> > might be just because we do not copy the LC PHI nodes or do not adjust
> > them when copying.  That might not be an issue in case you replace the
> > partition with a call.  I guess you can try to have a testcase with
> > two rawmemchr patterns and a regular loop part that has to be scheduled
> > inbetween both for correctness.
> 
> Ah ok, in that case I updated my patch by removing the constraint that
> the reduction statement must be in precisely one partition.  Please find
> attached the testcases I came up so far.  Since transforming a loop into
> a rawmemchr function call is backend dependend, I planned to include
> those only in my backend patch.  I wasn't able to come up with any
> testcase where a loop is distributed into multiple partitions and where
> one is classified as a rawmemchr builtin.  The latter boils down to a
> for loop with an empty body only in which case I suspect that loop
> distribution shouldn't be done anyway.
> 
> > > Furthermore, I simply added two new members (pattern, fn) to structure
> > > builtin_info which I consider rather hacky.  For the long run I thought
> > > about to split up structure builtin_info into a union where each member
> > > is a structure for a particular builtin of a partition, i.e., something
> > > like this:
> > >
> > > union builtin_info
> > > {
> > >   struct binfo_memset *memset;
> > >   struct binfo_memcpymove *memcpymove;
> > >   struct binfo_rawmemchr *rawmemchr;
> > > };
> > >
> > > Such that a structure for one builtin does not get "polluted" by a
> > > different one.  Any thoughts about this?
> > 
> > Probably makes sense if the list of recognized patterns grow further.
> > 
> > I see you use internal functions rather than builtin functions.  I guess
> > that's OK.  But you use new target hooks for expansion where I think
> > new optab entries similar to cmpmem would be more appropriate
> > where the distinction between 8, 16 or 32 bits can be encoded in
> > the modes.
> 
> The optab implementation is really nice which allows me to use iterators
> in the backend which in the end saves me some boiler plate code compared
> to the previous implementation :)
> 
> While using optabs now, I only require one additional member (pattern)
> in the builtin_info struct.  Thus I didn't want to overcomplicate things
> and kept the single struct approach as is.
> 
> For the long run, should I resubmit this patch once stage 1 opens or how
> would you propose to proceed?
> 
> Thanks for your review so far!
> 
> Cheers,
> Stefan
> 
> > 
> > Richard.
> > 
> > > Cheers,
> > > Stefan
> > > ---
> > >  gcc/internal-fn.c|  42 ++
> > >  gcc/internal-fn.def  |   3 +
> > >  gcc/target-insns.def |   3 +
> > >  gcc/tree-loop-distribution.c | 257 ++-
> > >  4 files changed, 272 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> > > index dd7173126fb..9cd62544a1a 100644
> > > --- a/gcc/internal-fn.c
> > > +++ b/gcc/internal-fn.c
> > > @@ -2917,6 +2917,48 @@ expand_VEC_CONVERT (internal_fn, gcall *)
> > >

Re: [PATCH 1/4] libstdc++: More efficient date from days.

[Jonathan Wakely via Gcc-patches]

On 25/02/21 14:19 +, Jonathan Wakely wrote:

On 25/02/21 14:02 +, Jonathan Wakely wrote:

On 25/02/21 13:46 +, Cassio Neri via Libstdc++ wrote:

Hi Jonathan,

The issue is that I didn't cast __dp.count() to uint32_t:

-  const auto __r0 = __dp.count() + __r2_e3;
+  const auto __r0 = static_cast(__dp.count()) + __r2_e3;

The above would be a better fix. Indeed, __r0 belongs to [0, 2^32[ which allows
all arithmetics that follow to be performed on uint32_t values. For performance
this is better than using signed integers.


OK, I'll make that change shortly, thanks.


We still need to cast to int for the return value though, because
converting from uint32_t to int is still narrowing.


I've committed this now.

Tested powerpc64le-linux, committed to trunk.


commit a47cec4ca7302e65f63490ad7f251c5a469bc0e0
Author: Jonathan Wakely 
Date:   Thu Feb 25 16:57:20 2021

libstdc++: Use uint32_t for all year_month_day::_S_from_days arithmetic

libstdc++-v3/ChangeLog:

* include/std/chrono (year_month_day::_S_from_days): Perform
all calculations with type uint32_t.

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index eef503af274..fcdaee7328e 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -2455,7 +2455,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr auto __z2= static_cast(-1468000);
   constexpr auto __r2_e3 = static_cast(536895458);
 
-  const auto __r0 = __dp.count() + __r2_e3;
+  const auto __r0 = static_cast(__dp.count()) + __r2_e3;
 
   const auto __n1 = 4 * __r0 + 3;
   const auto __q1 = __n1 / 146097;

c++: Rename new -flang-note-module-read option [PR 99166]

[Nathan Sidwell]

I realized that	the just-added flang-note-module-read option should also 
cover module writes, and was therefore misnamed.  This addresses that, 
replacing it with a -flang-note-module-cmi pair of options.  As this was 
such a recent addition, I didn't leave	the old	option available.


PR c++/99166
gcc/c-family/
* c.opt (-flang-info-module-cmi): Renamed option.
gcc/
* doc/invoke.texi (flang-info-module-cmi): Renamed option.
gcc/cp/
* module.cc (module_state::inform_cmi_p): Renamed field.
(module_state::do_import): Adjust.
(init_modules, finish_module_processing): Likewise.
(handle_module_option): Likewise.
gcc/testsuite/
* g++.dg/modules/pr99166_a.X: Adjust.
* g++.dg/modules/pr99166_b.C: Adjust.
* g++.dg/modules/pr99166_c.C: Adjust.
* g++.dg/modules/pr99166_d.C: Adjust.


--
Nathan Sidwell
diff --git c/gcc/c-family/c.opt w/gcc/c-family/c.opt
index 3264c646ad3..64e46e7573e 100644
--- c/gcc/c-family/c.opt
+++ w/gcc/c-family/c.opt
@@ -1752,11 +1752,11 @@ flang-info-include-translate=
 C++ Joined RejectNegative MissingArgError(missing header name)
 Note a #include translation of a specific header.
 
-flang-info-module-read
-C++ Var(note_module_read_yes)
+flang-info-module-cmi
+C++ Var(note_module_cmi_yes)
 Note Compiled Module Interface pathnames.
 
-flang-info-module-read=
+flang-info-module-cmi=
 C++ Joined RejectNegative MissingArgError(missing module name)
 Note Compiled Module Interface pathname of a specific module or header-unit.
 
diff --git c/gcc/cp/module.cc w/gcc/cp/module.cc
index e576face0d8..0cb5bd9b644 100644
--- c/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -3552,7 +3552,7 @@ class GTY((chain_next ("%h.parent"), for_user)) module_state {
 			   do it again  */
   bool call_init_p : 1; /* This module's global initializer needs
 			   calling.  */
-  bool inform_read_p : 1; /* Inform of a read.  */
+  bool inform_cmi_p : 1; /* Inform of a read/write.  */
   bool visited_p : 1;/* A walk-once flag. */
   /* Record extensions emitted or permitted.  */
   unsigned extensions : SE_BITS;
@@ -3789,7 +3789,7 @@ module_state::module_state (tree name, module_state *parent, bool partition)
 
   partition_p = partition;
 
-  inform_read_p = false;
+  inform_cmi_p = false;
   visited_p = false;
 
   extensions = 0;
@@ -18699,7 +18699,7 @@ module_state::do_import (cpp_reader *reader, bool outermost)
 {
   const char *file = maybe_add_cmi_prefix (filename);
   dump () && dump ("CMI is %s", file);
-  if (note_module_read_yes || inform_read_p)
+  if (note_module_cmi_yes || inform_cmi_p)
 	inform (loc, "reading CMI %qs", file);
   fd = open (file, O_RDONLY | O_CLOEXEC | O_BINARY);
   e = errno;
@@ -19695,7 +19695,7 @@ init_modules (cpp_reader *reader)
 	   0, is_pathname, name, len);
 	  }
 	if (auto module = get_module (name))
-	  module->inform_read_p = 1;
+	  module->inform_cmi_p = 1;
 	else
 	  error ("invalid module name %qs", name);
   }
@@ -19903,6 +19903,8 @@ finish_module_processing (cpp_reader *reader)
 		  break;
 		create_dirs (tmp_name);
 	  }
+	  if (note_module_cmi_yes || state->inform_cmi_p)
+	inform (state->loc, "writing CMI %qs", path);
 	  dump () && dump ("CMI is %s", path);
 	}
 
@@ -19915,7 +19917,7 @@ finish_module_processing (cpp_reader *reader)
 	  if (to.begin ())
 	{
 	  auto loc = input_location;
-	  /* So crashes finger point the module decl.  */
+	  /* So crashes finger-point the module decl.  */
 	  input_location = state->loc;
 	  state->write (, reader);
 	  input_location = loc;
@@ -20085,7 +20087,7 @@ handle_module_option (unsigned code, const char *str, int)
   vec_safe_push (note_includes, str);
   return true;
 
-case OPT_flang_info_module_read_:
+case OPT_flang_info_module_cmi_:
   vec_safe_push (note_cmis, str);
   return true;
 
diff --git c/gcc/doc/invoke.texi w/gcc/doc/invoke.texi
index ea315f1be58..546e95453c1 100644
--- c/gcc/doc/invoke.texi
+++ w/gcc/doc/invoke.texi
@@ -242,7 +242,7 @@ in the following sections.
 -fext-numeric-literals @gol
 -flang-info-include-translate@r{[}=@var{header}@r{]} @gol
 -flang-info-include-translate-not @gol
--flang-info-module-read@r{[}=@var{module}@r{]} @gol
+-flang-info-module-cmi@r{[}=@var{module}@r{]} @gol
 -stdlib=@var{libstdc++,libc++} @gol
 -Wabi-tag  -Wcatch-value  -Wcatch-value=@var{n} @gol
 -Wno-class-conversion  -Wclass-memaccess @gol
@@ -3390,9 +3390,9 @@ translations relating to that specific header.  If @var{header} is of
 the form @code{"user"} or @code{} it will be resolved to a
 specific user or system header using the include path.
 
-@item -flang-info-module-read
-@itemx -flang-info-module-read=@var{module}
-@opindex flang-info-module-read
+@item -flang-info-module-cmi
+@itemx -flang-info-module-cmi=@var{module}
+@opindex flang-info-module-cmi
 Inform of Compiled Module Interface pathnames.  The 

Re: [WIP] Re: [PATCH] openmp: Fix intermittent hanging of task-detach-6 libgomp tests [PR98738]

[Jakub Jelinek via Gcc-patches]

On Thu, Feb 25, 2021 at 04:21:31PM +, Kwok Cheung Yeung wrote:
> Reversing the order reduces the hole to 3 bytes:
> 
> size_t num_dependees;/*80 8 */
> union {
> gomp_sem_t *   completion_sem;   /*88 8 */
> struct gomp_team * detach_team;  /*88 8 */
> };   /*88 8 */
> _Bool  deferred_p;   /*96 1 */
> 
> /* XXX 3 bytes hole, try to pack */
> 
> intpriority; /*   100 4 */
> 
> If we were really determined to get rid of the hole, we could stash
> deferred_p in the least-significant bit of the pointer union, but I think

Sorry, indeed, I was thinking about how it would be packed after priority,
not before it but putting it in between priority and the related prio queues
is undesirable.  So union, deferred_p, priority is the right order.

> > I think you can move task->deferred_p into the if stmt.
> 
> That can be done (since the code for detach is currently the only thing
> using it), but I think it would be better to have deferred_p always have the
> right value, regardless of whether or not it is used? Otherwise that might
> lead to some confusion if it is later used by something else.

Ok either way.

> I will get this committed later if the regression tests finish with no 
> surprises.

Two more nits below.

> @@ -86,7 +87,8 @@ gomp_init_task (struct gomp_task *task, struct gomp_task 
> *parent_task,
>task->dependers = NULL;
>task->depend_hash = NULL;
>task->depend_count = 0;
> -  task->detach = false;
> +  task->deferred_p = true;
> +  task->detach_team = NULL;
>  }

Please initialize deferred_p to false rather than true, because gomp_init_task
is called in many places and except for that one spot in GOMP_task (and one
in taskloop.c) the tasks are undeferred (e.g. the implicit tasks in parallel
or the initial one etc.).
And maybe also reorder the fields initialized in there to match the order of 
increasing
field offsets.

> @@ -414,16 +411,18 @@ GOMP_task (void (*fn) (void *), void *data, void 
> (*cpyfn) (void *, void *),
>task.final_task = (thr->task && thr->task->final_task)
>   || (flags & GOMP_TASK_FLAG_FINAL);
>task.priority = priority;
> +  task.deferred_p = false;

And then this shouldn't be here, gomp_init_task has already initialized it
that way.

Jakub

Committed, pr95690.f90: move error line for CRIS.

[Hans-Peter Nilsson via Gcc-patches]

I don't know what it is that ix86, x86_64, Solaris and
apparently CRIS has in common here.

According to
https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652763.html
m68k-unknown-linux-gnu is also in that bunch, but since
there's a *-*-solaris* in the target specifier and also m68k
vs. m68k*, I'm leaving the adjustment to a maintainer.

gcc/testsuite:
* gfortran.dg/pr95690.f90: CRIS error appears on line 5.
---
 gcc/testsuite/gfortran.dg/pr95690.f90 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/pr95690.f90 
b/gcc/testsuite/gfortran.dg/pr95690.f90
index da809a0d3b34..7d8c68d1d7c3 100644
--- a/gcc/testsuite/gfortran.dg/pr95690.f90
+++ b/gcc/testsuite/gfortran.dg/pr95690.f90
@@ -2,8 +2,8 @@
 module m
 contains
subroutine s
-  print *, (erfc) ! { dg-error "not a floating constant" "" { target 
i?86-*-* x86_64-*-* *-*-solaris* } }
-   end ! { dg-error "not a floating constant" "" { target { ! "i?86-*-* 
x86_64-*-* *-*-solaris*" } } }
+  print *, (erfc) ! { dg-error "not a floating constant" "" { target 
i?86-*-* x86_64-*-* *-*-solaris* cris-*-* } }
+   end ! { dg-error "not a floating constant" "" { target { ! "i?86-*-* 
x86_64-*-* *-*-solaris* cris-*-*" } } }
function erfc()
end
 end
-- 
2.11.0

c++tools: Make NETWORKING define check consistent [PR 98318]

[Nathan Sidwell]

PR98318	also pointed out that the NETWORKING #define was being checked 
with both #if and #ifdef.  Let's consistently use one form.


c++tools/
* server.cc: Use #if NETWORKING not #ifdef, to be consistent
with elsewhere.

--
Nathan Sidwell
diff --git c/c++tools/server.cc w/c++tools/server.cc
index 8514ef6293b..21c7d468aa0 100644
--- c/c++tools/server.cc
+++ w/c++tools/server.cc
@@ -63,7 +63,7 @@ along with GCC; see the file COPYING3.  If not see
 #include 
 
 // Select or epoll
-#ifdef NETWORKING
+#if NETWORKING
 #ifdef HAVE_EPOLL
 /* epoll_create, epoll_ctl, epoll_pwait  */
 #include 
@@ -91,7 +91,7 @@ along with GCC; see the file COPYING3.  If not see
 #define DIR_SEPARATOR '/'
 #endif
 
-#ifdef NETWORKING
+#if NETWORKING
 struct netmask {
   in6_addr addr;
   unsigned bits;
@@ -161,7 +161,7 @@ static bool flag_xlate = false;
 /* Root binary directory.  */
 static const char *flag_root = "gcm.cache";
 
-#ifdef NETWORKING
+#if NETWORKING
 static netmask_set_t netmask_set;
 
 static netmask_vec_t accept_addrs;
@@ -233,7 +233,7 @@ error (const char *msg, ...)
   exit (1);
 }
 
-#ifdef NETWORKING
+#if NETWORKING
 /* Progress messages to the user.  */
 static bool ATTRIBUTE_PRINTF_1 ATTRIBUTE_COLD
 noisy (const char *fmt, ...)
@@ -414,7 +414,7 @@ process_args (int argc, char **argv)
   return optind;
 }
 
-#ifdef NETWORKING
+#if NETWORKING
 
 /* Manipulate the EPOLL state, or do nothing, if there is epoll.  */
 
@@ -871,7 +871,7 @@ main (int argc, char *argv[])
   /* Ignore sigpipe, so read/write get an error.  */
   signal (SIGPIPE, SIG_IGN);
 #endif
-#ifdef NETWORKING
+#if NETWORKING
 #ifdef SIGINT
   signal (SIGINT, kill_signal);
 #endif
@@ -935,7 +935,7 @@ main (int argc, char *argv[])
 }
 #endif
 
-#ifdef NETWORKING
+#if NETWORKING
   if (sock_fd >= 0)
 {
   server (name[0] != '=', sock_fd, );

Re: [PATCH,rs6000] [v2] Optimize pcrel access of globals

[Segher Boessenkool]

Hi!

On Thu, Feb 25, 2021 at 09:45:29AM +0100, Richard Biener wrote:
> On Wed, Feb 24, 2021 at 6:39 PM Segher Boessenkool
>  wrote:
> > On Tue, Feb 23, 2021 at 09:48:28AM +0100, Richard Biener wrote:
> > > stage1 please?
> >
> > Versions of this patch were first submitted in August.  Of 2019.
> >
> > We have quite a lot of experience with it so far.  There are no known
> > wrong-code (or ICE) problems with it.
> >
> > All of this is only when targetting power10 (which isn't shipping
> > hardware yet), and is behind a flag anyway, so you can easily disable
> > the optimisation.
> >
> > So, there is virtually no risk.
> 
> So it's enabled by default when targeting power10?

Yes.

> But power10 won't ship before the GCC 11 release?

"second half of 2021" says


The GCC release schedule is very much not harmonised with the POWER10
schedules :-/

> > On the other hand, we do want to get this into the hands of everyone
> > who should test it, and trunk works so much better for that than private
> > builds or patch sets.
> >
> > If it misses 11.1, we'll have to backport it to 11.2 .
> 
> I see.
> 
> > So, I'd really like it to get in now.  Do any of these arguments change
> > your position on that?
> 
> Well, in the end target maintainers have the say on target specific
> changes.  I guess hitting problems with the patch in testing GCC 11
> is unlikely to happen, and if it does we won't block shipping 11.1.

Thank you!

If any real problems crop up, we can just change the default to off.

> I do note that GCC 10 seems to know -mpower10 so technically
> such "regression" would block a release.

We'll not let that happen.  Promise.


Segher

[committed] [PR99233] testsuite: Run test pr96264.c only for little endian target

[Vladimir Makarov via Gcc-patches]

The following patch solves

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


commit 557a0d3b1b389c46d5a8aa24e27abed4c401d17e
Author: Vladimir N. Makarov 
Date:   Thu Feb 25 11:20:32 2021 -0500

[PR99233] tesstsuite: Run test pr96264.c only for little endian

The test in question is assumed to work only for little endian target.

gcc/testsuite/ChangeLog:

PR testsuite/99233
* gcc.target/powerpc/pr96264.c: Run it only for powerpc64le.

diff --git a/gcc/testsuite/gcc.target/powerpc/pr96264.c b/gcc/testsuite/gcc.target/powerpc/pr96264.c
index e89979b8998..9f7d885daf2 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr96264.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr96264.c
@@ -1,4 +1,4 @@
-/* { dg-do run } */
+/* { dg-do run { target { powerpc64le-*-* } } } */
 /* { dg-options "-Os -fno-forward-propagate -fschedule-insns -fno-tree-ter -Wno-psabi" } */
 /* { dg-require-effective-target p8vector_hw } */
 

[PATCH][committed]middle-end slp: Don't traverse tree on (nil) nodes.

[Tamar Christina via Gcc-patches]

Hi All,

The given testcase shows that one of the children of the complex MUL contains a
PHI node.  This results in the vectorizer having a child that's (nil).

The pattern matcher handles this correctly, but optimize_load_redistribution_1
needs to not traverse/inspect the NULL nodes.

This however does high-light a missed opportunity.  This testcase seems to
result in a different canonicalization than normally.

Normally the expressions are right leaning.  But sometimes, especially when type
casts are introduced the trees suddenly become left leaning. For instance this
testcase (even without type casts) won't detect the FMA form because the 
addition
gets the MUL node in the left and not right node as it expects.

Checking all forms would be quite expensive so for GCC 12 it probably makes 
sense to make
forms with type casts in them have the same form as those without?

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

Committed under the GCC obvious rule.

Thanks,
Tamar

gcc/ChangeLog:

* tree-vect-slp.c (optimize_load_redistribution_1): Abort on NULL nodes.

gcc/testsuite/ChangeLog:

* g++.dg/vect/complex-num-null-node.cc: New test.

--- inline copy of patch -- 
diff --git a/gcc/testsuite/g++.dg/vect/simd-complex-num-null-node.cc 
b/gcc/testsuite/g++.dg/vect/simd-complex-num-null-node.cc
new file mode 100644
index 
..eddf0ad8710138c3b5ac31706df02109d8164329
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vect/simd-complex-num-null-node.cc
@@ -0,0 +1,78 @@
+/* { dg-do compile { target { aarch64-*-* } } } */
+/* { dg-skip-if "incorrect syntax for c++98" { *-*-* } { "-std=c++98" } { "" } 
} */
+/* { dg-additional-options "-w -O3 -march=armv8.3-a -fdump-tree-vect-all" } */
+/* { dg-require-effective-target le } */
+
+typedef struct {
+  float b;
+  float c;
+} d;
+namespace {
+typedef int e;
+template  struct f;
+template  class g, typename h, typename k, typename... l>
+struct f, h> {
+  using m = g;
+};
+} // namespace
+namespace aa {
+template  class o {
+public:
+  typedef k p;
+};
+} // namespace aa
+namespace ab {
+template  using r = aa::o;
+template  class ac : public r {};
+struct s {
+  template  struct ad : f {};
+};
+template  using ae = typename s::ad::m;
+template  struct af {
+  typedef typename t::p p;
+  template  using u = ae;
+};
+} // namespace ab
+namespace aa {
+template  struct ag {
+  typedef ab::af v;
+  typedef typename v::p 
+  template  struct ai { typedef typename v::u aj; };
+};
+} // namespace aa
+namespace ab {
+template  struct w {
+  typedef typename aa::ag::ai::aj x;
+  struct y {};
+  typedef t ak;
+  w(e, ak);
+  y a;
+};
+template > class al : w {
+  typedef w am;
+  typedef typename am::x x;
+  typedef aa::ag an;
+
+public:
+  typedef typename an::ah ah;
+  typedef e ao;
+  typedef t ak;
+  al(ao ap, ak aq = ak()) : am(ar(ap, aq), aq) {}
+  ah operator[](ao);
+  ao ar(ao ap, ak) { return ap; }
+};
+} // namespace ab
+void as(int n, d *a, d *q) {
+  ab::al z(n);
+  d acc;
+  for (int j = 0; j < n; ++j) {
+auto at = a[j];
+auto au = q[j];
+acc.b += at.b * au.b - at.c * au.c;
+acc.c += at.b * au.c + at.c * au.b;
+  }
+  z[0] = acc;
+}
+
+
+/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_MUL" 1 "vect" } } */
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 
09a0f42410e3542c7823d70757550c22b8ef676f..aed0c7798b6203de6bce7a4764aeedd9a554670d
 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -2300,7 +2300,7 @@ optimize_load_redistribution_1 
(scalar_stmts_to_slp_tree_map_t *bst_map,
   unsigned i;
 
   /* For now, we don't know anything about externals so do not do anything.  */
-  if (SLP_TREE_DEF_TYPE (root) != vect_internal_def)
+  if (!root || SLP_TREE_DEF_TYPE (root) != vect_internal_def)
 return NULL;
   else if (SLP_TREE_CODE (root) == VEC_PERM_EXPR)
 {


-- 
diff --git a/gcc/testsuite/g++.dg/vect/simd-complex-num-null-node.cc b/gcc/testsuite/g++.dg/vect/simd-complex-num-null-node.cc
new file mode 100644
index ..eddf0ad8710138c3b5ac31706df02109d8164329
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vect/simd-complex-num-null-node.cc
@@ -0,0 +1,78 @@
+/* { dg-do compile { target { aarch64-*-* } } } */
+/* { dg-skip-if "incorrect syntax for c++98" { *-*-* } { "-std=c++98" } { "" } } */
+/* { dg-additional-options "-w -O3 -march=armv8.3-a -fdump-tree-vect-all" } */
+/* { dg-require-effective-target le } */
+
+typedef struct {
+  float b;
+  float c;
+} d;
+namespace {
+typedef int e;
+template  struct f;
+template  class g, typename h, typename k, typename... l>
+struct f, h> {
+  using m = g;
+};
+} // namespace
+namespace aa {
+template  class o {
+public:
+  typedef k p;
+};
+} // namespace aa
+namespace ab {
+template  using r = aa::o;
+template  class ac : public r {};
+struct s {
+  template  struct ad : f {};
+};
+template  using ae = typename s::ad::m;
+template  struct af {
+  typedef typename t::p p;
+  template  

Re: [WIP] Re: [PATCH] openmp: Fix intermittent hanging of task-detach-6 libgomp tests [PR98738]

[Kwok Cheung Yeung]

On 24/02/2021 7:46 pm, Jakub Jelinek wrote:

@@ -545,8 +548,15 @@ struct gomp_task
   entries and the gomp_task in which they reside.  */
struct priority_node pnode[3];
  
-  bool detach;

-  gomp_sem_t completion_sem;
+  union {
+/* Valid only if deferred_p is false.  */
+gomp_sem_t *completion_sem;
+/* Valid only if deferred_p is true.  Set to the team that executes the
+   task if the task is detached and the completion event has yet to be
+   fulfilled.  */
+struct gomp_team *detach_team;
+  };
+  bool deferred_p;
  
struct gomp_task_icv icv;

void (*fn) (void *);


What I don't like is that this creates too much wasteful padding
in a struct that should be as small as possible.
At least on 64-bit hosts which we care about most, pahole shows with your
patch:
struct gomp_task {
 struct gomp_task * parent;   /* 0 8 */
 struct priority_queue  children_queue;   /* 832 */
 struct gomp_taskgroup *taskgroup;/*40 8 */
 struct gomp_dependers_vec * dependers;   /*48 8 */
 struct htab *  depend_hash;  /*56 8 */
 /* --- cacheline 1 boundary (64 bytes) --- */
 struct gomp_taskwait * taskwait; /*64 8 */
 size_t depend_count; /*72 8 */
 size_t num_dependees;/*80 8 */
 intpriority; /*88 4 */

 /* XXX 4 bytes hole, try to pack */

 struct priority_node   pnode[3]; /*9648 */
 /* --- cacheline 2 boundary (128 bytes) was 16 bytes ago --- */
 union {
 gomp_sem_t *   completion_sem;   /*   144 8 */
 struct gomp_team * detach_team;  /*   144 8 */
 };   /*   144 8 */
 _Bool  deferred_p;   /*   152 1 */

 /* XXX 7 bytes hole, try to pack */

 struct gomp_task_icv   icv;  /*   16040 */
 /* --- cacheline 3 boundary (192 bytes) was 8 bytes ago --- */
 void   (*fn)(void *);/*   200 8 */
 void * fn_data;  /*   208 8 */
 enum gomp_task_kindkind; /*   216 4 */
 _Bool  in_tied_task; /*   220 1 */
 _Bool  final_task;   /*   221 1 */
 _Bool  copy_ctors_done;  /*   222 1 */
 _Bool  parent_depends_on;/*   223 1 */
 struct gomp_task_depend_entry depend[];  /*   224 0 */

 /* size: 224, cachelines: 4, members: 21 */
 /* sum members: 213, holes: 2, sum holes: 11 */
 /* last cacheline: 32 bytes */
};

So perhaps it might be better to put the new 1 fields before int priority;
field, in order bool deferred_p; union { };
That way, there will be just 3 bytes hole in the whole struct,
not 4 + 7 byte holes.



Moving the fields in that order before priority results in the same holes due to 
the alignment requirement of the pointers:


size_t num_dependees;/*80 8 */
_Bool  deferred_p;   /*88 1 */

/* XXX 7 bytes hole, try to pack */

union {
gomp_sem_t *   completion_sem;   /*96 8 */
struct gomp_team * detach_team;  /*96 8 */
};   /*96 8 */
intpriority; /*   104 4 */

/* XXX 4 bytes hole, try to pack */

struct priority_node pnode[3];   /*   11248 */

Reversing the order reduces the hole to 3 bytes:

size_t num_dependees;/*80 8 */
union {
gomp_sem_t *   completion_sem;   /*88 8 */
struct gomp_team * detach_team;  /*88 8 */
};   /*88 8 */
_Bool  deferred_p;   /*96 1 */

/* XXX 3 bytes hole, try to pack */

intpriority; /*   100 4 */

If we were really determined to get rid of the hole, we could stash deferred_p 
in the least-significant bit of the pointer union, but I think that might be 
more trouble than it is worth...


  
-  if (task.detach && !task_fulfilled_p ())

-   gomp_sem_wait (_sem);
+  if ((flags & GOMP_TASK_FLAG_DETACH) != 0 && detach)
+   gomp_sem_wait (_sem);


I think gomp_sem_destroy is missing here (in the 

Re: [PATCH] coroutines : Remove throwing_cleanup marks from the ramp [PR95822].

[Jason Merrill via Gcc-patches]

On 2/24/21 3:06 PM, Iain Sandoe wrote:

Hi,

The FE contains a mechanism for cleaning up return expressions if a
function throws during the execution of cleanups prior to the return.

If the original function has a return value with a non-trivial DTOR
and the body contains a var with a DTOR that might throw, the function
decl is marked "throwing_cleanup".

However, we do not [in the coroutine ramp function, which is
synthesised], use any body var types with DTORs that might throw.

The original body [which will then contain the type with the throwing
DTOR] is transformed into the actor function which only contains void
returns, and is also wrapped in a try-catch block.

So (a) the 'throwing_cleanup' is no longer correct for the ramp and
(b) we do not need to transfer it to the actor which only contains
void returns.

this is an ICE-on-valid,
tested on x86_64-darwin, x86_64-linux-gnu,

OK for master / 10.x ?


OK, but I wonder if there are other things that should also be reset.


thanks
Iain

gcc/cp/ChangeLog:

PR c++/95822
* coroutines.cc (morph_fn_to_coro): Unconditionally remove any
set throwing_cleanup marker.

gcc/testsuite/ChangeLog:

PR c++/95822
* g++.dg/coroutines/pr95822.C: New test.
---
  gcc/cp/coroutines.cc  | 11 +
  gcc/testsuite/g++.dg/coroutines/pr95822.C | 29 +++
  2 files changed, 40 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/coroutines/pr95822.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index abfe8d08192..19d2ca3e23e 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -4029,6 +4029,17 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
TREE_OPERAND (body_start, 0) = push_stmt_list ();
  }
  
+  /* If the original function has a return value with a non-trivial DTOR

+ and the body contains a var with a DTOR that might throw, the decl is
+ marked "throwing_cleanup".
+ We do not [in the ramp, which is synthesised here], use any body var
+ types with DTORs that might throw.
+ The original body is transformed into the actor function which only
+ contains void returns, and is also wrapped in a try-catch block.
+ So (a) the 'throwing_cleanup' is not correct for the ramp and (b) we do
+ not need to transfer it to the actor which only contains void returns.  */
+  cp_function_chain->throwing_cleanup = false;
+
/* Create the coro frame type, as far as it can be known at this stage.
   1. Types we already know.  */
  
diff --git a/gcc/testsuite/g++.dg/coroutines/pr95822.C b/gcc/testsuite/g++.dg/coroutines/pr95822.C

new file mode 100644
index 000..f6284aa417e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr95822.C
@@ -0,0 +1,29 @@
+#include 
+
+struct task {
+  struct promise_type {
+auto initial_suspend() noexcept { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+void return_void() {}
+task get_return_object() { return task{}; }
+void unhandled_exception() noexcept {}
+  };
+
+  ~task() noexcept {}
+
+  bool await_ready() const noexcept { return false; }
+  void await_suspend(std::coroutine_handle<>) noexcept {}
+  void await_resume() noexcept {}
+};
+
+struct Error {
+   Error() { };
+  ~Error() noexcept(false) {}
+};
+
+task g();
+
+task f() {
+  Error error;
+  co_await g();
+}

Re: [PATCH] clear more front end VLA bounds from IL (PR 97172)

[Martin Sebor via Gcc-patches]

On 2/25/21 9:06 AM, Christophe Lyon wrote:

Hi,



On Wed, 24 Feb 2021 at 09:57, Richard Biener via Gcc-patches
 wrote:


On Tue, Feb 23, 2021 at 8:53 PM Martin Sebor via Gcc-patches
 wrote:


Adding attribute access to declarations of functions that take
VLA arguments relies on the front end adding attribute "arg spec"
to each VLA parameter.  Like the VLA bounds in attribute access,
the same VLA bounds in attribute "arg spec" can cause trouble
during LTO streaming which expects front end trees to have been
either gimplified or removed.  For some reason, with arg spec
the LTO abort happens only with -fpic/-shared and so it escaped
testing in the prior fixes.

The attached patch clears the bounds from attribute "arg spec."


OK.



I committed the patch below as obvious, to avoid failures on targets
where -shared is not supported.
This happens on Arm where the multilibs are not compiled with -fpic
and link fails because
some relocations are generated which are incompatible with -shared.


Thanks!

Martin



commit 01c2ce169a05c8e59c4182796876f7e0754e4b5c
Author: Christophe Lyon 
Date:   Thu Feb 25 15:55:28 2021 +

 PR middle-end/97172 - ICE: tree code 'ssa_name' is not supported
in LTO streams

 Skip test when -shared is not supported.

 2021-02-25  Christophe Lyon  

 gcc/testsuite/
 PR middle-end/97172
 * gcc.dg/pr97172-2.c: Add dg-require-effective-target shared.

diff --git a/gcc/testsuite/gcc.dg/pr97172-2.c b/gcc/testsuite/gcc.dg/pr97172-2.c
index 6f355bb..99cc6c2 100644
--- a/gcc/testsuite/gcc.dg/pr97172-2.c
+++ b/gcc/testsuite/gcc.dg/pr97172-2.c
@@ -3,6 +3,7 @@
 { dg-do link }
 { dg-options "-Wall -flto -fpic -shared" }
 { dg-require-effective-target fpic }
+   { dg-require-effective-target shared }
 { dg-require-effective-target lto } */

  #include "pr97172.c"

Christophe



Richard.


Martin

Re: [PATCH] clear more front end VLA bounds from IL (PR 97172)

[Christophe Lyon via Gcc-patches]

Hi,



On Wed, 24 Feb 2021 at 09:57, Richard Biener via Gcc-patches
 wrote:
>
> On Tue, Feb 23, 2021 at 8:53 PM Martin Sebor via Gcc-patches
>  wrote:
> >
> > Adding attribute access to declarations of functions that take
> > VLA arguments relies on the front end adding attribute "arg spec"
> > to each VLA parameter.  Like the VLA bounds in attribute access,
> > the same VLA bounds in attribute "arg spec" can cause trouble
> > during LTO streaming which expects front end trees to have been
> > either gimplified or removed.  For some reason, with arg spec
> > the LTO abort happens only with -fpic/-shared and so it escaped
> > testing in the prior fixes.
> >
> > The attached patch clears the bounds from attribute "arg spec."
>
> OK.


I committed the patch below as obvious, to avoid failures on targets
where -shared is not supported.
This happens on Arm where the multilibs are not compiled with -fpic
and link fails because
some relocations are generated which are incompatible with -shared.

commit 01c2ce169a05c8e59c4182796876f7e0754e4b5c
Author: Christophe Lyon 
Date:   Thu Feb 25 15:55:28 2021 +

PR middle-end/97172 - ICE: tree code 'ssa_name' is not supported
in LTO streams

Skip test when -shared is not supported.

2021-02-25  Christophe Lyon  

gcc/testsuite/
PR middle-end/97172
* gcc.dg/pr97172-2.c: Add dg-require-effective-target shared.

diff --git a/gcc/testsuite/gcc.dg/pr97172-2.c b/gcc/testsuite/gcc.dg/pr97172-2.c
index 6f355bb..99cc6c2 100644
--- a/gcc/testsuite/gcc.dg/pr97172-2.c
+++ b/gcc/testsuite/gcc.dg/pr97172-2.c
@@ -3,6 +3,7 @@
{ dg-do link }
{ dg-options "-Wall -flto -fpic -shared" }
{ dg-require-effective-target fpic }
+   { dg-require-effective-target shared }
{ dg-require-effective-target lto } */

 #include "pr97172.c"

Christophe

>
> Richard.
>
> > Martin

Re: [PATCH] c++: Fix CTAD from single-element initializer list [PR99103]

[Jason Merrill via Gcc-patches]

On 2/15/21 2:30 PM, Patrick Palka wrote:

When determining whether to rule out initializer-list constructors
during CTAD with a single-element initializer list, the element type's
cv-qualifiers should be irrelevant.  This patch fixes this by making
is_spec_or_derived strip cv-qualifiers from the supplied expression
type.

In passing, I noticed in maybe_aggr_guide we were calling
is_spec_or_derived with swapped arguments.  This led us to prefer the
aggregate deduction candidate over copying deduction in the second
testcase below with -std=c++20.

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


OK.


gcc/cp/ChangeLog:

PR c++/99103
* pt.c (is_spec_or_derived): Drop cv-qualifiers from 'etype'.
(maybe_aggr_guide): Fix order of arguments to
is_spec_or_derived.

gcc/testsuite/ChangeLog:

PR c++/99103
* g++.dg/cpp1z/class-deduction79.C: New test.
* g++.dg/cpp1z/class-deduction80.C: New test.
---
  gcc/cp/pt.c|  3 ++-
  gcc/testsuite/g++.dg/cpp1z/class-deduction79.C | 10 ++
  gcc/testsuite/g++.dg/cpp1z/class-deduction80.C |  9 +
  3 files changed, 21 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction79.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction80.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5102bf02d0f..1acb5b3a097 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28829,6 +28829,7 @@ is_spec_or_derived (tree etype, tree tmpl)
if (!etype || !CLASS_TYPE_P (etype))
  return false;
  
+  etype = cv_unqualified (etype);

tree type = TREE_TYPE (tmpl);
tree tparms = (INNERMOST_TEMPLATE_PARMS
 (DECL_TEMPLATE_PARMS (tmpl)));
@@ -28859,7 +28860,7 @@ maybe_aggr_guide (tree tmpl, tree init, vec 
*args)
if (args->length() == 1)
  {
tree val = (*args)[0];
-  if (is_spec_or_derived (tmpl, TREE_TYPE (val)))
+  if (is_spec_or_derived (TREE_TYPE (val), tmpl))
return NULL_TREE;
  }
  
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction79.C b/gcc/testsuite/g++.dg/cpp1z/class-deduction79.C

new file mode 100644
index 000..ad0ba9bb8f5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction79.C
@@ -0,0 +1,10 @@
+// PR c++/99103
+// { dg-do compile { target c++17 } }
+#include 
+
+template 
+struct S { S(std::initializer_list); };
+
+extern const S x;
+using T = decltype(S{x});
+using T = S; // not S>
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction80.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction80.C
new file mode 100644
index 000..3dd7cb5890b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction80.C
@@ -0,0 +1,9 @@
+// PR c++/99103
+// { dg-do compile { target c++17 } }
+
+template  struct X { T a; };
+template  struct Y : X {};
+
+extern const Y y;
+using T = decltype(X{y});
+using T = X; // not X>

Re: [PATCH] c++: ICE with deduction guide in checking type-dep [PR99009, PR97034]

[Jason Merrill via Gcc-patches]

On 2/12/21 6:12 PM, Marek Polacek wrote:

We represent deduction guides with FUNCTION_DECLs, but they are built
without DECL_CONTEXT


Hmm, that seems wrong: "A deduction-guide shall be declared in the
same scope as the corresponding class template and, for a member class 
template, with the same access."  But it probably isn't necessary to 
change this:



leading to an ICE in type_dependent_expression_p
on the assert that the type of a function template with no dependent
(innermost!) template arguments must be non-dependent.  Consider the
attached class-deduction79.C: we create a deduction guide:

   template G(T)-> E::G

we deduce T and create a partial instantiation:

   G(T) -> E::G [with T = int]

And then do_class_deduction wants to create a CALL_EXPR from the above
using build_new_function_call -> build_over_call which calls mark_used
-> maybe_instantiate_noexcept -> type_dependent_expression_p.

There, the innermost template arguments are non-dependent (), but
the fntype is dependent -- the return type is a TYPENAME_TYPE, and
since we have no DECL_CONTEXT, this check holds:

   /* Otherwise, if the function decl isn't from a dependent scope, it can't be
  type-dependent.  Checking this is important for functions with auto return
  type, which looks like a dependent type.  */
   if (TREE_CODE (expression) == FUNCTION_DECL
   && !(DECL_CLASS_SCOPE_P (expression)
&& dependent_type_p (DECL_CONTEXT (expression)))

whereupon we ICE.

Experiments with setting DECL_CONTEXT didn't pan out.


In c8 of the PR it looks like you were using the class itself as 
DECL_CONTEXT; the quote above says that the right context is the 
enclosing scope of the class.



So perhaps we
just want to skip the assert for deduction guides, because they are
a little special.  Better ideas solicited.


In c3 you mention that one of the variants broke with r269093; this is 
because my change to check CLASSTYPE_TEMPLATE_INSTANTIATION is false for 
the template pattern itself (E).


But I think probably the right answer is to defer this deduction until 
the enclosing scope is non-dependent, i.e. (untested)


>From a0c19e712b8d8e6048d7371b237dc38cad2b9119 Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Thu, 25 Feb 2021 10:55:28 -0500
Subject: [PATCH] dep
To: gcc-patches@gcc.gnu.org

---
 gcc/cp/pt.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3576e0effb6..0e383d2434e 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29214,6 +29214,10 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
   if (DECL_TEMPLATE_TEMPLATE_PARM_P (tmpl))
 return ptype;
 
+  if (DECL_CLASS_SCOPE_P (tmpl)
+  && dependent_type_p (DECL_CONTEXT (tmpl)))
+return ptype;
+
   /* Initializing one placeholder from another.  */
   if (init && TREE_CODE (init) == TEMPLATE_PARM_INDEX
   && is_auto (TREE_TYPE (init))
-- 
2.27.0

[committed] libstdc++: Do not assume std::FILE is complete [PR 99270]

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

PR libstdc++/99270
* testsuite/27_io/headers/cstdio/types_std.cc: Use pointer to
FILE instead of FILE.

Tested x86_64-linux. Committed to trunk.

commit 31002af9040876dfb6444fabd524b11ca0739519
Author: Jonathan Wakely 
Date:   Thu Feb 25 15:31:19 2021

libstdc++: Do not assume std::FILE is complete [PR 99270]

libstdc++-v3/ChangeLog:

PR libstdc++/99270
* testsuite/27_io/headers/cstdio/types_std.cc: Use pointer to
FILE instead of FILE.

diff --git a/libstdc++-v3/testsuite/27_io/headers/cstdio/types_std.cc 
b/libstdc++-v3/testsuite/27_io/headers/cstdio/types_std.cc
index 41009f3214c..ad7cfe9a881 100644
--- a/libstdc++-v3/testsuite/27_io/headers/cstdio/types_std.cc
+++ b/libstdc++-v3/testsuite/27_io/headers/cstdio/types_std.cc
@@ -22,6 +22,6 @@
 namespace gnu
 {
   std::size_t s;
-  std::FILE f;
+  std::FILE* f;
   std::fpos_t p;
 }

[committed] libstdc++: Document library versioning for GCC 11

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* doc/xml/manual/abi.xml: Document versioning for GCC 11.
* doc/html/manual/abi.html: Regenerate.

Committed to trunk.

commit ed255fd5eda5e2530779bb69b8805c916ddfe0c2
Author: Jonathan Wakely 
Date:   Thu Feb 25 14:09:40 2021

libstdc++: Document library versioning for GCC 11

libstdc++-v3/ChangeLog:

* doc/xml/manual/abi.xml: Document versioning for GCC 11.
* doc/html/manual/abi.html: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/abi.xml 
b/libstdc++-v3/doc/xml/manual/abi.xml
index c15aa49e464..b332c978450 100644
--- a/libstdc++-v3/doc/xml/manual/abi.xml
+++ b/libstdc++-v3/doc/xml/manual/abi.xml
@@ -272,6 +272,7 @@ compatible.
 GCC 9.2.0: libstdc++.so.6.0.27
 GCC 9.3.0: libstdc++.so.6.0.28
 GCC 10.1.0: libstdc++.so.6.0.28
+GCC 11.1.0: libstdc++.so.6.0.29
 
 
   Note 1: Error should be libstdc++.so.3.0.3.
@@ -346,6 +347,7 @@ compatible.
 GCC 9.2.0: GLIBCXX_3.4.27, CXXABI_1.3.12
 GCC 9.3.0: GLIBCXX_3.4.28, CXXABI_1.3.12
 GCC 10.1.0: GLIBCXX_3.4.28, CXXABI_1.3.12
+GCC 11.1.0: GLIBCXX_3.4.29, CXXABI_1.3.13
 
 
 
@@ -579,10 +581,10 @@ compatible.
 GCC 3.3.3: include/c++/3.3.3
 GCC 3.4.x: include/c++/3.4.x
 GCC 4.x.y: include/c++/4.x.y
-GCC 5.x.0: include/c++/5.x.0
-GCC 6.x.0: include/c++/6.x.0
-GCC 7.x.0: include/c++/7.x.0
-GCC 8.x.0: include/c++/8.x.0
+GCC 5.1.0: include/c++/5.1.0
+
+  GCC x.y.0: include/c++/x.y.0 (for releases after GCC 5.1.0)
+
 
 
 
@@ -1227,7 +1229,7 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 
/usr/lib/libstdc++.so.
   on GNU/Linux Systems

   
-   
+
 
   SYRCoSE 2009
 

[OG10] backport an additional commit – was: [PATCH 0/7] [og10] openacc: Arrays/derived types/character type backports

[Tobias Burnus]

On 24.02.21 22:57, Julian Brown wrote:


This series contains several backports from mainline to the og10 branch


I have now also backported mainline commit
https://gcc.gnu.org/g:65167982efa4dbb96698d026e6d7e17acb513f0a
Fortran: add contiguous check for ptr assignment, fix non-contig check
(PR97242)

which relates to the contiguous check - which did not handle
derived-type components, popping up with some derived-type access in
clauses.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf

Re: [PATCH] c++: Fix call to push_tinst_level during satisfaction [PR99214]

[Jason Merrill via Gcc-patches]

On 2/25/21 1:37 AM, Patrick Palka wrote:

In-Reply-To: <20210225063712.3725111-1-ppa...@redhat.com>


BTW, This patch doesn't seem in any way a reply to your previous patch, 
so it's confusing for the mail headers (and thus MUA threading) to say 
that it is.  Maybe you want git send-email --no-thread or

git config sendemail.thread false ?


In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' doesn't correspond with
the augmented template arguments 'args', and so the instantiation
context that we push via push_tinst_level isn't quite correct.  This
manifests as misleading diagnostic context lines during satisfaction
failure as in the testcase below for which without this patch we emit
   In substitution of '... static void A::f() [with U = int]'
and with this patch we emit
   In substitution of '... static void A::f() [with U = char; T = int]'.

This patch fixes this by passing the most general template to
push_tinst_level.

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



gcc/cp/ChangeLog:

PR c++/99214
* constraint.cc (get_normalized_constraints_from_decl): Fix
formatting.
(satisfy_declaration_constraints): Be lazy about augmenting
'args'.  Pass the most general template to push_tinst_level.

gcc/testsuite/ChangeLog:

PR c++/99214
* g++.dg/concepts/diagnostic16.C: New test.
---
  gcc/cp/constraint.cc | 16 
  gcc/testsuite/g++.dg/concepts/diagnostic16.C | 15 +++
  2 files changed, 23 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic16.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 31e0fb5079a..88963e687a7 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -910,11 +910,9 @@ get_normalized_constraints_from_decl (tree d, bool diag = 
false)
   accepting the latter causes the template parameter level of U
   to be reduced in a way that makes it overly difficult substitute
   concrete arguments (i.e., eventually {int, int} during satisfaction.  */
-  if (tmpl)
-  {
-if (DECL_LANG_SPECIFIC(tmpl) && !DECL_TEMPLATE_SPECIALIZATION (tmpl))
-  tmpl = most_general_template (tmpl);
-  }
+  if (tmpl && DECL_LANG_SPECIFIC (tmpl)
+  && !DECL_TEMPLATE_SPECIALIZATION (tmpl))
+tmpl = most_general_template (tmpl);


Can we use template_for_substitution instead of checking 
DECL_TEMPLATE_SPECIALIZATION and most_general_template?  That seems to 
be the semantic we want.



/* If we're not diagnosing errors, use cached constraints, if any.  */
if (!diag)
@@ -3157,12 +3155,14 @@ satisfy_declaration_constraints (tree t, tree args, 
sat_info info)
  
gcc_assert (TREE_CODE (t) == TEMPLATE_DECL);
  
-  args = add_outermost_template_args (t, args);

-
tree result = boolean_true_node;
if (tree norm = normalize_template_requirements (t, info.noisy ()))
  {
-  if (!push_tinst_level (t, args))
+  args = add_outermost_template_args (t, args);
+  tree gen_tmpl = t;
+  if (DECL_LANG_SPECIFIC (t) && !DECL_TEMPLATE_SPECIALIZATION (t))
+   gen_tmpl = most_general_template (t);
+  if (!push_tinst_level (gen_tmpl, args))
return result;
tree pattern = DECL_TEMPLATE_RESULT (t);
push_access_scope (pattern);
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic16.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic16.C
new file mode 100644
index 000..b8d586e9a21
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic16.C
@@ -0,0 +1,15 @@
+// PR c++/99214
+// { dg-do compile { target c++20 } }
+
+template 
+struct A {
+  template  static void f() requires ([] { return U::fail; }()); // { dg-error 
"fail" }
+  template  static void f();
+};
+
+int main() {
+  A::f();
+}
+
+// This matches the context line "In substitution of '... [with U = char; T = 
int]'"
+// { dg-message "U = char; T = int" "" { target *-*-* } 0 }

Re: [PATCH] c++: Fix pretty printing of context of local class [PR99213]

[Jason Merrill via Gcc-patches]

On 2/25/21 1:37 AM, Patrick Palka wrote:

My r10-7705 patch for PR94521 made us set TFF_NO_FUNCTION_ARGUMENTS when
pretty printing the function scope of a local class type in order to
eliminate infinite recursion with a function signature that contains
decltype([]{}).  But due to the way dump_function_decl works, this
change regressed our pretty printing of local class types whose context
contains a class template specialization, as in the testcase below, in
which we wrongly pretty print the two local types as 'A::f::S1'
and 'B::f::S2'.

This patch makes dump_scope pass TFF_NO_TEMPLATE_BINDINGS instead of
TFF_NO_FUNCTION_ARGUMENTS when pretty printing a function scope.  It
appears this is the strictly better flag to use: it avoids the infinite
recursion issue, it restores pretty printing of the function parameter
list, and it stops dump_function_decl from trying to print a function
template specialization in its own weird way.

Summary of pretty printing differences for the below testcase:

   r10-7704:   A::f() [with U = char; T = int]::S1
   B::f() [with T = int]::S2

   r10-7705:   A::f::S1
   B::f::S2

   this patch: A::f()::S1
   B::f()::S2

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


OK.


gcc/cp/ChangeLog:

PR c++/99213
PR c++/94521
* error.c (dump_scope): Pass TFF_NO_TEMPLATE_BINDINGS instead of
TFF_NO_FUNCTION_ARGUMENTS when dumping a function scope.

gcc/testsuite/ChangeLog:

PR c++/99213
PR c++/94521
* g++.dg/diagnostic/local1.C: New test.
---
  gcc/cp/error.c   |  4 +---
  gcc/testsuite/g++.dg/diagnostic/local1.C | 25 
  2 files changed, 26 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/diagnostic/local1.C

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 5213a8030ca..ff4ae6f4b23 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -243,9 +243,7 @@ dump_scope (cxx_pretty_printer *pp, tree scope, int flags)
  }
else if ((flags & TFF_SCOPE) && TREE_CODE (scope) == FUNCTION_DECL)
  {
-  if (DECL_USE_TEMPLATE (scope))
-   f |= TFF_NO_FUNCTION_ARGUMENTS;
-  dump_function_decl (pp, scope, f);
+  dump_function_decl (pp, scope, f | TFF_NO_TEMPLATE_BINDINGS);
pp_cxx_colon_colon (pp);
  }
  }
diff --git a/gcc/testsuite/g++.dg/diagnostic/local1.C 
b/gcc/testsuite/g++.dg/diagnostic/local1.C
new file mode 100644
index 000..5905b571a44
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/local1.C
@@ -0,0 +1,25 @@
+// PR c++/99213
+// { dg-do compile { target c++14 } }
+
+template 
+struct A {
+  template 
+  static auto f() {
+struct S1{};
+return S1{};
+  }
+};
+
+using type = void;
+using type = decltype(A::f()); // { dg-error 
"A::f\\(\\)::S1"  }
+
+template 
+struct B {
+  static auto f() {
+struct S2{};
+return S2{};
+  }
+};
+
+using type = void;
+using type = decltype(B::f()); // { dg-error "B::f\\(\\)::S2"  }

Re: [PATCH 1/4] libstdc++: More efficient date from days.

[Jonathan Wakely via Gcc-patches]

On 25/02/21 14:02 +, Jonathan Wakely wrote:

On 25/02/21 13:46 +, Cassio Neri via Libstdc++ wrote:

Hi Jonathan,

The issue is that I didn't cast __dp.count() to uint32_t:

-  const auto __r0 = __dp.count() + __r2_e3;
+  const auto __r0 = static_cast(__dp.count()) + __r2_e3;

The above would be a better fix. Indeed, __r0 belongs to [0, 2^32[ which allows
all arithmetics that follow to be performed on uint32_t values. For performance
this is better than using signed integers.


OK, I'll make that change shortly, thanks.


We still need to cast to int for the return value though, because
converting from uint32_t to int is still narrowing.

Re: [PATCH 1/4] libstdc++: More efficient date from days.

[Jonathan Wakely via Gcc-patches]

On 25/02/21 13:46 +, Cassio Neri via Libstdc++ wrote:

Hi Jonathan,

The issue is that I didn't cast __dp.count() to uint32_t:

-  const auto __r0 = __dp.count() + __r2_e3;
+  const auto __r0 = static_cast(__dp.count()) + __r2_e3;

The above would be a better fix. Indeed, __r0 belongs to [0, 2^32[ which allows
all arithmetics that follow to be performed on uint32_t values. For performance
this is better than using signed integers.


OK, I'll make that change shortly, thanks.


I wrongly assumed __dp.count() was int32_t which would make __r0 also uint32_t.
It turns out, it is int64_t so are __r0 and other expressions including
__y1 + __z2. Hence, we're losing a bit of performance. I'm glad the compiler
warned us. (Although I don't understand why I didn't get the warning.)


You won't see it without -Wsystem-headers because warnings are
suppressed by default in libstdc++ headers.

There are a few annoyances in  due to the unnecessary use of
64-bit integers, which then causes narrowing conversions because some
constructors take int parameters.
e.g. https://github.com/cplusplus/draft/pull/4184

Re: [PATCH 1/4] libstdc++: More efficient date from days.

[Cassio Neri via Gcc-patches]

Hi Jonathan,

The issue is that I didn't cast __dp.count() to uint32_t:

-  const auto __r0 = __dp.count() + __r2_e3;
+  const auto __r0 = static_cast(__dp.count()) + __r2_e3;

The above would be a better fix. Indeed, __r0 belongs to [0, 2^32[ which allows
all arithmetics that follow to be performed on uint32_t values. For performance
this is better than using signed integers.

I wrongly assumed __dp.count() was int32_t which would make __r0 also uint32_t.
It turns out, it is int64_t so are __r0 and other expressions including
__y1 + __z2. Hence, we're losing a bit of performance. I'm glad the compiler
warned us. (Although I don't understand why I didn't get the warning.)

Thanks,
Cassio.

On Thu, Feb 25, 2021 at 11:56 AM Jonathan Wakely  wrote:
>
> On 24/02/21 17:28 +, Jonathan Wakely wrote:
> >On 23/02/21 13:24 +, Cassio Neri via Libstdc++ wrote:
> >>This patch reimplements std::chrono::year_month_day::_S_from_days() which
> >>retrieves a date from the number of elapsed days since 1970/01/01.  The new
> >>implementation is based on Proposition 6.3 of Neri and Schneider, "Euclidean
> >>Affine Functions and Applications to Calendar Algorithms" available at
> >>https://arxiv.org/abs/2102.06959.
> >>
> >>The aforementioned paper benchmarks the implementation against several
> >>counterparts, including libc++'s (which is identical to the current
> >>implementation).  The results, shown in Figure 4, indicate the new 
> >>algorithm is
> >>2.2 times faster than the current one.
> >>
> >>The patch adds a test which loops through all integers in [-12687428, 
> >>11248737],
> >>and for each of them, gets the corresponding date and compares the result
> >>against its expected value.  The latter is calculated using a much simpler 
> >>and
> >>easy to understand algorithm but which is also much slower.
> >>
> >>The interval used in the test covers the full range of values for which a
> >>roundtrip must work [time.cal.ymd.members].  Despite its completeness the 
> >>test
> >>runs in a matter of seconds.
> >>
> >>libstdc++-v3/ChangeLog:
> >>
> >>   * include/std/chrono:
> >>   * testsuite/std/time/year_month_day/3.cc: New test.
> >
> >Thanks! I'm committing this to trunk (it only changes new C++20
> >material so OK during stage 4 ... and anyway it's both faster and
> >better tested than the old code).
> >
> >I've tweaked it slightly to keep some lines below 80 columns, but no
> >changes except whitespace.
>
> I've made the attached tweak, to avoid a narrowing conversion from
> long to int. Tested x86_64-linux, committed to trunk.
>

Re: [PATCH] coroutines : Call promise CTOR with parm copies [PR97587].

[Nathan Sidwell]

On 2/24/21 3:09 PM, Iain Sandoe wrote:

Hi,

As the PR notes, we were calling the promise CTOR with the original
function parameters, not the copy (as pointed, a previous wording of
the section on this was unambiguous).  Fixed thus.

tested on x86_64-darwin, x86_64-linux-gnu,
this is a wrong-code bug,

OK for master / 10.x?
thanks
Iain

gcc/cp/ChangeLog:

PR c++/97587
* coroutines.cc (struct param_info): Track rvalue refs.
(morph_fn_to_coro): Track rvalue refs, and call the promise
CTOR with the frame copy of passed parms.

gcc/testsuite/ChangeLog:

PR c++/97587
* g++.dg/coroutines/coro1-refs-and-ctors.h: Add a CTOR with two
reference parms, to distinguish the rvalue ref. variant.
* g++.dg/coroutines/pr97587.C: New test.


ok, thanks


--
Nathan Sidwell

c++: Fix typo in module-mapper [PR 98318]

[Nathan Sidwell]

User reported this typo: '0' and '-' are right next to each other, and 
as it happened I always had networking, so it went unnoticed.


PR c++/98318
gcc/cp/
* mapper-client.cc (module_client::open_module_client): Fix typo
of fd init.

--
Nathan Sidwell
diff --git c/gcc/cp/mapper-client.cc w/gcc/cp/mapper-client.cc
index a72b4b70664..774e2b2b095 100644
--- c/gcc/cp/mapper-client.cc
+++ w/gcc/cp/mapper-client.cc
@@ -249,7 +249,7 @@ module_client::open_module_client (location_t loc, const char *o,
 		if (port && endp != cptr + 1 && !*endp)
 		  {
 			name[colon] = 0;
-			int fd = 01;
+			int fd = -1;
 #if CODY_NETWORKING
 			fd = Cody::OpenInet6 (, name.c_str (), port);
 #endif

[PATCH] First do add_noreturn_fake_exit_edges in connect_infinite_loops_to_exit

[Richard Biener]

Most callers of connect_infinite_loops_to_exit already do this but
the few that do not end up with extra exit edges.  The following
makes that consistent, also matching the post-dominance DFS walk code.

Boostrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.

2021-02-25  Richard Biener  

* cfganal.c (connect_infinite_loops_to_exit): First call
add_noreturn_fake_exit_edges.
* ipa-sra.c (process_scan_results): Do not call the now redundant
add_noreturn_fake_exit_edges.
* predict.c (tree_estimate_probability): Likewise.
(rebuild_frequencies): Likewise.
* store-motion.c (one_store_motion_pass): Likewise.
---
 gcc/cfganal.c  | 10 +++---
 gcc/ipa-sra.c  |  1 -
 gcc/predict.c  |  2 --
 gcc/store-motion.c |  1 -
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/cfganal.c b/gcc/cfganal.c
index 2627c2ff457..cec5abe30f9 100644
--- a/gcc/cfganal.c
+++ b/gcc/cfganal.c
@@ -582,9 +582,9 @@ add_noreturn_fake_exit_edges (void)
   make_single_succ_edge (bb, EXIT_BLOCK_PTR_FOR_FN (cfun), EDGE_FAKE);
 }
 
-/* This function adds a fake edge between any infinite loops to the
-   exit block.  Some optimizations require a path from each node to
-   the exit node.
+/* This function adds a fake edge between any noreturn block and
+   infinite loops to the exit block.  Some optimizations require a path
+   from each node to the exit node.
 
See also Morgan, Figure 3.10, pp. 82-83.
 
@@ -596,6 +596,10 @@ add_noreturn_fake_exit_edges (void)
 void
 connect_infinite_loops_to_exit (void)
 {
+  /* First add fake exits to noreturn blocks, this is required to
+ discover only truly infinite loops below.  */
+  add_noreturn_fake_exit_edges ();
+
   /* Perform depth-first search in the reverse graph to find nodes
  reachable from the exit block.  */
   depth_first_search dfs;
diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
index 1571921cb48..7a89906cee6 100644
--- a/gcc/ipa-sra.c
+++ b/gcc/ipa-sra.c
@@ -2394,7 +2394,6 @@ process_scan_results (cgraph_node *node, struct function 
*fun,
if (!pdoms_calculated)
  {
gcc_checking_assert (cfun);
-   add_noreturn_fake_exit_edges ();
connect_infinite_loops_to_exit ();
calculate_dominance_info (CDI_POST_DOMINATORS);
pdoms_calculated = true;
diff --git a/gcc/predict.c b/gcc/predict.c
index d0a8e5f8e04..0bf1748ffa8 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -3106,7 +3106,6 @@ tree_estimate_probability (bool dry_run)
 {
   basic_block bb;
 
-  add_noreturn_fake_exit_edges ();
   connect_infinite_loops_to_exit ();
   /* We use loop_niter_by_eval, which requires that the loops have
  preheaders.  */
@@ -4291,7 +4290,6 @@ rebuild_frequencies (void)
   if (profile_status_for_fn (cfun) == PROFILE_GUESSED)
 {
   loop_optimizer_init (0);
-  add_noreturn_fake_exit_edges ();
   mark_irreducible_loops ();
   connect_infinite_loops_to_exit ();
   estimate_bb_frequencies (true);
diff --git a/gcc/store-motion.c b/gcc/store-motion.c
index f0401cae272..3f6e003219d 100644
--- a/gcc/store-motion.c
+++ b/gcc/store-motion.c
@@ -1152,7 +1152,6 @@ one_store_motion_pass (void)
 
   /* Now compute kill & transp vectors.  */
   build_store_vectors ();
-  add_noreturn_fake_exit_edges ();
   connect_infinite_loops_to_exit ();
 
   edge_list = pre_edge_rev_lcm (num_stores, st_transp, st_avloc,
-- 
2.26.2

[wwwdocs] Document new libstdc++ features

[Jonathan Wakely via Gcc-patches]

Pushed to wwwdocs.


commit 86937d6dfe04c81c805cfc321c62a520dfd2a59f
Author: Jonathan Wakely 
Date:   Thu Feb 25 12:54:45 2021 +

Document new libstdc++ features

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index de75b8d6..6a47b0b8 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -429,12 +429,15 @@ a work-in-progress.
 
   Improved C++17 support, including:
 
-  std::from_chars for floating-point types.
+  std::from_chars and std::to_chars
+for floating-point types.
 
   
   Improved experimental C++20 support, including:
 
-  Calendar additions to chrono.
+  Calendar additions to chrono.
+Thanks to Cassio Neri for optimizations.
+  
   std::bit_cast
   std::source_location
   Atomic wait and notify operations.
@@ -449,6 +452,7 @@ a work-in-progress.
   contains member functions for strings,
 thanks to Paul Fee.
   
+  std::to_underlying
 
   
   Experimental support for Data-Parallel Types (simd)

Re: [PATCH 1/4] libstdc++: More efficient date from days.

[Jonathan Wakely via Gcc-patches]

On 24/02/21 17:28 +, Jonathan Wakely wrote:

On 23/02/21 13:24 +, Cassio Neri via Libstdc++ wrote:

This patch reimplements std::chrono::year_month_day::_S_from_days() which
retrieves a date from the number of elapsed days since 1970/01/01.  The new
implementation is based on Proposition 6.3 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
https://arxiv.org/abs/2102.06959.

The aforementioned paper benchmarks the implementation against several
counterparts, including libc++'s (which is identical to the current
implementation).  The results, shown in Figure 4, indicate the new algorithm is
2.2 times faster than the current one.

The patch adds a test which loops through all integers in [-12687428, 11248737],
and for each of them, gets the corresponding date and compares the result
against its expected value.  The latter is calculated using a much simpler and
easy to understand algorithm but which is also much slower.

The interval used in the test covers the full range of values for which a
roundtrip must work [time.cal.ymd.members].  Despite its completeness the test
runs in a matter of seconds.

libstdc++-v3/ChangeLog:

  * include/std/chrono:
  * testsuite/std/time/year_month_day/3.cc: New test.


Thanks! I'm committing this to trunk (it only changes new C++20
material so OK during stage 4 ... and anyway it's both faster and
better tested than the old code).

I've tweaked it slightly to keep some lines below 80 columns, but no
changes except whitespace.


I've made the attached tweak, to avoid a narrowing conversion from
long to int. Tested x86_64-linux, committed to trunk.

commit 75c74a83acee3f51e6753b8159fa600fe2d86810
Author: Jonathan Wakely 
Date:   Thu Feb 25 11:48:18 2021

libstdc++: Fix narrowing conversion in year_month_day [PR 99265]

libstdc++-v3/ChangeLog:

PR libstdc++/99265
* include/std/chrono (year_month_day::_S_from_days): Cast long
to int explicitly.

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index feb2c2a1fad..eef503af274 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -2481,8 +2481,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const auto __m1 = __j ? __m0 - 12 : __m0;
   const auto __d1 = __d0 + 1;
 
-  return year_month_day{chrono::year{__y1 + __z2}, chrono::month{__m1},
-			chrono::day{__d1}};
+  return year_month_day{chrono::year{static_cast(__y1 + __z2)},
+			chrono::month{__m1}, chrono::day{__d1}};
 }
 
 // Days since 1970/01/01.

[committed] libstdc++: Add std::to_underlying for C++23

[Jonathan Wakely via Gcc-patches]

Implement P1682R2 as just approved for C++23.

libstdc++-v3/ChangeLog:

* include/std/utility (to_underlying): Define.
* include/std/version (__cpp_lib_to_underlying): Define.
* testsuite/20_util/to_underlying/1.cc: New test.
* testsuite/20_util/to_underlying/version.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

commit 7244879b883cb3405bdd98f051d50a2f36394e79
Author: Jonathan Wakely 
Date:   Thu Feb 25 11:20:17 2021

libstdc++: Add std::to_underlying for C++23

Implement P1682R2 as just approved for C++23.

libstdc++-v3/ChangeLog:

* include/std/utility (to_underlying): Define.
* include/std/version (__cpp_lib_to_underlying): Define.
* testsuite/20_util/to_underlying/1.cc: New test.
* testsuite/20_util/to_underlying/version.cc: New test.

diff --git a/libstdc++-v3/include/std/utility b/libstdc++-v3/include/std/utility
index 4c7fca96c5e..fb19d62968f 100644
--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -461,6 +461,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   else
return __t <= make_unsigned_t<_Up>(__int_traits<_Up>::__max);
 }
+
+#if __cplusplus > 202002L
+#define __cpp_lib_to_underlying 202102L
+  /// Convert an object of enumeration type to its underlying type.
+  template
+constexpr underlying_type_t<_Tp>
+to_underlying(_Tp __value) noexcept
+{ return static_cast>(__value); }
+#endif // C++23
 #endif // C++20
 #endif // C++17
 
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index ace87cf42cf..e9eca06a72a 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -250,7 +250,7 @@
 #define __cpp_lib_ssize 201902L
 #define __cpp_lib_starts_ends_with 201711L
 # if _GLIBCXX_USE_CXX11_ABI
-// Only supported with cx11-abi
+// Only supported with cxx11-abi
 #  define __cpp_lib_syncbuf 201803L
 # endif
 #define __cpp_lib_to_address 201711L
@@ -260,6 +260,7 @@
 #if __cplusplus > 202002L
 // c++2b
 #define __cpp_lib_string_contains 202011L
+#define __cpp_lib_to_underlying 202102L
 #endif // C++2b
 #endif // C++20
 #endif // C++17
diff --git a/libstdc++-v3/testsuite/20_util/to_underlying/1.cc 
b/libstdc++-v3/testsuite/20_util/to_underlying/1.cc
new file mode 100644
index 000..5d2b150230f
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/to_underlying/1.cc
@@ -0,0 +1,38 @@
+// Copyright (C) 2021 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++23" }
+// { dg-do compile { target c++23 } }
+
+#include 
+
+#ifndef __cpp_lib_to_underlying
+# error "Feature-test macro for to_underlying missing in "
+#elif __cpp_lib_to_underlying != 202102L
+# error "Feature-test macro for to_underlying has wrong value in "
+#endif
+
+void
+test01()
+{
+  enum E : short { e0, e1, e2 };
+  E e = e0;
+  static_assert( std::is_same_v );
+  static_assert( noexcept(std::to_underlying(e)) );
+  static_assert( std::to_underlying(e1) == 1 );
+  static_assert( std::to_underlying((E)3) == 3 );
+}
diff --git a/libstdc++-v3/testsuite/20_util/to_underlying/version.cc 
b/libstdc++-v3/testsuite/20_util/to_underlying/version.cc
new file mode 100644
index 000..418bbff3702
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/to_underlying/version.cc
@@ -0,0 +1,27 @@
+// Copyright (C) 2021 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++23" }
+// { dg-do compile { target c++23 } }
+
+#include 
+
+#ifndef __cpp_lib_to_underlying
+# error "Feature-test macro for 

Fortran: Create CLASS(*) early to avoid ICE [PR99254]

[Tobias Burnus]

The issue is that for CLASS – and in particular CLASS(*)
the ts.u.derived->components is not yet created when it is
accessed. – PR99138 shows a similar case (unfixed!
See comment 5 and initial report for two examples).

There is an issue for code like:
  class(*) var
  dimension :: var(..)
that the attribute is not properly encoded in the class.
That's independent of this patch, cf. PR fortran/99266.

NOTE: This patch causes a regression:
  subroutine foo()
class(*) :: x
allocatable :: x
is now rejected with:
  CLASS variable ‘x’ at (1) must be dummy, allocatable or pointer

HOWEVER: While that was accepted before,
  subroutine foo(dummy)
class(*) :: dummy
allocatable :: dummy
failed before and still fails. (→ class_ok handling in
gfc_build_class_symbol).

All those issues are tracked in that PR fortran/99266.

OK for the trunk? What about GCC 10??

I am unsure about GCC 10 due to the new regression;
the issue (PR99254) was reported as new ICE between
20190825 and 20190901.

Tobias

PS: I still do not like the way we represent CLASS internally,
but I think I had complained about this already years ago...
Can proponents of the current way please look at
PR fortran/99266 ?

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf
Fortran: Create CLASS(*) early to avoid ICE [PR99254]

gcc/fortran/ChangeLog:

	PR fortran/99254
	* class.c (gfc_build_class_symbol): Always build for CLASS(*).

gcc/testsuite/ChangeLog:

	PR fortran/99254
	* gfortran.dg/class_72.f90: New test.
	* gfortran.dg/pr96086.f90: Update dg-error.

 gcc/fortran/class.c|  5 -
 gcc/testsuite/gfortran.dg/class_72.f90 | 26 ++
 gcc/testsuite/gfortran.dg/pr96086.f90  |  4 ++--
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 89353218417..e49f5a5df77 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -659,7 +659,10 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
   attr->class_ok = attr->dummy || attr->pointer || attr->allocatable
 		   || attr->select_type_temporary || attr->associate_var;
 
-  if (!attr->class_ok)
+  bool build_star = (ts->u.derived && !ts->u.derived->components
+		 && ts->u.derived->attr.unlimited_polymorphic);
+
+  if (!attr->class_ok && !build_star)
 /* We cannot build the class container yet.  */
 return true;
 
diff --git a/gcc/testsuite/gfortran.dg/class_72.f90 b/gcc/testsuite/gfortran.dg/class_72.f90
new file mode 100644
index 000..0e181b27086
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_72.f90
@@ -0,0 +1,26 @@
+! { dg-do compile }
+!
+! PR fortran/99254
+!
+! Contributed by G. Steinmetz
+!
+subroutine s1
+   class(*) :: x(..)  ! { dg-error "must be dummy, allocatable or pointer" }
+   select rank (y => x)
+   rank (1)
+   end select
+end
+
+subroutine s2
+   class(*), allocatable :: x(..)  ! { dg-error "Assumed-rank array at .1. must be a dummy argument" }
+   select rank (y => x)
+   rank (1)
+   end select
+end
+
+subroutine s3(x)
+   class(*) :: x(..)
+   select rank (y => x)
+   rank (1)
+   end select
+end
diff --git a/gcc/testsuite/gfortran.dg/pr96086.f90 b/gcc/testsuite/gfortran.dg/pr96086.f90
index b80967a7a07..58f11f51028 100644
--- a/gcc/testsuite/gfortran.dg/pr96086.f90
+++ b/gcc/testsuite/gfortran.dg/pr96086.f90
@@ -2,7 +2,7 @@
 ! PR fortran/96086 - ICE in gfc_match_select_rank, at fortran/match.c:6645
 
 subroutine s
-  class(*) :: x(..) ! { dg-error "Assumed-rank array" }
-  select rank (y => x)  ! { dg-error "CLASS variable" }
+  class(*) :: x(..) ! { dg-error "must be dummy, allocatable or pointer" }
+  select rank (y => x)
   end select
 end

[PATCH] tree-optimization/99253 - fix reduction path check

[Richard Biener]

This fixes an ordering problem with verifying that no intermediate
computations in a reduction path are used outside of the chain.  The
check was disabled for value-preserving conversions at the tail
but whether a stmt was a conversion or not was only computed after
the first use.  The following fixes this by re-ordering things
accordingly.

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

2021-02-25  Richard Biener  

PR tree-optimization/99253
* tree-vect-loop.c (check_reduction_path): First compute
code, then verify out-of-loop uses.

* gcc.dg/vect/pr99253.c: New testcase.
---
 gcc/testsuite/gcc.dg/vect/pr99253.c | 22 
 gcc/tree-vect-loop.c| 56 ++---
 2 files changed, 50 insertions(+), 28 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr99253.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr99253.c 
b/gcc/testsuite/gcc.dg/vect/pr99253.c
new file mode 100644
index 000..9e3345025ba
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr99253.c
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+
+#include "tree-vect.h"
+
+int a = 0;
+static int b = 0;
+long c = 0;
+
+int
+main()
+{
+  check_vect ();
+  for (int d = 0; d < 8; d++)
+{
+  a ^= c;
+  b = a;
+  a ^= 1;
+}
+  if (a != 0 || b != 1)
+__builtin_abort();
+  return 0;
+}
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 27845c01430..3e973e774af 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -3432,34 +3432,6 @@ pop:
  fail = true;
  break;
}
-  /* Check there's only a single stmt the op is used on.  For the
-not value-changing tail and the last stmt allow out-of-loop uses.
-???  We could relax this and handle arbitrary live stmts by
-forcing a scalar epilogue for example.  */
-  imm_use_iterator imm_iter;
-  gimple *op_use_stmt;
-  unsigned cnt = 0;
-  FOR_EACH_IMM_USE_STMT (op_use_stmt, imm_iter, op)
-   if (!is_gimple_debug (op_use_stmt)
-   && (*code != ERROR_MARK
-   || flow_bb_inside_loop_p (loop, gimple_bb (op_use_stmt
- {
-   /* We want to allow x + x but not x < 1 ? x : 2.  */
-   if (is_gimple_assign (op_use_stmt)
-   && gimple_assign_rhs_code (op_use_stmt) == COND_EXPR)
- {
-   use_operand_p use_p;
-   FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
- cnt++;
- }
-   else
- cnt++;
- }
-  if (cnt != 1)
-   {
- fail = true;
- break;
-   }
   tree_code use_code = gimple_assign_rhs_code (use_stmt);
   if (use_code == MINUS_EXPR)
{
@@ -3489,6 +3461,34 @@ pop:
  fail = true;
  break;
}
+  /* Check there's only a single stmt the op is used on.  For the
+not value-changing tail and the last stmt allow out-of-loop uses.
+???  We could relax this and handle arbitrary live stmts by
+forcing a scalar epilogue for example.  */
+  imm_use_iterator imm_iter;
+  gimple *op_use_stmt;
+  unsigned cnt = 0;
+  FOR_EACH_IMM_USE_STMT (op_use_stmt, imm_iter, op)
+   if (!is_gimple_debug (op_use_stmt)
+   && (*code != ERROR_MARK
+   || flow_bb_inside_loop_p (loop, gimple_bb (op_use_stmt
+ {
+   /* We want to allow x + x but not x < 1 ? x : 2.  */
+   if (is_gimple_assign (op_use_stmt)
+   && gimple_assign_rhs_code (op_use_stmt) == COND_EXPR)
+ {
+   use_operand_p use_p;
+   FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
+ cnt++;
+ }
+   else
+ cnt++;
+ }
+  if (cnt != 1)
+   {
+ fail = true;
+ break;
+   }
 }
   return ! fail && ! neg && *code != ERROR_MARK;
 }
-- 
2.26.2

Re: [PATCH] match.pd: Use single_use for (T)(A) + CST -> (T)(A + CST) [PR95798]

[Richard Biener]

On Thu, 25 Feb 2021, Jakub Jelinek wrote:

> On Wed, Feb 24, 2021 at 08:56:55PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Feb 24, 2021 at 08:52:44PM +0100, Marc Glisse wrote:
> > > On Wed, 24 Feb 2021, Jakub Jelinek via Gcc-patches wrote:
> > > 
> > > > The following patch adds single_use case which restores these testcases
> > > > but keeps the testcases the patch meant to improve as is.
> > > 
> > > Hello,
> > > 
> > > I wonder if :s would be sufficient here? I don't have an opinion on which
> > > one is better for this particular transformation (don't change the patch
> > > because of my comment), we just seem to be getting more and more uses of
> > > single_use in match.pd, maybe at some point we need to revisit the meaning
> > > of :s or introduce a stronger :S.
> > 
> > :s seems to work for these testcases too, I'm never sure about :s
> > vs. single_use.
> 
> Following passed bootstrap/regtest on x86_64-linux and i686-linux too.

OK.

Thanks,
Richard.

> 2021-02-24  Jakub Jelinek  
> 
>   PR target/95798
>   * match.pd ((T)(A) + CST -> (T)(A + CST)): Add :s to convert.
> 
>   * gcc.target/i386/pr95798-1.c: New test.
>   * gcc.target/i386/pr95798-2.c: New test.
> 
> --- gcc/match.pd.jj   2021-02-24 12:58:22.233006845 +0100
> +++ gcc/match.pd  2021-02-24 20:54:41.970241132 +0100
> @@ -2492,7 +2492,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  /* ((T)(A)) + CST -> (T)(A + CST)  */
>  #if GIMPLE
>(simplify
> -   (plus (convert SSA_NAME@0) INTEGER_CST@1)
> +   (plus (convert:s SSA_NAME@0) INTEGER_CST@1)
>  (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
>   && TREE_CODE (type) == INTEGER_TYPE
>   && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
> --- gcc/testsuite/gcc.target/i386/pr95798-1.c.jj  2021-02-24 
> 15:58:06.935598077 +0100
> +++ gcc/testsuite/gcc.target/i386/pr95798-1.c 2021-02-24 16:02:47.298504500 
> +0100
> @@ -0,0 +1,29 @@
> +/* PR target/95798 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -masm=att" } */
> +/* { dg-final { scan-assembler "1, 8\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "2, 16\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "3, 24\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "4, 32\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "5, 40\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "6, 48\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "7, 56\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +
> +void bar (unsigned long long *, int);
> +
> +void
> +foo (int y, unsigned long long z)
> +{
> +  unsigned long long x[1024];
> +  unsigned long long i = y % 127;
> +  __builtin_memset (x, -1, sizeof (x));
> +  x[i] = 0;
> +  x[i + 1] = 1;
> +  x[i + 2] = 2;
> +  x[i + 3] = 3;
> +  x[i + 4] = 4;
> +  x[i + 5] = 5;
> +  x[i + 6] = 6;
> +  x[i + 7] = 7;
> +  bar (x, y);
> +}
> --- gcc/testsuite/gcc.target/i386/pr95798-2.c.jj  2021-02-24 
> 16:01:39.708250302 +0100
> +++ gcc/testsuite/gcc.target/i386/pr95798-2.c 2021-02-24 16:03:57.497729907 
> +0100
> @@ -0,0 +1,29 @@
> +/* PR target/95798 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -masm=att" } */
> +/* { dg-final { scan-assembler "1, 8\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "2, 16\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "3, 24\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "4, 32\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "5, 40\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "6, 48\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +/* { dg-final { scan-assembler "7, 56\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
> lp64 } } } */
> +
> +void bar (unsigned long long *, int);
> +
> +void
> +foo (unsigned int y, unsigned long long z)
> +{
> +  unsigned long long x[1024];
> +  unsigned long long i = y % 127;
> +  __builtin_memset (x, -1, sizeof (x));
> +  x[i] = 0;
> +  x[i + 1] = 1;
> +  x[i + 2] = 2;
> +  x[i + 3] = 3;
> +  x[i + 4] = 4;
> +  x[i + 5] = 5;
> +  x[i + 6] = 6;
> +  x[i + 7] = 7;
> +  bar (x, y);
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] vrp: Handle VCE in vrp_simplify_cond_using_ranges [PR80635]

[Richard Biener]

On Wed, 24 Feb 2021, Jakub Jelinek wrote:

> On Wed, Feb 24, 2021 at 01:32:02PM +0100, Richard Biener wrote:
> > Small comment about the patch below, which otherwise is OK:
> > 
> > I think that !INTEGRAL_TYPE_P (TREE_TYPE (innerop)) is a sufficient
> > condition here.
> 
> Unfortunately as shown during the bootstrap, that patch contained a fatal
> thinko, 
> > > + default:
> > > +   break;
> 
> for default: we need return;
> 
> Here is a version of the patch that passed bootstrap/regtest on x86_64-linux
> and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2021-02-24  Jakub Jelinek  
> 
>   PR tree-optimization/80635
>   * tree-vrp.c (vrp_simplify_cond_using_ranges): Also handle
>   VIEW_CONVERT_EXPR if modes are the same, innerop is integral and
>   has mode precision.
> 
>   * g++.dg/warn/pr80635-1.C: New test.
>   * g++.dg/warn/pr80635-2.C: New test.
> 
> --- gcc/tree-vrp.c.jj 2021-02-24 12:56:58.573939572 +0100
> +++ gcc/tree-vrp.c2021-02-24 13:05:22.675326780 +0100
> @@ -4390,11 +4390,22 @@ vrp_simplify_cond_using_ranges (vr_value
>gimple *def_stmt = SSA_NAME_DEF_STMT (op0);
>tree innerop;
>  
> -  if (!is_gimple_assign (def_stmt)
> -   || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
> +  if (!is_gimple_assign (def_stmt))
>   return;
>  
> -  innerop = gimple_assign_rhs1 (def_stmt);
> +  switch (gimple_assign_rhs_code (def_stmt))
> + {
> + CASE_CONVERT:
> +   innerop = gimple_assign_rhs1 (def_stmt);
> +   break;
> + case VIEW_CONVERT_EXPR:
> +   innerop = TREE_OPERAND (gimple_assign_rhs1 (def_stmt), 0);
> +   if (!INTEGRAL_TYPE_P (TREE_TYPE (innerop)))
> + return;
> +   break;
> + default:
> +   return;
> + }
>  
>if (TREE_CODE (innerop) == SSA_NAME
> && !POINTER_TYPE_P (TREE_TYPE (innerop))
> --- gcc/testsuite/g++.dg/warn/pr80635-1.C.jj  2021-02-24 12:24:15.176834532 
> +0100
> +++ gcc/testsuite/g++.dg/warn/pr80635-1.C 2021-02-24 12:24:15.176834532 
> +0100
> @@ -0,0 +1,46 @@
> +// PR tree-optimization/80635
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-O2 -Wmaybe-uninitialized" }
> +
> +using size_t = decltype (sizeof (1));
> +inline void *operator new (size_t, void *p) { return p; }
> +template
> +struct optional
> +{
> +  optional () : m_dummy (), live (false) {}
> +  void emplace () { new (_item) T (); live = true; }
> +  ~optional () { if (live) m_item.~T (); }
> +
> +  union
> +  {
> +struct {} m_dummy;
> +T m_item;
> +  };
> +  bool live;
> +};
> +
> +extern int get ();
> +extern void set (int);
> +
> +struct A
> +{
> +  A () : m (get ()) {}
> +  ~A () { set (m); } // { dg-bogus "may be used uninitialized in this 
> function" }
> +
> +  int m;
> +};
> +
> +struct B
> +{
> +  B ();
> +  ~B ();
> +};
> +
> +void func ()
> +{
> +  optional maybe_a;
> +  optional maybe_b;
> +
> +  maybe_a.emplace ();
> +  maybe_b.emplace ();
> +}
> --- gcc/testsuite/g++.dg/warn/pr80635-2.C.jj  2021-02-24 12:24:15.176834532 
> +0100
> +++ gcc/testsuite/g++.dg/warn/pr80635-2.C 2021-02-24 12:24:15.176834532 
> +0100
> @@ -0,0 +1,31 @@
> +// PR tree-optimization/80635
> +// { dg-do compile { target c++17 } }
> +// { dg-options "-O2 -Wmaybe-uninitialized" }
> +
> +#include 
> +
> +extern int get ();
> +extern void set (int);
> +
> +struct A
> +{
> +  A () : m (get ()) {}
> +  ~A () { set (m); } // { dg-bogus "may be used uninitialized in this 
> function" }
> +
> +  int m;
> +};
> +
> +struct B
> +{
> +  B ();
> +  ~B ();
> +};
> +
> +void func ()
> +{
> +  std::optional maybe_a;
> +  std::optional maybe_b;
> +
> +  maybe_a.emplace ();
> +  maybe_b.emplace ();
> +}
> 
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH,rs6000] [v2] Optimize pcrel access of globals

[Richard Biener via Gcc-patches]

On Wed, Feb 24, 2021 at 6:39 PM Segher Boessenkool
 wrote:
>
> Hi!
>
> On Tue, Feb 23, 2021 at 09:48:28AM +0100, Richard Biener wrote:
> > On Tue, Feb 23, 2021 at 4:48 AM acsawdey--- via Gcc-patches
> >  wrote:
> > >
> > > From: Aaron Sawdey 
> > >
> > > This patch implements a RTL pass that looks for pc-relative loads of the
> > > address of an external variable using the PCREL_GOT relocation and a
> > > single load or store that uses that external address.
> > >
> > > Produced by a cast of thousands:
> > >  * Michael Meissner
> > >  * Peter Bergner
> > >  * Bill Schmidt
> > >  * Alan Modra
> > >  * Segher Boessenkool
> > >  * Aaron Sawdey
> > >
> > > This incorporates the changes requested in Segher's review. A few things I
> > > did not change were the insn-at-a-time scan that could be done with DF, 
> > > and
> > > I did not change to using statistics.[ch] for the counters struct. I did 
> > > try
> > > to improve the naming, and rewrote a number of comments to make them 
> > > consistent
> > > with the code, and generally tried to make things more readable.
> > >
> > > OK for trunk if bootstrap/regtest passes?
> >
> > stage1 please?
>
> Versions of this patch were first submitted in August.  Of 2019.
>
> We have quite a lot of experience with it so far.  There are no known
> wrong-code (or ICE) problems with it.
>
> All of this is only when targetting power10 (which isn't shipping
> hardware yet), and is behind a flag anyway, so you can easily disable
> the optimisation.
>
> So, there is virtually no risk.

So it's enabled by default when targeting power10?  But power10
won't ship before the GCC 11 release?

> On the other hand, we do want to get this into the hands of everyone
> who should test it, and trunk works so much better for that than private
> builds or patch sets.
>
> If it misses 11.1, we'll have to backport it to 11.2 .

I see.

> So, I'd really like it to get in now.  Do any of these arguments change
> your position on that?

Well, in the end target maintainers have the say on target specific
changes.  I guess hitting problems with the patch in testing GCC 11
is unlikely to happen, and if it does we won't block shipping 11.1.

I do note that GCC 10 seems to know -mpower10 so technically
such "regression" would block a release.

Richard.

>
> Segher

[PATCH] Make the PR99220 fix more robust

[Richard Biener]

This avoids interleaving pattern recognition and load redistribution
optimization since the load_map used in the latter is fragile with
respect to release and reuse of SLP nodes, something which can also
occur within the pattern recognition machinery.

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

2021-02-25  Richard Biener  

* tree-vect-slp.c (optimize_load_redistribution_1): Delay
load_map population.
(vect_match_slp_patterns_2): Revert part of last change.
(vect_analyze_slp): Do not interleave optimize_load_redistribution
with pattern detection but do it afterwards.  Dump the
whole SLP graph after pattern recognition and load
redistribution optimization finished.
---
 gcc/tree-vect-slp.c | 53 +
 1 file changed, 30 insertions(+), 23 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index c55c01a4a94..430c66c6f3c 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -2294,8 +2294,6 @@ optimize_load_redistribution_1 
(scalar_stmts_to_slp_tree_map_t *bst_map,
   if (slp_tree *leader = load_map->get (root))
 return *leader;
 
-  load_map->put (root, NULL);
-
   slp_tree node;
   unsigned i;
 
@@ -2342,6 +2340,8 @@ optimize_load_redistribution_1 
(scalar_stmts_to_slp_tree_map_t *bst_map,
 }
 
 next:
+  load_map->put (root, NULL);
+
   FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (root), i , node)
 {
   slp_tree value
@@ -2352,11 +2352,10 @@ next:
  SLP_TREE_REF_COUNT (value)++;
  SLP_TREE_CHILDREN (root)[i] = value;
  /* ???  We know the original leafs of the replaced nodes will
-   be referenced by bst_map, only the permutes created by
- pattern matching are not.  */
+be referenced by bst_map, only the permutes created by
+pattern matching are not.  */
  if (SLP_TREE_REF_COUNT (node) == 1)
load_map->remove (node);
-
  vect_free_slp_tree (node);
}
 }
@@ -2394,7 +2393,6 @@ optimize_load_redistribution 
(scalar_stmts_to_slp_tree_map_t *bst_map,
 pattern matching are not.  */
  if (SLP_TREE_REF_COUNT (node) == 1)
load_map->remove (node);
-
  vect_free_slp_tree (node);
}
 }
@@ -2417,9 +2415,7 @@ vect_match_slp_patterns_2 (slp_tree *ref_node, vec_info 
*vinfo,
   slp_tree node = *ref_node;
   bool found_p = false;
   if (!node || visited->add (node))
-return node
-  && SLP_TREE_REPRESENTATIVE (node)
-  && STMT_VINFO_SLP_VECT_ONLY_PATTERN (SLP_TREE_REPRESENTATIVE (node));
+return false;
 
   slp_tree child;
   FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (node), i, child)
@@ -2898,23 +2894,24 @@ vect_analyze_slp (vec_info *vinfo, unsigned 
max_tree_size)
 
   hash_set visited_patterns;
   slp_tree_to_load_perm_map_t perm_cache;
-  hash_map load_map;
 
   /* See if any patterns can be found in the SLP tree.  */
+  bool pattern_found = false;
   FOR_EACH_VEC_ELT (LOOP_VINFO_SLP_INSTANCES (vinfo), i, instance)
-if (vect_match_slp_patterns (instance, vinfo, _patterns,
-_cache))
-  {
-   slp_tree root = SLP_INSTANCE_TREE (instance);
-   optimize_load_redistribution (bst_map, vinfo, SLP_TREE_LANES (root),
- _map, root);
-   if (dump_enabled_p ())
- {
-   dump_printf_loc (MSG_NOTE, vect_location,
-"Pattern matched SLP tree\n");
-   vect_print_slp_graph (MSG_NOTE, vect_location, root);
- }
-  }
+pattern_found |= vect_match_slp_patterns (instance, vinfo,
+ _patterns, _cache);
+
+  /* If any were found optimize permutations of loads.  */
+  if (pattern_found)
+{
+  hash_map load_map;
+  FOR_EACH_VEC_ELT (LOOP_VINFO_SLP_INSTANCES (vinfo), i, instance)
+   {
+ slp_tree root = SLP_INSTANCE_TREE (instance);
+ optimize_load_redistribution (bst_map, vinfo, SLP_TREE_LANES (root),
+   _map, root);
+   }
+}
 
 
 
@@ -2925,6 +2922,16 @@ vect_analyze_slp (vec_info *vinfo, unsigned 
max_tree_size)
   vect_free_slp_tree ((*it).second);
   delete bst_map;
 
+  if (pattern_found && dump_enabled_p ())
+{
+  dump_printf_loc (MSG_NOTE, vect_location,
+  "Pattern matched SLP tree\n");
+  hash_set visited;
+  FOR_EACH_VEC_ELT (LOOP_VINFO_SLP_INSTANCES (vinfo), i, instance)
+   vect_print_slp_graph (MSG_NOTE, vect_location,
+ SLP_INSTANCE_TREE (instance), visited);
+}
+
   return opt_result::success ();
 }
 
-- 
2.26.2

Re: [PATCH] match.pd, expand: Fold VCE from integer with [0, 1] range to bool into NOP_EXPR [PR80635]

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 24, 2021 at 05:54:08PM -0700, Martin Sebor via Gcc-patches wrote:
> > > Why does uninit warn with VCE but not with NOP_EXPR?  Or does the
> > > warning disappear because of those other optimizations you mention?
> 
> Can you comment on Jeff's POC patch in the PR?  Would it make sense
> to apply it (with adjustments if necessary) as well to make the warning
> more robust in case the VCE comes back?

It has been a while since I looked into uninit pass in detail, so I don't
know if it is the right spot to do it, but as my mail clearly states,
it is not just about VIEW_CONVERT_EXPR, demoting NOP_EXPR/CONVERT_EXPR
that vrp_simplify_cond_using_ranges doesn't simplify are the same case.

So, if the uninit pass was to be made robust against tree-vrp.c not doing
its job, then it would basically need to virtually repeat
vrp_simplify_cond_using_ranges (using either get_range_info or ranger).
I'm not convinced it is the right way though to account for possibilities
of disabled passes by repeating their code in other passes.

Jakub

Re: [PATCH] match.pd: Use single_use for (T)(A) + CST -> (T)(A + CST) [PR95798]

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 24, 2021 at 08:56:55PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Feb 24, 2021 at 08:52:44PM +0100, Marc Glisse wrote:
> > On Wed, 24 Feb 2021, Jakub Jelinek via Gcc-patches wrote:
> > 
> > > The following patch adds single_use case which restores these testcases
> > > but keeps the testcases the patch meant to improve as is.
> > 
> > Hello,
> > 
> > I wonder if :s would be sufficient here? I don't have an opinion on which
> > one is better for this particular transformation (don't change the patch
> > because of my comment), we just seem to be getting more and more uses of
> > single_use in match.pd, maybe at some point we need to revisit the meaning
> > of :s or introduce a stronger :S.
> 
> :s seems to work for these testcases too, I'm never sure about :s
> vs. single_use.

Following passed bootstrap/regtest on x86_64-linux and i686-linux too.

2021-02-24  Jakub Jelinek  

PR target/95798
* match.pd ((T)(A) + CST -> (T)(A + CST)): Add :s to convert.

* gcc.target/i386/pr95798-1.c: New test.
* gcc.target/i386/pr95798-2.c: New test.

--- gcc/match.pd.jj 2021-02-24 12:58:22.233006845 +0100
+++ gcc/match.pd2021-02-24 20:54:41.970241132 +0100
@@ -2492,7 +2492,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 /* ((T)(A)) + CST -> (T)(A + CST)  */
 #if GIMPLE
   (simplify
-   (plus (convert SSA_NAME@0) INTEGER_CST@1)
+   (plus (convert:s SSA_NAME@0) INTEGER_CST@1)
 (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
  && TREE_CODE (type) == INTEGER_TYPE
  && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
--- gcc/testsuite/gcc.target/i386/pr95798-1.c.jj2021-02-24 
15:58:06.935598077 +0100
+++ gcc/testsuite/gcc.target/i386/pr95798-1.c   2021-02-24 16:02:47.298504500 
+0100
@@ -0,0 +1,29 @@
+/* PR target/95798 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -masm=att" } */
+/* { dg-final { scan-assembler "1, 8\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target lp64 
} } } */
+/* { dg-final { scan-assembler "2, 16\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "3, 24\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "4, 32\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "5, 40\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "6, 48\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "7, 56\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+
+void bar (unsigned long long *, int);
+
+void
+foo (int y, unsigned long long z)
+{
+  unsigned long long x[1024];
+  unsigned long long i = y % 127;
+  __builtin_memset (x, -1, sizeof (x));
+  x[i] = 0;
+  x[i + 1] = 1;
+  x[i + 2] = 2;
+  x[i + 3] = 3;
+  x[i + 4] = 4;
+  x[i + 5] = 5;
+  x[i + 6] = 6;
+  x[i + 7] = 7;
+  bar (x, y);
+}
--- gcc/testsuite/gcc.target/i386/pr95798-2.c.jj2021-02-24 
16:01:39.708250302 +0100
+++ gcc/testsuite/gcc.target/i386/pr95798-2.c   2021-02-24 16:03:57.497729907 
+0100
@@ -0,0 +1,29 @@
+/* PR target/95798 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -masm=att" } */
+/* { dg-final { scan-assembler "1, 8\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target lp64 
} } } */
+/* { dg-final { scan-assembler "2, 16\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "3, 24\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "4, 32\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "5, 40\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "6, 48\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+/* { dg-final { scan-assembler "7, 56\\\(%rsp,%r\[a-z0-9]*,8\\\)" { target 
lp64 } } } */
+
+void bar (unsigned long long *, int);
+
+void
+foo (unsigned int y, unsigned long long z)
+{
+  unsigned long long x[1024];
+  unsigned long long i = y % 127;
+  __builtin_memset (x, -1, sizeof (x));
+  x[i] = 0;
+  x[i + 1] = 1;
+  x[i + 2] = 2;
+  x[i + 3] = 3;
+  x[i + 4] = 4;
+  x[i + 5] = 5;
+  x[i + 6] = 6;
+  x[i + 7] = 7;
+  bar (x, y);
+}

Jakub