Re: [PATCH] bswap: Handle bswapping of pointers [PR96573]

[Richard Biener]

On Wed, 31 Mar 2021, Jakub Jelinek wrote:

> Hi!
> 
> In GCC8/9 we used to optimize this into a bswap, but we no longer do.
> Handling byteswapping of pointers is easy, all we need is to allow them,
> for the __builtin_bswap* we already use TYPE_PRECISION to determine
> the precision and we cast the operand and result to the correct type
> if they aren't uselessly convertible to what the builtin expects.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2021-03-31  Jakub Jelinek  
> 
>   PR tree-optimization/96573
>   * gimple-ssa-store-merging.c (init_symbolic_number): Handle
>   also pointer types.
> 
>   * gcc.dg/pr96573.c: New test.
> 
> --- gcc/gimple-ssa-store-merging.c.jj 2021-02-22 17:54:05.701798074 +0100
> +++ gcc/gimple-ssa-store-merging.c2021-03-31 11:30:55.519845647 +0200
> @@ -333,7 +333,7 @@ init_symbolic_number (struct symbolic_nu
>  {
>int size;
>  
> -  if (! INTEGRAL_TYPE_P (TREE_TYPE (src)))
> +  if (!INTEGRAL_TYPE_P (TREE_TYPE (src)) && !POINTER_TYPE_P (TREE_TYPE 
> (src)))
>  return false;
>  
>n->base_addr = n->offset = n->alias_set = n->vuse = NULL_TREE;
> --- gcc/testsuite/gcc.dg/pr96573.c.jj 2021-03-31 11:39:19.382122478 +0200
> +++ gcc/testsuite/gcc.dg/pr96573.c2021-03-31 11:39:54.186727148 +0200
> @@ -0,0 +1,20 @@
> +/* PR tree-optimization/96573 */
> +/* { dg-do compile { target { lp64 || ilp32 } } } */
> +/* { dg-require-effective-target bswap } */
> +/* { dg-options "-O3 -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-dump "__builtin_bswap" "optimized" } } */
> +
> +typedef __SIZE_TYPE__ size_t;
> +
> +void *
> +foo (void * const p)
> +{
> +  const size_t m = sizeof (p) - 1;
> +  const unsigned char * const o = (unsigned char*) &p;
> +  void *n;
> +  unsigned char * const q = (unsigned char *) &n;
> +  unsigned char i;
> +  for (i = 0; i <= m; ++i)
> +q[m - i] = o[i];
> +  return n;
> +}
> 
>   Jakub
> 
> 

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

Re: [PATCH] sra: Fix bug in grp_write propagation (PR 97009)

[Richard Biener]

On Wed, 31 Mar 2021, Martin Jambor wrote:

> Hi,
> 
> SRA represents parts of aggregates which are arrays accessed with
> unknown index as "unscalarizable regions."  When there are two such
> regions one within another and the outer is only read whereas the
> inner is written to, SRA fails to propagate that write information
> across assignments.  This means that a second aggregate can contain
> data while SRA thinks it does not and the pass can wrongly eliminate
> big chunks of assignment from that second aggregate into a third
> aggregate, which is what happens in PR 97009.
> 
> Fixed by checking all children of unscalariable accesses for the
> grp_write flag.
> 
> Bootstrap and testing on top of trunk and the gcc-10 branch is underway
> and I also plan to backport this to gcc-9.  OK if they pass?

OK.

Thanks,
Richard.

> Thanks,
> 
> Martin
> 
> 
> gcc/ChangeLog:
> 
> 2021-03-31  Martin Jambor  
> 
>   PR tree-optimization/97009
>   * tree-sra.c (access_or_its_child_written): New function.
>   (propagate_subaccesses_from_rhs): Use it instead of a simple grp_write
>   test.
> 
> gcc/testsuite/ChangeLog:
> 
> 2021-03-31  Martin Jambor  
> 
>   PR tree-optimization/97009
>   * gcc.dg/tree-ssa/pr97009.c: New test.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/pr97009.c | 66 +
>  gcc/tree-sra.c  | 15 +-
>  2 files changed, 80 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr97009.c
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr97009.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr97009.c
> new file mode 100644
> index 000..741dbc270c3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr97009.c
> @@ -0,0 +1,66 @@
> +/* { dg-do run } */
> +/* { dg-options "-O1" } */
> +
> +static int __attribute__((noipa))
> +get_5 (void)
> +{
> +  return 5;
> +}
> +
> +static int __attribute__((noipa))
> +verify_5 (int v)
> +{
> +  if (v != 5)
> +__builtin_abort ();
> +}
> +
> +struct T
> +{
> +  int w;
> +  int a[4];
> +};
> +
> +struct S
> +{
> +  int v;
> +  int x;
> +  struct T t[2];
> +  char alotofstuff[128];
> +};
> +
> +volatile int vol;
> +
> +void __attribute__((noipa))
> +consume_t (struct T t)
> +{
> +  vol = t.a[0];
> +}
> +
> +int __attribute__((noipa))
> +foo (int l1, int l2)
> +{
> +  struct S s1, s2, s3;
> +  int i, j;
> +
> +  s1.v = get_5 ();
> +  for (i = 0; i < l1; i++)
> +{
> +  for (j = 0; j < l2; j++)
> + s1.t[i].a[j] = get_5 ();
> +  consume_t(s1.t[i]);
> +}
> +
> +  s2 = s1;
> +
> +  s3 = s2;
> +  for (i = 0; i < l1; i++)
> +for (j = 0; j < l2; j++)
> +  verify_5 (s3.t[i].a[j]);
> +}
> +
> +int
> +main (int argc, char *argv[])
> +{
> +  foo (2, 4);
> +  return 0;
> +}
> diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
> index d177f1ba11c..8dfc923ed7e 100644
> --- a/gcc/tree-sra.c
> +++ b/gcc/tree-sra.c
> @@ -2723,6 +2723,19 @@ budget_for_propagation_access (tree decl)
>return true;
>  }
>  
> +/* Return true if ACC or any of its subaccesses has grp_child set.  */
> +
> +static bool
> +access_or_its_child_written (struct access *acc)
> +{
> +  if (acc->grp_write)
> +return true;
> +  for (struct access *sub = acc->first_child; sub; sub = sub->next_sibling)
> +if (access_or_its_child_written (sub))
> +  return true;
> +  return false;
> +}
> +
>  /* Propagate subaccesses and grp_write flags of RACC across an assignment 
> link
> to LACC.  Enqueue sub-accesses as necessary so that the write flag is
> propagated transitively.  Return true if anything changed.  Additionally, 
> if
> @@ -2836,7 +2849,7 @@ propagate_subaccesses_from_rhs (struct access *lacc, 
> struct access *racc)
>if (rchild->grp_unscalarizable_region
> || !budget_for_propagation_access (lacc->base))
>   {
> -   if (rchild->grp_write && !lacc->grp_write)
> +   if (!lacc->grp_write && access_or_its_child_written (rchild))
>   {
> ret = true;
> subtree_mark_written_and_rhs_enqueue (lacc);
> 

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

Re: [PATCH] c++, abi: Fix abi_tag attribute handling [PR98481]

[Richard Biener]

On Thu, 1 Apr 2021, Jakub Jelinek wrote:

> On Thu, Apr 01, 2021 at 12:52:20AM -0400, Jason Merrill wrote:
> > On 1/8/21 2:29 PM, Jakub Jelinek wrote:
> > > On Fri, Jan 08, 2021 at 02:22:59PM -0500, Jason Merrill wrote:
> > > > I like the idea to use *walk_subtrees to distinguish between walking
> > > > syntactic subtrees and walking type-identity subtrees.  But it should be
> > > > more general; how does this look to you?
> > > 
> > > LGTM, thanks.
> > 
> > As discussed on IRC, we probably want to fix this in GCC 10 as well, but not
> > by default.  The first patch adds ABI v15 and fixes the bug for !v14, so
> > -fabi-version=0 has the fix, but the default behavior does not.  The second
> > patch adds ABI v15 on trunk.
> > 
> > It would be nice to make -Wabi/-fabi-compat-version handle this case, but
> > that would require a bunch of new code unsuitable for this point in the
> > process.
> > 
> > Does this make sense to you?
> 
> LGTM, thanks.

LGTM as well.  I'd like to roll RC1 today around 2pm CEST, so I'm going
to give this a round of testing myself (also noticing the corresponding
trunk patch isn't in yet)

So if you can manage to push it before this time that would be great,
otherwise I guess I'm going to push it to 10.

Richard.

> > commit 123f254cce416a4d50445465b88af6d8e754dc5e
> > Author: Jakub Jelinek 
> > Date:   Thu Jan 7 17:47:18 2021 +0100
> > 
> > c++, abi: Fix abi_tag attribute handling [PR98481]
> > 
> > In GCC10 cp_walk_subtrees has been changed to walk template arguments.
> > As the following testcase, that changed the mangling of some functions.
> > I believe the previous behavior that find_abi_tags_r doesn't recurse 
> > into
> > template args has been the correct one, but setting *walk_subtrees = 0
> > for the types and handling the types subtree walking manually in
> > find_abi_tags_r looks too hard, there are a lot of subtrees and details 
> > what
> > should and shouldn't be walked, both in tree.c (walk_type_fields there,
> > which is static) and in cp_walk_subtrees itself.
> > 
> > The following patch abuses the fact that *walk_subtrees is an int to
> > tell cp_walk_subtrees it shouldn't walk the template args.
> > 
> > But we don't want to introduce an ABI change in the middle of the GCC 10
> > cycle, so the GCC 10 version of this patch introduces ABI v15 for the 
> > fix,
> > which will be available but not default in GCC 10.3.
> > 
> > Co-authored-by: Jason Merrill 
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/98481
> > * class.c (find_abi_tags_r): Set *walk_subtrees to 2 instead of 
> > 1
> > for types.
> > (mark_abi_tags_r): Likewise.
> > * tree.c (cp_walk_subtrees): If *walk_subtrees_p is 2, look 
> > through
> > typedefs.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/98481
> > * g++.dg/abi/abi-tag24.C: New test.
> > * g++.dg/abi/abi-tag24a.C: New test.
> > * g++.dg/abi/macro0.C: Adjust expected value.
> > 
> > gcc/ChangeLog:
> > 
> > PR c++/98481
> > * common.opt (fabi-version): Default to 14.
> > 
> > gcc/c-family/ChangeLog:
> > 
> > PR c++/98481
> > * c-opts.c (c_common_post_options): Bump latest_abi_version.
> > 
> > diff --git a/gcc/common.opt b/gcc/common.opt
> > index 9cc47b16cac..ec5235c3a41 100644
> > --- a/gcc/common.opt
> > +++ b/gcc/common.opt
> > @@ -956,10 +956,13 @@ Driver Undocumented
> >  ; 14: Corrects the mangling of nullptr expression.
> >  ; Default in G++ 10.
> >  ;
> > +; 15: Corrects G++ 10 ABI tag regression [PR98481].
> > +; Available, but not default, in G++ 10.3.
> > +;
> >  ; Additional positive integers will be assigned as new versions of
> >  ; the ABI become the default version of the ABI.
> >  fabi-version=
> > -Common Joined RejectNegative UInteger Var(flag_abi_version) Init(0)
> > +Common Joined RejectNegative UInteger Var(flag_abi_version) Init(14)
> >  The version of the C++ ABI in use.
> >  
> >  faggressive-loop-optimizations
> > diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
> > index 58ba0948e79..c51d6d34726 100644
> > --- a/gcc/c-family/c-opts.c
> > +++ b/gcc/c-family/c-opts.c
> > @@ -943,7 +943,7 @@ c_common_post_options (const char **pfilename)
> >  
> >/* Change flag_abi_version to be the actual current ABI level, for the
> >   benefit of c_cpp_builtins, and to make comparison simpler.  */
> > -  const int latest_abi_version = 14;
> > +  const int latest_abi_version = 15;
> >/* Generate compatibility aliases for ABI v11 (7.1) by default.  */
> >const int abi_compat_default = 11;
> >  
> > diff --git a/gcc/cp/class.c b/gcc/cp/class.c
> > index ed8f9527929..c0101130ba3 100644
> > --- a/gcc/cp/class.c
> > +++ b/gcc/cp/class.c
> > @@ -1450,6 +1450,10 @@ mark_or_check_tags (tree t, tree *tp, abi_tag_data 
> >

Re: [PATCH] modules : Make sure we include in system.h.

[Richard Biener via Gcc-patches]

On Wed, Mar 31, 2021 at 10:51 PM Iain Sandoe  wrote:
>
> Hi,
>
> This fixes a stage 1 bootstrap fail on some Darwin versions when the
> bootstrap compiler is clang / libc++ from Xcode.
>
> bootstrapped on x86_64-darwin16, x86_64-linux-gnu
> OK for master?

LGTM.

Thanks,
Richard.

> thanks
> Iain
>
> 
>
>
> It appears that many targets include the map header transitively in
> other std headers included from system.h.  However there are some
> editions of clang/libc++ in Xcode that do not, which results in a
> bootstrap fail - since when resolver.h is included  there is then a
> conflict in declaring abort().
>
> The fix is to ensure that map is pulled in by system.h and before
> resolver.h is included.  As a precautionary measure and to alert
> anyone perhaps adding another header to resolver.h this patch also
> gates the direct includes there on !IN_GCC.
>
> c++tools/ChangeLog:
>
> * resolver.h: Do not include std headers directly when
> building in GCC.
>
> gcc/cp/ChangeLog:
>
> * mapper-client.cc (INCLUDE_MAP): New; require map to be
> included from system.h.
> * mapper-resolver.cc (INCLUDE_MAP): Likewise.
> ---
>   c++tools/resolver.h   | 2 ++
>   gcc/cp/mapper-client.cc   | 1 +
>   gcc/cp/mapper-resolver.cc | 1 +
>   3 files changed, 4 insertions(+)
>
> diff --git a/c++tools/resolver.h b/c++tools/resolver.h
> index 19339125b26..a9547bf6994 100644
> --- a/c++tools/resolver.h
> +++ b/c++tools/resolver.h
> @@ -24,8 +24,10 @@ along with GCC; see the file COPYING3.  If not see
>   // Mapper interface for client and server bits
>   #include "cody.hh"
>   // C++
> +#if !IN_GCC
>   #include 
>   #include 
> +#endif
>
>   // This is a GCC class, so GCC coding conventions on new bits.
>   class module_resolver : public Cody::Resolver
> diff --git a/gcc/cp/mapper-client.cc b/gcc/cp/mapper-client.cc
> index 774e2b2b095..b9e02168d55 100644
> --- a/gcc/cp/mapper-client.cc
> +++ b/gcc/cp/mapper-client.cc
> @@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.  If not see
>   #endif
>   #define INCLUDE_STRING
>   #define INCLUDE_VECTOR
> +#define INCLUDE_MAP
>   #include "system.h"
>
>   #include "line-map.h"
> diff --git a/gcc/cp/mapper-resolver.cc b/gcc/cp/mapper-resolver.cc
> index bcf6c8871e5..db443fb4948 100644
> --- a/gcc/cp/mapper-resolver.cc
> +++ b/gcc/cp/mapper-resolver.cc
> @@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  If not see
>   #define INCLUDE_STRING
>   #define INCLUDE_VECTOR
>   #define INCLUDE_ALGORITHM
> +#define INCLUDE_MAP
>   #include "system.h"
>
>   // We don't want or need to be aware of networking
> --
> 2.24.1
>
>

[PATCH] tree-optimization/99856 - fix overwideing pattern creation

[Richard Biener]

This fixes an omission of promoting a bit-precision required precision
to a vector element precision.

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

2021-04-01  Richard Biener  

PR tree-optimization/99856
* tree-vect-patterns.c (vect_recog_over_widening_pattern): Promote
precision to vector element precision.

* gcc.dg/vect/pr99856.c: New testcase.
---
 gcc/testsuite/gcc.dg/vect/pr99856.c | 33 +
 gcc/tree-vect-patterns.c|  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr99856.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr99856.c 
b/gcc/testsuite/gcc.dg/vect/pr99856.c
new file mode 100644
index 000..e5d2a45be57
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr99856.c
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_unpack } */
+/* { dg-require-effective-target vect_pack_trunc } */
+
+#define SHIFTFORDIV255(a)\
+a) >> 8) + a) >> 8)
+
+#define DIV255(a)\
+SHIFTFORDIV255(a + 0x80)
+
+typedef unsigned char uint8_t;
+
+void
+opSourceOver_premul(uint8_t* restrict Rrgba,
+const uint8_t* restrict Srgba,
+const uint8_t* restrict Drgba, int len)
+{
+  Rrgba = __builtin_assume_aligned (Rrgba, __BIGGEST_ALIGNMENT__);
+  Srgba = __builtin_assume_aligned (Rrgba, __BIGGEST_ALIGNMENT__);
+  Drgba = __builtin_assume_aligned (Rrgba, __BIGGEST_ALIGNMENT__);
+  int i = 0;
+  for (; i < len*4; i += 4)
+{
+  uint8_t Sa = Srgba[i + 3];
+  Rrgba[i + 0] = DIV255(Srgba[i + 0] * 255 + Drgba[i + 0] * (255 - Sa));
+  Rrgba[i + 1] = DIV255(Srgba[i + 1] * 255 + Drgba[i + 1] * (255 - Sa));
+  Rrgba[i + 2] = DIV255(Srgba[i + 2] * 255 + Drgba[i + 2] * (255 - Sa));
+  Rrgba[i + 3] = DIV255(Srgba[i + 3] * 255 + Drgba[i + 3] * (255 - Sa));
+}
+}
+
+/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" } } */
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index b575b456301..803de3fc287 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -1705,6 +1705,7 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
   /* Apply the minimum efficient precision we just calculated.  */
   if (new_precision < min_precision)
 new_precision = min_precision;
+  new_precision = vect_element_precision (new_precision);
   if (new_precision >= TYPE_PRECISION (type))
 return NULL;
 
-- 
2.26.2

Re: Small refactoring of cgraph_node::release_body

[Christophe Lyon via Gcc-patches]

Hi,

On Wed, 31 Mar 2021 at 11:38, Jan Hubicka  wrote:
>
> Hi,
> in the dicussion on PR 99447 there was some confusion about release_body
> being used in context where call edges/references survive. This is not
> a valid use because it would leave stale pointers to ggc_freed memory
> location. By auditing code I did not find any however this patch moves
> the callees/references removal into the function itself that makes it
> bit more robust.
>
> Some code paths calling release_body already free these earlier, but
> checking poitners for being NULL is not that expensive.
>
> Bootstrapped/regtested x86_64-linux, comitted.

This patch is causing ICEs on arm and aarch64, and others according to
gcc-testresults:
on aarch64:
g++.dg/ipa/devirt-7.C  -std=gnu++14 (internal compiler error)
g++.dg/ipa/devirt-7.C  -std=gnu++17 (internal compiler error)
g++.dg/ipa/devirt-7.C  -std=gnu++2a (internal compiler error)
g++.dg/ipa/devirt-7.C  -std=gnu++98 (internal compiler error)
g++.dg/ipa/pr71146.C  -std=gnu++14 (internal compiler error)
g++.dg/ipa/pr71146.C  -std=gnu++17 (internal compiler error)
g++.dg/ipa/pr71146.C  -std=gnu++2a (internal compiler error)
g++.dg/ipa/pr71146.C  -std=gnu++98 (internal compiler error)
g++.dg/ipa/pr85421.C   (internal compiler error)
g++.dg/ipa/pr92528.C   (internal compiler error)
g++.dg/lto/pr89330 cp_lto_pr89330_0.o-cp_lto_pr89330_1.o link,
-O3 -g -flto -shared -fPIC -Wno-odr  (internal compiler error)
g++.dg/torture/covariant-1.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
g++.dg/torture/covariant-1.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
g++.dg/torture/pr46287.C   -O2  (internal compiler error)
g++.dg/torture/pr46287.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
g++.dg/torture/pr46287.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
g++.dg/torture/pr46287.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
g++.dg/torture/pr46287.C   -O3 -g  (internal compiler error)
g++.dg/torture/pr78692.C   -O2  (internal compiler error)
g++.dg/torture/pr78692.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
g++.dg/torture/pr78692.C   -O3 -g  (internal compiler error)
g++.dg/torture/pr83619.C   -O2  (internal compiler error)
g++.dg/torture/pr83619.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
g++.dg/torture/pr83619.C   -O3 -g  (internal compiler error)

The backtrace includes:
FAIL: g++.dg/ipa/devirt-7.C  -std=gnu++98 (internal compiler error)
FAIL: g++.dg/ipa/devirt-7.C  -std=gnu++98 (test for excess errors)
Excess errors:
/gcc/testsuite/g++.dg/ipa/devirt-7.C:85:1: internal compiler error: in
release_body, at cgraph.c:1863
0xb98d4f cgraph_node::release_body(bool)
/gcc/cgraph.c:1863
0xba7f3c expand_all_functions
/gcc/cgraphunit.c:1994
0xba7f3c symbol_table::compile()
/gcc/cgraphunit.c:2358
0xbab204 symbol_table::finalize_compilation_unit()
/gcc/cgraphunit.c:2539

Can you check/fix?

Thanks,

Christophe


>
> PR lto/99447
> * cgraph.c (cgraph_node::release_body): Remove all callers and
> references.
> * cgraphclones.c (cgraph_node::materialize_clone): Do not do it here.
> * cgraphunit.c (cgraph_node::expand): And here.
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 80140757d16..b77c676a58a 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -1860,6 +1860,9 @@ cgraph_node::release_body (bool keep_arguments)
>lto_free_function_in_decl_state_for_node (this);
>lto_file_data = NULL;
>  }
> +  gcc_assert (!clones);
> +  remove_callees ();
> +  remove_all_references ();
>  }
>
>  /* Remove function from symbol table.  */
> diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
> index 95103a423f7..9f86463b42d 100644
> --- a/gcc/cgraphclones.c
> +++ b/gcc/cgraphclones.c
> @@ -1143,11 +1143,7 @@ cgraph_node::materialize_clone ()
>/* Function is no longer clone.  */
>remove_from_clone_tree ();
>if (!this_clone_of->analyzed && !this_clone_of->clones)
> -{
> -  this_clone_of->release_body ();
> -  this_clone_of->remove_callees ();
> -  this_clone_of->remove_all_references ();
> -}
> +this_clone_of->release_body ();
>  }
>
>  #include "gt-cgraphclones.h"
> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> index 1c74cee69ac..0b70e4d4fde 100644
> --- a/gcc/cgraphunit.c
> +++ b/gcc/cgraphunit.c
> @@ -1892,10 +1892,6 @@ cgraph_node::expand (void)
>   comdat groups.  */
>assemble_thunks_and_aliases ();
>release_body ();
> -  /* Eliminate all call edges.  This is important so the GIMPLE_CALL no 
> longer
> - points to the dead function body.  */
> -  remove_callees ();
> -  remove_all_references 

doc: Fix up symver attribute documentation

[Jakub Jelinek via Gcc-patches]

Hi!

When looking at the symver documentation, I've noticed a couple of
syntax errors in it.

Committed to trunk as obvious.

But looking more at it, the
r11-2859-g363080bb8bd2cca81dd9e2e774910a8c8226f430
change that introduced this has another problem - the documentation
still talks about foo_v1 but the alias attribute has been removed
from the example.

Maybe it would be better to restore to the old way for symver_foo_v1
with its GCC 10 attributes, describe what that does, then have the
bar example and add baz example with multiple symver attributes
in the same attribute and describe what each of them does and mention
that only binutils 2.35 and later actually handle some of the forms.

2021-04-01  Jakub Jelinek  

* doc/extend.texi (symver attribute): Fix up syntax errors
in the examples.

--- gcc/doc/extend.texi.jj  2021-03-03 09:43:57.898723872 +0100
+++ gcc/doc/extend.texi 2021-04-01 10:56:25.604914998 +0200
@@ -3851,13 +3851,13 @@ output.
 One can also define multiple version for a given symbol.
 
 @smallexample
-__attribute__ ((__symver__ ("foo@@VERS_2"), ("foo@@VERS_3")))
+__attribute__ ((__symver__ ("foo@@VERS_2"), __symver__ ("foo@@VERS_3")))
 int symver_foo_v1 (void)
 @{
 @}
 
-__attribute__ ((__symver__ ("bar@@VERS_2"
-__attribute__ ((__symver__ ("bar@@VERS_3"
+__attribute__ ((__symver__ ("bar@@VERS_2")))
+__attribute__ ((__symver__ ("bar@@VERS_3")))
 int symver_bar_v1 (void)
 @{
 @}

Jakub

Re: Small refactoring of cgraph_node::release_body

[Jan Hubicka]

> This patch is causing ICEs on arm and aarch64, and others according to
> gcc-testresults:
> on aarch64:
> g++.dg/ipa/devirt-7.C  -std=gnu++14 (internal compiler error)
> g++.dg/ipa/devirt-7.C  -std=gnu++17 (internal compiler error)
> g++.dg/ipa/devirt-7.C  -std=gnu++2a (internal compiler error)
> g++.dg/ipa/devirt-7.C  -std=gnu++98 (internal compiler error)
> g++.dg/ipa/pr71146.C  -std=gnu++14 (internal compiler error)
> g++.dg/ipa/pr71146.C  -std=gnu++17 (internal compiler error)
> g++.dg/ipa/pr71146.C  -std=gnu++2a (internal compiler error)
> g++.dg/ipa/pr71146.C  -std=gnu++98 (internal compiler error)
> g++.dg/ipa/pr85421.C   (internal compiler error)
> g++.dg/ipa/pr92528.C   (internal compiler error)
> g++.dg/lto/pr89330 cp_lto_pr89330_0.o-cp_lto_pr89330_1.o link,
> -O3 -g -flto -shared -fPIC -Wno-odr  (internal compiler error)
> g++.dg/torture/covariant-1.C   -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  (internal compiler error)
> g++.dg/torture/covariant-1.C   -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  (internal compiler error)
> g++.dg/torture/pr46287.C   -O2  (internal compiler error)
> g++.dg/torture/pr46287.C   -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  (internal compiler error)
> g++.dg/torture/pr46287.C   -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  (internal compiler error)
> g++.dg/torture/pr46287.C   -O3 -fomit-frame-pointer -funroll-loops
> -fpeel-loops -ftracer -finline-functions  (internal compiler error)
> g++.dg/torture/pr46287.C   -O3 -g  (internal compiler error)
> g++.dg/torture/pr78692.C   -O2  (internal compiler error)
> g++.dg/torture/pr78692.C   -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  (internal compiler error)
> g++.dg/torture/pr78692.C   -O3 -g  (internal compiler error)
> g++.dg/torture/pr83619.C   -O2  (internal compiler error)
> g++.dg/torture/pr83619.C   -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  (internal compiler error)
> g++.dg/torture/pr83619.C   -O3 -g  (internal compiler error)
> 
> The backtrace includes:
> FAIL: g++.dg/ipa/devirt-7.C  -std=gnu++98 (internal compiler error)
> FAIL: g++.dg/ipa/devirt-7.C  -std=gnu++98 (test for excess errors)
> Excess errors:
> /gcc/testsuite/g++.dg/ipa/devirt-7.C:85:1: internal compiler error: in
> release_body, at cgraph.c:1863
> 0xb98d4f cgraph_node::release_body(bool)
> /gcc/cgraph.c:1863
> 0xba7f3c expand_all_functions
> /gcc/cgraphunit.c:1994
> 0xba7f3c symbol_table::compile()
> /gcc/cgraphunit.c:2358
> 0xbab204 symbol_table::finalize_compilation_unit()
> /gcc/cgraphunit.c:2539
> 
> Can you check/fix?

I checked in a fix for most of the yesterday (I added last minute check
that was too restrictive and apparently did not fully re-test by
mistake).  In some setups there is one failure
libgomp.c/declare-variant-1.c remaining that is different, I am looking
into it now and will fix it soon.

Honza

Re: [PATCH] modules : Make sure we include in system.h.

[Nathan Sidwell]

On 3/31/21 4:50 PM, Iain Sandoe wrote:

Hi,

This fixes a stage 1 bootstrap fail on some Darwin versions when the
bootstrap compiler is clang / libc++ from Xcode.

bootstrapped on x86_64-darwin16, x86_64-linux-gnu
OK for master?
thanks
Iain


ok, thanks for tracking this down!


--
Nathan Sidwell

GCC 10.2.1 Status Report (2021-04-01), branch frozen for release

[Richard Biener]

The GCC 10 branch is now frozen in preparation for the GCC 10.3 release
which will see a first release candidate built soon.

All changes from now on require release manager approval.

GCC 10.2.1 Status Report (2021-04-01), branch frozen for release

[Richard Biener]

Status
==

The GCC 10 branch is frozen for the release of GCC 10.3 with
a first release candidate published.  All changes require
release manager approval.


Quality Data


Priority  #   Change from last report
---   ---
P1-   1
P2  326   -  27
P3   25   -   5
P4  179   +   3
P5   23
---   ---
Total P1-P3 350   -  34
Total   552   -  31


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2021-March/235046.html

c++: inter-cluster import order [PR 99283]

[Nathan Sidwell]

I finally managed to reduce the testcase without hitting other bugs. 
This problem is caused by discovering a duplicate in the middle of 
reading in the entity in question.  I had thougt the import seeding at 
the beginning of a cluster prevented that, but it is insufficient. 
Specifically an earlier cluster in the same module can cause the import 
of a duplicate.  Although clusters within a module are well-ordered, 
there is no ordering between clusters of one module and clusters of 
another module.  And thus we can get duplicate declaration loops.  This 
prevents the problem by also seeding references to earlier clusters in 
the same module.  As the FIXME notes, it is sufficient to reference a 
single entity in any particular earlier cluster, plus, we also could 
determine the implicit dependencies and prune that seeding even further. 
 I do not do that -- it decrease the loading that will happen, but 
would reduce the serialization size.  As ever, let's get correctness first.


PR c++/99283
gcc/cp/
* module.cc (trees_out::decl_node): Adjust importedness reference
assert.
(module_state::intercluster_seed): New.  Seed both imports and
inter-cluster references.  Broken out of ...
(module_state::write_cluster): ... here.  Call it.
gcc/testsuite/
* g++.dg/modules/pr99283-6.h: New.
* g++.dg/modules/pr99283-6_a.H: New.
* g++.dg/modules/pr99283-6_b.H: New.
* g++.dg/modules/pr99283-6_c.C: New.
* g++.dg/modules/hdr-init-1_c.C: Adjust scan.
* g++.dg/modules/indirect-3_c.C: Adjust scan.
* g++.dg/modules/indirect-4_c.C: Adjust scan.
* g++.dg/modules/lambda-3_b.C: Adjust scan.
* g++.dg/modules/late-ret-3_c.C: Adjust scan.
* g++.dg/modules/pr99425-1_b.H: Adjust scan.
* g++.dg/modules/pr99425-1_c.C: Adjust scan.

--
Nathan Sidwell
diff --git c/gcc/cp/module.cc w/gcc/cp/module.cc
index fab6b573d24..c87ddd16a80 100644
--- c/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -3570,6 +3570,7 @@ class GTY((chain_next ("%h.parent"), for_user)) module_state {
 			 unsigned, unsigned *crc_ptr);
   bool read_namespaces (unsigned);
 
+  void intercluster_seed (trees_out &sec, unsigned index, depset *dep);
   unsigned write_cluster (elf_out *to, depset *depsets[], unsigned size,
 			  depset::hash &, unsigned *counts, unsigned *crc_ptr);
   bool read_cluster (unsigned snum);
@@ -8548,8 +8549,7 @@ trees_out::decl_node (tree decl, walk_kind ref)
 	gcc_checking_assert (index == ~import_entity_index (decl));
 
 #if CHECKING_P
-  if (importedness)
-	gcc_assert (!import == (importedness < 0));
+  gcc_assert (!import || importedness >= 0);
 #endif
   i (tt_entity);
   u (import);
@@ -14419,7 +14419,33 @@ enum ct_bind_flags
   cbf_wrapped = 0x8,  	/* ... that is wrapped.  */
 };
 
-/* Write the cluster of depsets in SCC[0-SIZE).  */
+/* DEP belongs to a different cluster, seed it to prevent
+   unfortunately timed duplicate import.  */
+// FIXME: QOI For inter-cluster references we could just only pick
+// one entity from an earlier cluster.  Even better track
+// dependencies between earlier clusters
+
+void
+module_state::intercluster_seed (trees_out &sec, unsigned index_hwm, depset *dep)
+{
+  if (dep->is_import ()
+  || dep->cluster < index_hwm)
+{
+  tree ent = dep->get_entity ();
+  if (!TREE_VISITED (ent))
+	{
+	  sec.tree_node (ent);
+	  dump (dumper::CLUSTER)
+	&& dump ("Seeded %s %N",
+		 dep->is_import () ? "import" : "intercluster", ent);
+	}
+}
+}
+
+/* Write the cluster of depsets in SCC[0-SIZE).
+   dep->section -> section number
+   dep->cluster -> entity number
+ */
 
 unsigned
 module_state::write_cluster (elf_out *to, depset *scc[], unsigned size,
@@ -14431,6 +14457,7 @@ module_state::write_cluster (elf_out *to, depset *scc[], unsigned size,
 
   trees_out sec (to, this, table, table.section);
   sec.begin ();
+  unsigned index_lwm = counts[MSC_entities];
 
   /* Determine entity numbers, mark for writing.   */
   dump (dumper::CLUSTER) && dump ("Cluster members:") && (dump.indent (), true);
@@ -14484,10 +14511,10 @@ module_state::write_cluster (elf_out *to, depset *scc[], unsigned size,
 }
   dump (dumper::CLUSTER) && (dump.outdent (), true);
 
-  /* Ensure every imported decl is referenced before we start
- streaming.  This ensures that we never encounter the situation
- where this cluster instantiates some implicit member that
- importing some other decl causes to be instantiated.  */
+  /* Ensure every out-of-cluster decl is referenced before we start
+ streaming.  We must do both imports *and* earlier clusters,
+ because the latter could reach into the former and cause a
+ duplicate loop.   */
   sec.set_importing (+1);
   for (unsigned ix = 0; ix != size; ix++)
 {
@@ -14505,30 +14532,14 @@ module_state::write_cluster (elf_out *to, depset *scc[], unsigned size,
 		  depset *bind = dep->deps[ix];

Re: [PATCH] bswap: Handle bswapping of pointers [PR96573]

[Alex Coplan via Gcc-patches]

Hi Jakub,

On 31/03/2021 21:30, Jakub Jelinek via Gcc-patches wrote:
> Hi!
> 
> In GCC8/9 we used to optimize this into a bswap, but we no longer do.
> Handling byteswapping of pointers is easy, all we need is to allow them,
> for the __builtin_bswap* we already use TYPE_PRECISION to determine
> the precision and we cast the operand and result to the correct type
> if they aren't uselessly convertible to what the builtin expects.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2021-03-31  Jakub Jelinek  
> 
>   PR tree-optimization/96573
>   * gimple-ssa-store-merging.c (init_symbolic_number): Handle
>   also pointer types.
> 
>   * gcc.dg/pr96573.c: New test.

FYI, I'm seeing the new test failing on aarch64:

PASS: gcc.dg/pr96573.c (test for excess errors)
FAIL: gcc.dg/pr96573.c scan-tree-dump optimized "__builtin_bswap"

Thanks,
Alex

> 
> --- gcc/gimple-ssa-store-merging.c.jj 2021-02-22 17:54:05.701798074 +0100
> +++ gcc/gimple-ssa-store-merging.c2021-03-31 11:30:55.519845647 +0200
> @@ -333,7 +333,7 @@ init_symbolic_number (struct symbolic_nu
>  {
>int size;
>  
> -  if (! INTEGRAL_TYPE_P (TREE_TYPE (src)))
> +  if (!INTEGRAL_TYPE_P (TREE_TYPE (src)) && !POINTER_TYPE_P (TREE_TYPE 
> (src)))
>  return false;
>  
>n->base_addr = n->offset = n->alias_set = n->vuse = NULL_TREE;
> --- gcc/testsuite/gcc.dg/pr96573.c.jj 2021-03-31 11:39:19.382122478 +0200
> +++ gcc/testsuite/gcc.dg/pr96573.c2021-03-31 11:39:54.186727148 +0200
> @@ -0,0 +1,20 @@
> +/* PR tree-optimization/96573 */
> +/* { dg-do compile { target { lp64 || ilp32 } } } */
> +/* { dg-require-effective-target bswap } */
> +/* { dg-options "-O3 -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-dump "__builtin_bswap" "optimized" } } */
> +
> +typedef __SIZE_TYPE__ size_t;
> +
> +void *
> +foo (void * const p)
> +{
> +  const size_t m = sizeof (p) - 1;
> +  const unsigned char * const o = (unsigned char*) &p;
> +  void *n;
> +  unsigned char * const q = (unsigned char *) &n;
> +  unsigned char i;
> +  for (i = 0; i <= m; ++i)
> +q[m - i] = o[i];
> +  return n;
> +}
> 
>   Jakub
> 

RFC: Sphinx for GCC documentation

[Martin Liška]

Hey.

I've returned to the David's project and I'm willing to finish his transition 
effort.
I believe using Sphinx documentation can rapidly improve readability, both HTML 
and PDF version,
of various GCC manuals ([1]). I've spent some time working on the David's 
texi2rsf conversion tool ([2])
and I'm presenting a result that is not perfect, but can be acceptable after a 
reasonable
amount of manual modifications.

So far I focused on the 2 biggest manuals we have:

(1) User documentation
https://splichal.eu/sphinx/
https://splichal.eu/sphinx/gcc.pdf

(2) GCC Internals Manual
https://splichal.eu/sphinx-internal
https://splichal.eu/sphinx-internal/gccint.pdf

I'm aware of missing pieces (thanks Joseph) and I'm willing to finish it.

That said, I'm asking the GCC community for a green light before I invest
more time on it?

Cheers,
Martin

[1] https://gcc.gnu.org/onlinedocs/
[2] https://github.com/davidmalcolm/texi2rst

Re: RFC: Sphinx for GCC documentation

[Koning, Paul via Gcc-patches]

Can  it provide EPUB or MOBI output?  Some of the documentation systems used in 
various open source products have that capability, and that is very nice to 
have.  I have seen this from the one used by the Python project, for example.  
Converting other formats to EPUB sometimes works tolerably well, but often not 
-- in particular, PDF to anything else is generally utterly unuseable, which is 
actually a design goal of PDF.

paul

> On Apr 1, 2021, at 9:30 AM, Martin Liška  wrote:
> 
> Hey.
> 
> I've returned to the David's project and I'm willing to finish his transition 
> effort.
> I believe using Sphinx documentation can rapidly improve readability, both 
> HTML and PDF version,
> of various GCC manuals ([1]). I've spent some time working on the David's 
> texi2rsf conversion tool ([2])
> and I'm presenting a result that is not perfect, but can be acceptable after 
> a reasonable
> amount of manual modifications.
> 
> So far I focused on the 2 biggest manuals we have:
> 
> (1) User documentation
> https://splichal.eu/sphinx/
> https://splichal.eu/sphinx/gcc.pdf
> 
> (2) GCC Internals Manual
> https://splichal.eu/sphinx-internal
> https://splichal.eu/sphinx-internal/gccint.pdf
> 
> I'm aware of missing pieces (thanks Joseph) and I'm willing to finish it.
> 
> That said, I'm asking the GCC community for a green light before I invest
> more time on it?
> 
> Cheers,
> Martin
> 
> [1] https://gcc.gnu.org/onlinedocs/
> [2] https://github.com/davidmalcolm/texi2rst

[Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186

[Paul Richard Thomas via Gcc-patches]

This one is trivial. The wrong error message was transformed by my patch
for PR98897 into an ICE. This patch now produces the correct error.

Regtests OK on FC33/x86_64 - OK for the affected branches?

Paul

Fortran: Fix ICE on wrong code [PR99818].

2021-04-01  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/99818
* interface.c (compare_parameter): The codimension attribute is
applied to the _data field of class formal arguments.

gcc/testsuite/ChangeLog

PR fortran/99818
* gfortran.dg/coarray_48.f90: New test.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index f7ca52e6550..60736123550 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2327,6 +2327,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   bool rank_check, is_pointer;
   char err[200];
   gfc_component *ppc;
+  bool codimension = false;
 
   /* If the formal arg has type BT_VOID, it's to one of the iso_c_binding
  procs c_f_pointer or c_f_procpointer, and we need to accept most
@@ -2490,7 +2491,12 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   return false;
 }
 
-  if (formal->attr.codimension && !gfc_is_coarray (actual))
+  if (formal->ts.type == BT_CLASS && formal->attr.class_ok)
+codimension = CLASS_DATA (formal)->attr.codimension;
+  else
+codimension = formal->attr.codimension;
+
+  if (codimension && !gfc_is_coarray (actual))
 {
   if (where)
 	gfc_error ("Actual argument to %qs at %L must be a coarray",
@@ -2498,7 +2504,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   return false;
 }
 
-  if (formal->attr.codimension && formal->attr.allocatable)
+  if (codimension && formal->attr.allocatable)
 {
   gfc_ref *last = NULL;
 
@@ -2520,7 +2526,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
 	}
 }
 
-  if (formal->attr.codimension)
+  if (codimension)
 {
   /* F2008, 12.5.2.8 + Corrig 2 (IR F08/0048).  */
   /* F2018, 12.5.2.8.  */
@@ -2586,7 +2592,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   return false;
 }
 
-  if (formal->attr.allocatable && !formal->attr.codimension
+  if (formal->attr.allocatable && !codimension
   && actual_attr.codimension)
 {
   if (formal->attr.intent == INTENT_OUT)
! { dg-do compile }
! { dg-options "-fcoarray=lib" }
!
! Fix for P99818 in which wrong code caused an ICE.
!
! Contributed by Gerhard Steinmetz 
!
module m
   type t
  integer :: a
   contains
  procedure :: s
   end type
contains
   subroutine s(x)
  class(t) :: x[*]
   end
end
program p
   use m
   associate (y => t(1))
  call y%s   ! { dg-error "must be a coarray" }
   end associate
end

Re: RFC: Sphinx for GCC documentation

[Martin Liška]

On 4/1/21 3:42 PM, Koning, Paul wrote:
> Can  it provide EPUB or MOBI output?

Yes, [1] lists 'epub' as one of the possible "buildername" options.
Btw. what Python project do you speak about?

Cheers,
Martin

[1] 
https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption-sphinx-build-b

Re: RFC: Sphinx for GCC documentation

[Koning, Paul via Gcc-patches]

On Apr 1, 2021, at 9:51 AM, Martin Liška 
mailto:mli...@suse.cz>> wrote:


[EXTERNAL EMAIL]

On 4/1/21 3:42 PM, Koning, Paul wrote:
Can  it provide EPUB or MOBI output?

Yes, [1] lists 'epub' as one of the possible "buildername" options.
Btw. what Python project do you speak about?

Cheers,
Martin

[1] 
https://urldefense.com/v3/__https://www.sphinx-doc.org/en/master/man/sphinx-build.html*cmdoption-sphinx-build-b__;Iw!!LpKI!0_fWcPNFwNBId3ubX-HgUu7gNFW_aV4Esdt-et67FMeHmhLWOiOVEbZZktJiLH8w$
 [sphinx-doc[.]org]

Good to know.  I mean the project that delivers Python 
(python.org).  It delivers documentation in several forms, 
EPUB among them: https://docs.python.org/3/download.html

paul

Re: [PATCH] Complete __gnu_debug::basic_string

[Jonathan Wakely via Gcc-patches]

On 29/03/21 22:25 +0200, François Dumont wrote:

On 25/03/21 4:29 pm, Jonathan Wakely wrote:

Oh, it's the same generate(sz) bug as you already found. But I've
found other bugs, e.g. with GLIBCXX_SEED_TEST_RNG=1908970375).

I think we should also add a check for non-empty containers to those
test functions, and ensure we don't try to erase from empty
containers (see attached).


I had a look at this patch and on my side I was more thinking about 
avoiding empty containers in the first place.


What do you think ?


I did consider this and decided against it for the reasons below.


François




diff --git a/libstdc++-v3/testsuite/util/exception/safety.h 
b/libstdc++-v3/testsuite/util/exception/safety.h
index 54449d2f7bb..6940f2f765d 100644
--- a/libstdc++-v3/testsuite/util/exception/safety.h
+++ b/libstdc++-v3/testsuite/util/exception/safety.h
@@ -55,14 +55,14 @@ namespace __gnu_test

// Return randomly generated integer on range [0, __max_size].
static size_type
-generate(size_type __max_size)
+generate(size_type __max_size, size_type __min_size = 0)
{
  using param_type = typename distribution_type::param_type;

  // Make the engine and distribution static...
  static engine_type engine = get_engine();
  static distribution_type distribution;
-  return distribution(engine, param_type{0, __max_size});
+  return distribution(engine, param_type{__min_size, __max_size});
}

// Given an instantiating type, return a unique value.
@@ -198,7 +198,8 @@ namespace __gnu_test

  // Size test container.
  const size_type max_elements = 100;
- size_type n = generate(max_elements);
+ const size_type min_elements = 10;
+ size_type n = generate(max_elements, min_elements);


Why 10 though? Why not 1? Otherwise we never test the case where you
erase a single element from a container that only has a single
element.

And it would also mean we never test inserting into an empty
container, because it always starts with at least 10 elements.

So I decided that it was better to keep /most/ of the tests unchanged,
so they sometimes (depending on the RNG, which can now be made less
predictable by using a non-default seed) test with empty containers.
Only the operations that really can't work for empty containers need
to care about them. For other operations, we should keep testing the
empty case.

Re: [PATCH 1/3] libstdc++: Fix elements_view::operator* and operator[] [LWG 3502]

[Jonathan Wakely via Gcc-patches]

On 29/03/21 14:49 -0400, Patrick Palka via Libstdc++ wrote:

While we're modifying elements_view, this also implements the one-line
resolution of LWG 3492.

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::__returnable_element): New
concept.
(elements_view): Use this concept in its constraints.  Add
missing private access specifier.
(elements_view::_S_get_element): Define as per LWG 3502.
(elements_view::operator*, elements_view::operator[]): Use
_S_get_element.
(elements_view::operator++): Remove unnecessary constraint
as per LWG 3492.
* testsuite/std/ranges/adaptors/elements.cc (test05): New test.


OK, thanks.

Re: [PATCH 3/3] libstdc++: Fix split_view::_OuterIter::operator++ [LWG 3505]

[Jonathan Wakely via Gcc-patches]

On 29/03/21 14:49 -0400, Patrick Palka via Libstdc++ wrote:

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::find): Define.
(split_view::_OuterIter::operator++): Apply proposed resolution
of LWG 3505.
* testsuite/std/ranges/adaptors/split.cc (test10): New test.


OK, thanks.

Re: [committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]

[Eric Botcazou]

> Oops, and I also forgot to update the other headers that were using
> those autoconf-generated macros!
> 
> Fixed by this patch. Tested on mingw-w64, pushed to trunk.

The original patch was apparently backported onto the gcc-10 branch, but not 
this follow-up fix, so Windows builds are now broken on the branch.

-- 
Eric Botcazou

Re: [PATCH 2/3] libstdc++: Simplify copy-pasted algorithms in

[Jonathan Wakely via Gcc-patches]

On 29/03/21 14:49 -0400, Patrick Palka via Libstdc++ wrote:

The  header currently copies some simple algorithms from
, which was originally done in order to avoid a
circular dependency with the header.  This is no longer an issue since
the latter header now includes  instead of all of
.

This means we could now just include  and remove the
copied algorithms, but that would double the size of .  And we
can't use the corresponding STL-style algorithms here because they
assume input iterators are copyable.  So this patch instead simplifies
these copied algorithms, removing their constraints and unused
parameters, and keeps them around.  In a subsequent patch we're going to
copy ranges::find into  as well.

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::find_if): Simplify.
(__detail::find_if_not): Likewise.
(__detail::min): Remove.
(__detail::mismatch): Simplify.
(take_view::size): Use std::min instead of __detail::min.


I wonder if we want a  which has this subset
of algos. That could be used from  and also from the real
algos in . The ones in ranges_algobase.h wouldn't
need to have the constraints (because we know the caller is
constrained, or uses them correctly), but for that to work the unused
params would need to be re-added. We can consider that for GCC 12
though.

So OK for GCC 11.

Re: RFC: Sphinx for GCC documentation

[Marek Polacek via Gcc-patches]

On Thu, Apr 01, 2021 at 03:30:10PM +0200, Martin Liška wrote:
> Hey.
> 
> I've returned to the David's project and I'm willing to finish his transition 
> effort.
> I believe using Sphinx documentation can rapidly improve readability, both 
> HTML and PDF version,
> of various GCC manuals ([1]). I've spent some time working on the David's 
> texi2rsf conversion tool ([2])
> and I'm presenting a result that is not perfect, but can be acceptable after 
> a reasonable
> amount of manual modifications.
> 
> So far I focused on the 2 biggest manuals we have:
> 
> (1) User documentation
> https://splichal.eu/sphinx/
> https://splichal.eu/sphinx/gcc.pdf
> 
> (2) GCC Internals Manual
> https://splichal.eu/sphinx-internal
> https://splichal.eu/sphinx-internal/gccint.pdf
> 
> I'm aware of missing pieces (thanks Joseph) and I'm willing to finish it.
> 
> That said, I'm asking the GCC community for a green light before I invest
> more time on it?

I really like it, so +1 from my side.  (The web page more than the pdf.)

Marek

Re: [committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]

[Jonathan Wakely via Gcc-patches]

On 01/04/21 16:04 +0200, Eric Botcazou wrote:

Oops, and I also forgot to update the other headers that were using
those autoconf-generated macros!

Fixed by this patch. Tested on mingw-w64, pushed to trunk.


The original patch was apparently backported onto the gcc-10 branch, but not
this follow-up fix, so Windows builds are now broken on the branch.


Sorry. I did try to test a mingw-w64 cross, but I think I probably
tested it against trunk not the branch. So didn't test it at all.

It should be fixed by the attached patch for gcc-10. I'm testing it
now on linux and mingw.

I'll wait for RM approval before pushing.



commit 03a430a55093d2ea5b80db3273c3a7134367272a
Author: Jonathan Wakely 
Date:   Thu Dec 17 13:27:04 2020 +

libstdc++: Test errno macros directly for all targets [PR 93151]

This applies the same changes to the djgpp and mingw versions of
error_constants.h as r11-6137 did for the generic version.

All of these constants are defined as macros by  on these
targets, so we can just test the macro directly instead of checking for
it at configure time.

libstdc++-v3/ChangeLog:

* config.h.in: Regenerate.
* config/os/djgpp/error_constants.h: Test POSIX errno macros
directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
* config/os/mingw32-w64/error_constants.h: Likewise.
* config/os/mingw32/error_constants.h: Likewise.
* configure: Regenerate.

(cherry picked from commit 217d5beaff9987a9845155fc796322b5f8bb876d)

diff --git a/libstdc++-v3/config/os/djgpp/error_constants.h b/libstdc++-v3/config/os/djgpp/error_constants.h
index e0a67bc8d6d..8f947e69e37 100644
--- a/libstdc++-v3/config/os/djgpp/error_constants.h
+++ b/libstdc++-v3/config/os/djgpp/error_constants.h
@@ -48,7 +48,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   bad_address = EFAULT,
   bad_file_descriptor = 			EBADF,
 
-#ifdef _GLIBCXX_HAVE_EBADMSG
+#ifdef EBADMSG
   bad_message = EBADMSG,
 #endif
 
@@ -68,7 +68,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   function_not_supported = 			ENOSYS,
 //host_unreachable = 			EHOSTUNREACH,
 
-#ifdef _GLIBCXX_HAVE_EIDRM
+#ifdef EIDRM
   identifier_removed = 			EIDRM,
 #endif
 
@@ -86,13 +86,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 //no_buffer_space = 			ENOBUFS,
   no_child_process = 			ECHILD,
 
-#ifdef _GLIBCXX_HAVE_ENOLINK
+#ifdef ENOLINK
   no_link = ENOLINK,
 #endif
 
   no_lock_available = 			ENOLCK,
 
-#ifdef _GLIBCXX_HAVE_ENODATA
+#ifdef ENODATA
   no_message_available = 			ENODATA,
 #endif
 
@@ -100,7 +100,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 //no_protocol_option = 			ENOPROTOOPT,
   no_space_on_device = 			ENOSPC,
 
-#ifdef _GLIBCXX_HAVE_ENOSR
+#ifdef ENOSR
   no_stream_resources = 			ENOSR,
 #endif
 
@@ -111,18 +111,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   not_a_directory = 			ENOTDIR,
 //not_a_socket = ENOTSOCK,
 
-#ifdef _GLIBCXX_HAVE_ENOSTR
+#ifdef ENOSTR
   not_a_stream = ENOSTR,
 #endif
 
 //not_connected = ENOTCONN,
   not_enough_memory = 			ENOMEM,
 
-#ifdef _GLIBCXX_HAVE_ENOTSUP
+#ifdef ENOTSUP
   not_supported = ENOTSUP,
 #endif
 
-#ifdef _GLIBCXX_HAVE_ECANCELED
+#ifdef ECANCELED
   operation_canceled = 			ECANCELED,
 #endif
 
@@ -131,13 +131,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 //operation_not_supported = 		EOPNOTSUPP,
 //operation_would_block = 			EWOULDBLOCK,
 
-#ifdef _GLIBCXX_HAVE_EOWNERDEAD
+#ifdef EOWNERDEAD
   owner_dead = EOWNERDEAD,
 #endif
 
   permission_denied = 			EACCES,
 
-#ifdef _GLIBCXX_HAVE_EPROTO
+#ifdef EPROTO
   protocol_error = EPROTO,
 #endif
 
@@ -147,15 +147,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   resource_unavailable_try_again = 		EAGAIN,
   result_out_of_range = 			ERANGE,
 
-#ifdef _GLIBCXX_HAVE_ENOTRECOVERABLE
+#ifdef ENOTRECOVERABLE
   state_not_recoverable = 			ENOTRECOVERABLE,
 #endif
 
-#ifdef _GLIBCXX_HAVE_ETIME
+#ifdef ETIME
   stream_timeout = ETIME,
 #endif
 
-#ifdef _GLIBCXX_HAVE_ETXTBSY
+#ifdef ETXTBSY
   text_file_busy = ETXTBSY,
 #endif
 
@@ -165,7 +165,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   too_many_links = EMLINK,
   too_many_symbolic_link_levels = 		ELOOP,
 
-#ifdef _GLIBCXX_HAVE_EOVERFLOW
+#ifdef EOVERFLOW
   value_too_large = 			EOVERFLOW,
 #endif
 
diff --git a/libstdc++-v3/config/os/mingw32-w64/error_constants.h b/libstdc++-v3/config/os/mingw32-w64/error_constants.h
index 72422299def..3534c3e11b7 100644
--- a/libstdc++-v3/config/os/mingw32-w64/error_constants.h
+++ b/libstdc++-v3/config/os/mingw32-w64/error_constants.h
@@ -49,7 +49,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   argument_out_of_domain = 			EDOM,
   bad_address = EFAULT,
   bad_file_descriptor = 			EBADF,
-#ifdef _GLIBCXX_HAVE_EBADMSG
+#ifdef EBADMSG
   bad_message = EBADMSG,
 #endif
   broken_pipe = EPIPE,
@@ -67,7 +67,7 @@ _

Re: [committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 01, 2021 at 03:25:56PM +0100, Jonathan Wakely via Gcc-patches wrote:
> On 01/04/21 16:04 +0200, Eric Botcazou wrote:
> > > Oops, and I also forgot to update the other headers that were using
> > > those autoconf-generated macros!
> > > 
> > > Fixed by this patch. Tested on mingw-w64, pushed to trunk.
> > 
> > The original patch was apparently backported onto the gcc-10 branch, but not
> > this follow-up fix, so Windows builds are now broken on the branch.
> 
> Sorry. I did try to test a mingw-w64 cross, but I think I probably
> tested it against trunk not the branch. So didn't test it at all.
> 
> It should be fixed by the attached patch for gcc-10. I'm testing it
> now on linux and mingw.
> 
> I'll wait for RM approval before pushing.

Ok for 10.3, thanks.

> commit 03a430a55093d2ea5b80db3273c3a7134367272a
> Author: Jonathan Wakely 
> Date:   Thu Dec 17 13:27:04 2020 +
> 
> libstdc++: Test errno macros directly for all targets [PR 93151]
> 
> This applies the same changes to the djgpp and mingw versions of
> error_constants.h as r11-6137 did for the generic version.
> 
> All of these constants are defined as macros by  on these
> targets, so we can just test the macro directly instead of checking for
> it at configure time.
> 
> libstdc++-v3/ChangeLog:
> 
> * config.h.in: Regenerate.
> * config/os/djgpp/error_constants.h: Test POSIX errno macros
> directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
> * config/os/mingw32-w64/error_constants.h: Likewise.
> * config/os/mingw32/error_constants.h: Likewise.
> * configure: Regenerate.
> 
> (cherry picked from commit 217d5beaff9987a9845155fc796322b5f8bb876d)
> 
> diff --git a/libstdc++-v3/config/os/djgpp/error_constants.h 
> b/libstdc++-v3/config/os/djgpp/error_constants.h
> index e0a67bc8d6d..8f947e69e37 100644
> --- a/libstdc++-v3/config/os/djgpp/error_constants.h
> +++ b/libstdc++-v3/config/os/djgpp/error_constants.h
> @@ -48,7 +48,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>bad_address =  EFAULT,
>bad_file_descriptor =  EBADF,
>  
> -#ifdef _GLIBCXX_HAVE_EBADMSG
> +#ifdef EBADMSG
>bad_message =  EBADMSG,
>  #endif
>  
> @@ -68,7 +68,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>function_not_supported =   ENOSYS,
>  //host_unreachable = EHOSTUNREACH,
>  
> -#ifdef _GLIBCXX_HAVE_EIDRM
> +#ifdef EIDRM
>identifier_removed =   EIDRM,
>  #endif
>  
> @@ -86,13 +86,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  //no_buffer_space =  ENOBUFS,
>no_child_process = ECHILD,
>  
> -#ifdef _GLIBCXX_HAVE_ENOLINK
> +#ifdef ENOLINK
>no_link =  ENOLINK,
>  #endif
>  
>no_lock_available =ENOLCK,
>  
> -#ifdef _GLIBCXX_HAVE_ENODATA
> +#ifdef ENODATA
>no_message_available = ENODATA,
>  #endif
>  
> @@ -100,7 +100,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  //no_protocol_option =   ENOPROTOOPT,
>no_space_on_device =   ENOSPC,
>  
> -#ifdef _GLIBCXX_HAVE_ENOSR
> +#ifdef ENOSR
>no_stream_resources =  ENOSR,
>  #endif
>  
> @@ -111,18 +111,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>not_a_directory =  ENOTDIR,
>  //not_a_socket = ENOTSOCK,
>  
> -#ifdef _GLIBCXX_HAVE_ENOSTR
> +#ifdef ENOSTR
>not_a_stream = ENOSTR,
>  #endif
>  
>  //not_connected =ENOTCONN,
>not_enough_memory =ENOMEM,
>  
> -#ifdef _GLIBCXX_HAVE_ENOTSUP
> +#ifdef ENOTSUP
>not_supported =ENOTSUP,
>  #endif
>  
> -#ifdef _GLIBCXX_HAVE_ECANCELED
> +#ifdef ECANCELED
>operation_canceled =   ECANCELED,
>  #endif
>  
> @@ -131,13 +131,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  //operation_not_supported =  EOPNOTSUPP,
>  //operation_would_block =EWOULDBLOCK,
>  
> -#ifdef _GLIBCXX_HAVE_EOWNERDEAD
> +#ifdef EOWNERDEAD
>owner_dead =   EOWNERDEAD,
>  #endif
>  
>permission_denied =EACCES,
>  
> -#ifdef _GLIBCXX_HAVE_EPROTO
> +#ifdef EPROTO
>protocol_error =   EPROTO,
>  #endif
>  
> @@ -147,15 +147,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>resource_unavailable_try_again =   EAGAIN,
>result_out_of_range =  ERANGE,
>  
> -#ifdef _GLIBCXX_HAVE_ENOTRECOVERABLE
> +#ifdef ENOTRECOVERABLE
>state_not_recoverable =ENOTRECOVERABLE,
>  #endif
>  
> -#ifdef _GLIBCXX_HAVE_ETIME
> +#ifdef ETIME
>strea

[PATCH] c++: Refine check for CTAD placeholder [PR99586]

[Patrick Palka via Gcc-patches]

In the below testcase, during finish_compound_literal for A{},
type_uses_auto finds and returns the CTAD placeholder for B{V}, which
tricks us into attempting CTAD on A{} and leads to bogus errors.

AFAICT 'type' will always be a bare 'auto' in the CTAD case, so we don't
need to look deeply to find it; checking template_placeholder_p instead
should suffice here.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also on cmcstl2
and range-v3.  Does this look OK for trunk, or perhaps stage1?

gcc/cp/ChangeLog:

PR c++/99586
* semantics.c (finish_compound_literal): Check
template_placeholder_p instead of type_uses_auto.

gcc/testsuite/ChangeLog:

PR c++/99586
* g++.dg/cpp2a/nontype-class42.C: New test.
---
 gcc/cp/semantics.c   | 15 +++
 gcc/testsuite/g++.dg/cpp2a/nontype-class42.C |  8 
 2 files changed, 15 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class42.C

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index b02596f73bd..8eaaaefe2d6 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3036,14 +3036,13 @@ finish_compound_literal (tree type, tree 
compound_literal,
   return error_mark_node;
 }
 
-  if (tree anode = type_uses_auto (type))
-if (CLASS_PLACEHOLDER_TEMPLATE (anode))
-  {
-   type = do_auto_deduction (type, compound_literal, anode, complain,
- adc_variable_type);
-   if (type == error_mark_node)
- return error_mark_node;
-  }
+  if (template_placeholder_p (type))
+{
+  type = do_auto_deduction (type, compound_literal, type, complain,
+   adc_variable_type);
+  if (type == error_mark_node)
+   return error_mark_node;
+}
 
   /* Used to hold a copy of the compound literal in a template.  */
   tree orig_cl = NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C
new file mode 100644
index 000..a688bee6f3d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C
@@ -0,0 +1,8 @@
+// PR c++/99586
+// { dg-do compile { target c++20 } }
+
+template 
+struct B { constexpr B(T) { } };
+
+template  struct A{};
+template  auto a = A{};
-- 
2.31.1.133.g84d06cdc06

Re: RFC: Sphinx for GCC documentation

[David Malcolm via Gcc-patches]

On Thu, 2021-04-01 at 15:30 +0200, Martin Liška wrote:
> Hey.
> 
> I've returned to the David's project and I'm willing to finish his
> transition effort.

For reference, the original thread about this is in the archives here:
  https://gcc.gnu.org/pipermail/gcc-patches/2015-November/434055.html

> I believe using Sphinx documentation can rapidly improve readability,
> both HTML and PDF version,
> of various GCC manuals ([1]).

Specifically, some of the benefits over the status quo are:
- internal hyperlinks in both HTML and PDF output for things like
options (see how every reference to e.g. -Wall and -O2 becomes a link
to those options, and they themselves have links to the things they
encompass)
- sane, stable URLs for anchors
- syntax highlighting of code snippets (and the format lets us express
what language the code snippets are in)
- a page splitting structure that makes sense (IMHO)
- appropriate use of well-designed CSS

The sphinx toolchain is used successfully by numerous projects (e.g.
Python, the Linux kernel, and LLVM).

>  I've spent some time working on the David's texi2rsf conversion tool
> ([2])
> and I'm presenting a result that is not perfect, but can be
> acceptable after a reasonable
> amount of manual modifications.

I think some further tweaking of the conversion script is needed first;
I'd rather iron out the script rather than play whack-a-mole manually.
I enjoy proofreading conversions, but I'm trying to focus right now on
analyzer bugfixing for GCC 11.

> So far I focused on the 2 biggest manuals we have:
> 
> (1) User documentation
> https://splichal.eu/sphinx/
> https://splichal.eu/sphinx/gcc.pdf
> 
> (2) GCC Internals Manual
> https://splichal.eu/sphinx-internal
> https://splichal.eu/sphinx-internal/gccint.pdf
> 
> I'm aware of missing pieces (thanks Joseph) and I'm willing to finish
> it.

One important requirement is manpage output.  Sphinx can do that - what
does the output look like based on the texi2rst output?

> That said, I'm asking the GCC community for a green light before I
> invest
> more time on it?

+1 from me, but you probably guessed that :)

Dave

> Cheers,
> Martin
> 
> [1] https://gcc.gnu.org/onlinedocs/
> [2] https://github.com/davidmalcolm/texi2rst
> 

Re: RFC: Sphinx for GCC documentation

[Koning, Paul via Gcc-patches]

> On Apr 1, 2021, at 9:30 AM, Martin Liška  wrote:
> 
> Hey.
> 
> I've returned to the David's project and I'm willing to finish his transition 
> effort.
> I believe using Sphinx documentation can rapidly improve readability, both 
> HTML and PDF version,
> of various GCC manuals ([1]). I've spent some time working on the David's 
> texi2rsf conversion tool ([2])
> and I'm presenting a result that is not perfect, but can be acceptable after 
> a reasonable
> amount of manual modifications.
> ...
> That said, I'm asking the GCC community for a green light before I invest
> more time on it?

Looks VERY good to me.  Given what I've seen about Sphinx (now that I've 
refreshed my memory) this would be a major improvement.

paul

Re: Small refactoring of cgraph_node::release_body

[David Edelsohn via Gcc-patches]

On Thu, Apr 1, 2021 at 12:45 AM Martin Liška  wrote:
>
> On 3/31/21 8:45 PM, David Edelsohn via Gcc-patches wrote:
> > This patch is causing new crashes in the testsuite.
> >
> > ICE in release_body, at graph.c:1863
> > ranges offset out of range
>
> Hello.
>
> Should be fixed with 23ce9945d5efa77c96161443f68e03664705ada3.

Yes, thanks fixed.  I bootstrapped during the window.

Thanks, David

Re: [committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]

[Jonathan Wakely via Gcc-patches]

On 01/04/21 16:27 +0200, Jakub Jelinek via Libstdc++ wrote:

On Thu, Apr 01, 2021 at 03:25:56PM +0100, Jonathan Wakely via Gcc-patches wrote:

On 01/04/21 16:04 +0200, Eric Botcazou wrote:
> > Oops, and I also forgot to update the other headers that were using
> > those autoconf-generated macros!
> >
> > Fixed by this patch. Tested on mingw-w64, pushed to trunk.
>
> The original patch was apparently backported onto the gcc-10 branch, but not
> this follow-up fix, so Windows builds are now broken on the branch.

Sorry. I did try to test a mingw-w64 cross, but I think I probably
tested it against trunk not the branch. So didn't test it at all.

It should be fixed by the attached patch for gcc-10. I'm testing it
now on linux and mingw.

I'll wait for RM approval before pushing.


Ok for 10.3, thanks.


Thanks, pushed.

I was unable to reproduce the problem on the gcc-10 branch or with the
gcc-10.3.0-RC-20210401.tar.xz release candidate. That's because I
didn't backport r11-6226-gf5feee6adc8350a292c235eb21e31a5082350d94
either. The follow-up fix referred to above was only needed because
r11-6226 regenerated libstdc++-v3/configure and libstdc++-v3/config.h.in. But 
because I didn't backport that (or the follow-up fix) to gcc-10, it still 
checks for the errno macros during configure, and so the HAVE_EXXX macros that 
the Windows headers need should be defined.

Eric, are you building the RC with --enable-maintainer-mode maybe? Or
regenerating the autoconf files yourself?

[PATCH] arm: Fix PCS for SFmode -> SImode libcalls [PR99748]

[Alex Coplan via Gcc-patches]

Hi all,

This patch fixes PR99748 which shows us trying to pass the argument to
__aeabi_f2iz in the VFP register s0 when the library function is
expecting to use the GPR r0. It also fixes the __aeabi_f2uiz case which
was broken in the same way.

For the testcase in the PR, here is the code we generate before the
patch (with -mfloat-abi=hard -march=armv8.1-m.main+mve -O0):

main:
push{r7, lr}
sub sp, sp, #8
add r7, sp, #0
mov r3, #1065353216
str r3, [r7, #4]@ float
vldr.32 s0, [r7, #4]
bl  __aeabi_f2iz
mov r3, r0
cmp r3, #1
[...]

This becomes:

main:
push{r7, lr}
sub sp, sp, #8
add r7, sp, #0
mov r3, #1065353216
str r3, [r7, #4]@ float
ldr r0, [r7, #4]@ float
bl  __aeabi_f2iz
mov r3, r0
cmp r3, #1
[...]

after the patch. We see a similar change for the same testcase with a
cast to unsigned instead of int.

Testing:
 * Bootstrapped and regtested on arm-linux-gnueabihf, no regressions.
 * Regtested an arm-eabi cross configured with --with-float=hard
   --with-arch=armv8.1-m.main+mve. This shows that the patch fixes the
   following execution failures:

   FAIL->PASS: gcc.c-torture/execute/2605-1.c   -O0  execution test
   FAIL->PASS: gcc.c-torture/execute/conversion.c   -O0  execution test
   FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O0  execution test
   FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O1  execution test
   FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O2  execution test
   FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
   FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O3 -g  execution test
   FAIL->PASS: gcc.c-torture/execute/float-floor.c   -Os  execution test
   FAIL->PASS: gcc.c-torture/execute/gofast.c   -O0  execution test
   FAIL->PASS: gcc.dg/torture/float32-basic.c   -O0  execution test
   FAIL->PASS: gcc.dg/torture/float32-basic.c   -O1  execution test
   FAIL->PASS: gcc.dg/torture/float32-basic.c   -O2  execution test
   FAIL->PASS: gcc.dg/torture/float32-basic.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
   FAIL->PASS: gcc.dg/torture/float32-basic.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
   FAIL->PASS: gcc.dg/torture/float32-basic.c   -O3 -g  execution test
   FAIL->PASS: gcc.dg/torture/float32-basic.c   -Os  execution test

OK for trunk?

Thanks,
Alex

gcc/ChangeLog:

* config/arm/arm.c (arm_libcall_uses_aapcs_base): Also use base
PCS for [su]fix_optab.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 518bfed1c35..8910dad8214 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -5773,6 +5773,10 @@ arm_libcall_uses_aapcs_base (const_rtx libcall)
   convert_optab_libfunc (sfix_optab, DImode, SFmode));
   add_libcall (libcall_htab,
   convert_optab_libfunc (ufix_optab, DImode, SFmode));
+  add_libcall (libcall_htab,
+  convert_optab_libfunc (sfix_optab, SImode, SFmode));
+  add_libcall (libcall_htab,
+  convert_optab_libfunc (ufix_optab, SImode, SFmode));
 
   /* Values from double-precision helper functions are returned in core
 registers if the selected core only supports single-precision

Re: [PATCH V5 0/6] Support for the CTF and BTF debug formats

[Jose E. Marchesi via Gcc-patches]

ping

> [Changes from V4:
> - Rebased to latest master.
> - Support for DATASEC in BTF.
> - Bug fixes in the CTF support.
> - Be more silent: do not inform() the user anymore if -gctf is used
>   along with a frontend for which there is no CTF support.  Ignore
>   the request instead.
> - Got rid of lang_GNU_GIMPLE, which is not needed.
> - New preparatory patch that abstracts the tests on write_symbols
>   in a predicate.
> - New preparatory patch that provides an internal interface to the
>   DWARF internal structures.  This makes it possible to not have to
>   #include dwarf2ctf.c in dwarf2out.c.  Note that we only added the
>   minimum set of functions/data types we need for dwarf2ctf.  Note
>   also that we didn't add prefixes to avoid massive renames in
>   dwarf2out.c.  We also add a few new accessor functions.  See the
>   particular patch description.
> - Fixes to allow using -gctf along with -gdwarf.
> - More testing:
>   + More BTF tests.
>   + More CTF tests.
>   + Tests for mixing -gctf and -gdwarf.
>   + Regression tests in x86_64 and aarch64.
>   + LTO testing.
>   + 1612 Gentoo packages built with CTF support, no failures.]
>
> Hi people!
>
> Last year we submitted a first patch series introducing support for
> the CTF debugging format in GCC [1].  We got a lot of feedback that
> prompted us to change the approach used to generate the debug info,
> and this patch series is the result of that.
>
> This series also add support for the BTF debug format, which is needed
> by the BPF backend (more on this below.)
>
> This implementation works, but there are several points that need
> discussion and agreement with the upstream community, as they impact
> the way debugging options work.  We are also proposing a way to add
> additional debugging formats in the future.  See below for more
> details.
>
> Finally, a patch makes the BPF GCC backend to use the DWARF debug
> hooks in order to make -gbtf available to it.
>
> [1] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-05/msg01297.html
>
> About CTF
> =
>
> CTF is a debugging format designed in order to express C types in a
> very compact way.  The key is compactness and simplicity.  For more
> information see:
>
> - CTF specification
>   http://www.esperi.org.uk/~oranix/ctf/ctf-spec.pdf
>
> - Compact C-Type support in the GNU toolchain (talk + slides)
>   https://linuxplumbersconf.org/event/4/contributions/396/
>
> - On type de-duplication in CTF (talk + slides)
>   https://linuxplumbersconf.org/event/7/contributions/725/
>
> About BTF
> =
>
> BTF is a debugging format, similar to CTF, that is used in the Linux
> kernel as the debugging format for BPF programs.  From the kernel
> documentation:
>
> "BTF (BPF Type Format) is the metadata format which encodes the debug
>  info related to BPF program/map. The name BTF was used initially to
>  describe data types. The BTF was later extended to include function
>  info for defined subroutines, and line info for source/line
>  information."
>
> Supporting BTF in GCC is important because compiled BPF programs
> (which GCC supports as a target) require the type information in order
> to be loaded and run in diverse kernel versions.  This mechanism is
> known as CO-RE (compile-once, run-everywhere) and is described in the
> "Update of the BPF support in the GNU Toolchain" talk mentioned below.
>
> The BTF is documented in the Linux kernel documentation tree:
> - linux/Documentation/bpf/btf.rst
>
> CTF in the GNU Toolchain
> 
>
> During the last year we have been working in adding support for CTF to
> several components of the GNU toolchain:
>
> - binutils support is already upstream.  It supports linking objects
>   with CTF information with full type de-duplication.
>
> - GDB support is to be sent upstream very shortly.  It makes the
>   debugger capable to use the CTF information whenever available.
>   This is useful in cases where DWARF has been stripped out but CTF is
>   kept.
>
> - GCC support is being discussed and submitted in this series.
>
> Overview of the Implementation
> ==
>
>   dwarf2out.c
>
> The enabled debug formats are hooked in dwarf2out_early_finish.
>
>   dwarf2int.h
>
> Internal interface that exports a few functions and data types
> defined in dwarf2out.c.
>
>   dwarf2ctf.c
>
> Code that tranform the internal GCC DWARF DIEs into CTF container
> structures.  This file uses the dwarf2int.h interface.
>
>   ctfc.c
>   ctfc.h
>
> These two files implement the "CTF container", which is shared
> among CTF and BTF, due to the many similarities between both
> formats.
>
>   ctfout.c
>
> Code that emits assembler with the .ctf section data, from the CTF
> container.
>
>   btfout.c
>
> Code that emits assembler with the .BTF section data, from the CTF
> container.
>
> From debug hooks to debug formats
> =
>
> Our first attempt in adding CTF to G

Re: [committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]

[Eric Botcazou]

> Thanks, pushed.

I can confirm that the build failure we had is now gone, thanks!

> Eric, are you building the RC with --enable-maintainer-mode maybe? Or
> regenerating the autoconf files yourself?

The latter, we have local configure changes so we regenerate the script.

-- 
Eric Botcazou

[PATCH] x86: Don't generate uiret with -mcmodel=kernel

[H.J. Lu via Gcc-patches]

Since uiret should be used only for user interrupt handler return, don't
generate uiret in interrupt handler return with -mcmodel=kernel even if
UINTR is enabled.

gcc/

PR target/99870
* config/i386/i386.md (interrupt_return): Don't generate uiret
for -mcmodel=kernel.

gcc/testsuite/

* gcc.target/i386/pr99870.c: New test.
---
 gcc/config/i386/i386.md |  3 ++-
 gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 9ff35d9a607..1055b4187b2 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
(unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
   "reload_completed"
 {
-  return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
+  return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
+? "uiret" : "iretq") : "iret";
 })
 
 ;; Used by x86_machine_dependent_reorg to avoid penalty on single byte RET
diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c 
b/gcc/testsuite/gcc.target/i386/pr99870.c
new file mode 100644
index 000..0dafa001ba9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr99870.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
+/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } } */
+
+void
+__attribute__((interrupt))
+fn (void *frame)
+{
+}
+
+typedef void (*fn_t) (void *) __attribute__((interrupt));
+
+fn_t fns[] =
+{
+  fn,
+};
+
+/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } } */
+/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 } } } } */
-- 
2.30.2

Re: [PATCH] c++: Refine check for CTAD placeholder [PR99586]

[Jason Merrill via Gcc-patches]

On 4/1/21 10:30 AM, Patrick Palka wrote:

In the below testcase, during finish_compound_literal for A{},
type_uses_auto finds and returns the CTAD placeholder for B{V}, which
tricks us into attempting CTAD on A{} and leads to bogus errors.

AFAICT 'type' will always be a bare 'auto' in the CTAD case, so we don't
need to look deeply to find it; checking template_placeholder_p instead
should suffice here.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also on cmcstl2
and range-v3.  Does this look OK for trunk, or perhaps stage1?


OK for trunk.


gcc/cp/ChangeLog:

PR c++/99586
* semantics.c (finish_compound_literal): Check
template_placeholder_p instead of type_uses_auto.

gcc/testsuite/ChangeLog:

PR c++/99586
* g++.dg/cpp2a/nontype-class42.C: New test.
---
  gcc/cp/semantics.c   | 15 +++
  gcc/testsuite/g++.dg/cpp2a/nontype-class42.C |  8 
  2 files changed, 15 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class42.C

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index b02596f73bd..8eaaaefe2d6 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3036,14 +3036,13 @@ finish_compound_literal (tree type, tree 
compound_literal,
return error_mark_node;
  }
  
-  if (tree anode = type_uses_auto (type))

-if (CLASS_PLACEHOLDER_TEMPLATE (anode))
-  {
-   type = do_auto_deduction (type, compound_literal, anode, complain,
- adc_variable_type);
-   if (type == error_mark_node)
- return error_mark_node;
-  }
+  if (template_placeholder_p (type))
+{
+  type = do_auto_deduction (type, compound_literal, type, complain,
+   adc_variable_type);
+  if (type == error_mark_node)
+   return error_mark_node;
+}
  
/* Used to hold a copy of the compound literal in a template.  */

tree orig_cl = NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C 
b/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C
new file mode 100644
index 000..a688bee6f3d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C
@@ -0,0 +1,8 @@
+// PR c++/99586
+// { dg-do compile { target c++20 } }
+
+template 
+struct B { constexpr B(T) { } };
+
+template  struct A{};
+template  auto a = A{};

Re: [PATCH] arm: Fix PCS for SFmode -> SImode libcalls [PR99748]

[Richard Earnshaw via Gcc-patches]

On 01/04/2021 17:11, Alex Coplan via Gcc-patches wrote:

Hi all,

This patch fixes PR99748 which shows us trying to pass the argument to
__aeabi_f2iz in the VFP register s0 when the library function is
expecting to use the GPR r0. It also fixes the __aeabi_f2uiz case which
was broken in the same way.

For the testcase in the PR, here is the code we generate before the
patch (with -mfloat-abi=hard -march=armv8.1-m.main+mve -O0):

main:
 push{r7, lr}
 sub sp, sp, #8
 add r7, sp, #0
 mov r3, #1065353216
 str r3, [r7, #4]@ float
 vldr.32 s0, [r7, #4]
 bl  __aeabi_f2iz
 mov r3, r0
 cmp r3, #1
 [...]

This becomes:

main:
 push{r7, lr}
 sub sp, sp, #8
 add r7, sp, #0
 mov r3, #1065353216
 str r3, [r7, #4]@ float
 ldr r0, [r7, #4]@ float
 bl  __aeabi_f2iz
 mov r3, r0
 cmp r3, #1
 [...]

after the patch. We see a similar change for the same testcase with a
cast to unsigned instead of int.

Testing:
  * Bootstrapped and regtested on arm-linux-gnueabihf, no regressions.
  * Regtested an arm-eabi cross configured with --with-float=hard
--with-arch=armv8.1-m.main+mve. This shows that the patch fixes the
following execution failures:

FAIL->PASS: gcc.c-torture/execute/2605-1.c   -O0  execution test
FAIL->PASS: gcc.c-torture/execute/conversion.c   -O0  execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O0  execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O1  execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O2  execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c   -O3 -g  execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c   -Os  execution test
FAIL->PASS: gcc.c-torture/execute/gofast.c   -O0  execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c   -O0  execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c   -O1  execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c   -O2  execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c   -O3 -g  execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c   -Os  execution test

OK for trunk?

Thanks,
Alex

gcc/ChangeLog:

* config/arm/arm.c (arm_libcall_uses_aapcs_base): Also use base
PCS for [su]fix_optab.



OK.

As a wrong code bug we should probably be looking to backport this if 
needed (though it's likely too late now for 10.3).


R.

Re: [committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]

[Jonathan Wakely via Gcc-patches]

On 01/04/21 18:47 +0200, Eric Botcazou wrote:

Thanks, pushed.


I can confirm that the build failure we had is now gone, thanks!


Eric, are you building the RC with --enable-maintainer-mode maybe? Or
regenerating the autoconf files yourself?


The latter, we have local configure changes so we regenerate the script.


Aha, that explains it then. And it's useful that you noticed this
before the final release!

[PATCH] c++: GC collects live data when synthesizing operator== [PR99831]

[Marek Polacek via Gcc-patches]

Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:

  if (kind == sfk_comparison)
{
  /* If the function was declared constexpr, check that the definition
 qualifies.  Otherwise we can define the function lazily.  */
  if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
synthesize_method (fn);
  return;
}

which in this test triggers when we're processing the string<"a">{} in
the static_assert.  First, we create a CONSTRUCTOR for the "{}" in
cp_parser_functional_cast, then we call finish_compound_literal which
calls complete_type and that results in garbage collection, which then
frees the CONSTRUCTOR {} we created when parsing the braced-list in
string<"a">{} -- at this point, it's not referenced by anything.
(That's not the case for 'type' in finish_compound_literal: the symbol
table contains a node for operator==, so ggc_mark_roots goes and marks
the fn decl, its type, its arguments etc., as used, so we don't collect
it.)

We could just bump function_depth around the new call to
synthesize_method.  Alternatively, as in this patch, we can create a new
GC root to hold the expression list.  Since I'm adding a new global, I
felt compelled to get rid of one, and I actually did find an unused one!
So, 86 it.  But I'm also happy to just go with bumping function_depth.

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

gcc/cp/ChangeLog:

PR c++/99831
* parser.c (cp_parser_functional_cast): Make the expression list
a GC root.
* pt.c: Remove the saved_trees global.

gcc/testsuite/ChangeLog:

PR c++/99831
* g++.dg/other/gc6.C: New test.
---
 gcc/cp/parser.c  | 20 
 gcc/cp/pt.c  |  1 -
 gcc/testsuite/g++.dg/other/gc6.C | 16 
 3 files changed, 28 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/other/gc6.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0477c42afe..28d7a8be258 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30569,13 +30569,17 @@ cp_parser_simple_cast_expression (cp_parser *parser)
 }
 
 /* Parse a functional cast to TYPE.  Returns an expression
-   representing the cast.  */
+   representing the cast.  Preserve the expression list across
+   a garbage collect (by making it a GC root), which can occur
+   in finish_compound_literal -> complete_type, when we synthesize
+   a constexpr comparison function.  */
+
+static GTY(()) tree fncast_expression_list;
 
 static cp_expr
 cp_parser_functional_cast (cp_parser* parser, tree type)
 {
   vec *vec;
-  tree expression_list;
   cp_expr cast;
   bool nonconst_p;
 
@@ -30588,12 +30592,12 @@ cp_parser_functional_cast (cp_parser* parser, tree 
type)
 {
   cp_lexer_set_source_position (parser->lexer);
   maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
-  expression_list = cp_parser_braced_list (parser, &nonconst_p);
-  CONSTRUCTOR_IS_DIRECT_INIT (expression_list) = 1;
+  fncast_expression_list = cp_parser_braced_list (parser, &nonconst_p);
+  CONSTRUCTOR_IS_DIRECT_INIT (fncast_expression_list) = 1;
   if (TREE_CODE (type) == TYPE_DECL)
type = TREE_TYPE (type);
 
-  cast = finish_compound_literal (type, expression_list,
+  cast = finish_compound_literal (type, fncast_expression_list,
  tf_warning_or_error, fcl_functional);
   /* Create a location of the form:
type_name{i, f}
@@ -30612,10 +30616,10 @@ cp_parser_functional_cast (cp_parser* parser, tree 
type)
 /*allow_expansion_p=*/true,
 /*non_constant_p=*/NULL);
   if (vec == NULL)
-expression_list = error_mark_node;
+fncast_expression_list = error_mark_node;
   else
 {
-  expression_list = build_tree_list_vec (vec);
+  fncast_expression_list = build_tree_list_vec (vec);
   release_tree_vector (vec);
 }
 
@@ -30626,7 +30630,7 @@ cp_parser_functional_cast (cp_parser* parser, tree type)
  finishing at the closing paren.  */
   location_t combined_loc = make_location (start_loc, start_loc,
   parser->lexer);
-  cast = build_functional_cast (combined_loc, type, expression_list,
+  cast = build_functional_cast (combined_loc, type, fncast_expression_list,
 tf_warning_or_error);
   
   /* [expr.const]/1: In an integral constant expression "only type
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc6f2f37f9b..7956e83c1de 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -65,7 +65,6 @@ static GTY(()) struct pending_template *last_pending_template;
 int processing_template_parmlist;
 static int template_header_count;
 
-static GTY(()) tree saved_trees;
 static vec inline_parm_levels;
 
 static GTY(()) struct tinst_level *current_t

Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel

[Bernhard Reutner-Fischer via Gcc-patches]

On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches" 
 wrote:
>Since uiret should be used only for user interrupt handler return,
>don't
>generate uiret in interrupt handler return with -mcmodel=kernel even if
>UINTR is enabled.
>
>gcc/
>
>   PR target/99870
>   * config/i386/i386.md (interrupt_return): Don't generate uiret
>   for -mcmodel=kernel.
>
>gcc/testsuite/
>
>   * gcc.target/i386/pr99870.c: New test.
>---
> gcc/config/i386/i386.md |  3 ++-
> gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
> 2 files changed, 21 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
>
>diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
>index 9ff35d9a607..1055b4187b2 100644
>--- a/gcc/config/i386/i386.md
>+++ b/gcc/config/i386/i386.md
>@@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
>(unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
>   "reload_completed"
> {
>-  return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
>+  return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
>+   ? "uiret" : "iretq") : "iret";
> })
> 
>;; Used by x86_machine_dependent_reorg to avoid penalty on single byte
>RET
>diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c
>b/gcc/testsuite/gcc.target/i386/pr99870.c
>new file mode 100644
>index 000..0dafa001ba9
>--- /dev/null
>+++ b/gcc/testsuite/gcc.target/i386/pr99870.c
>@@ -0,0 +1,19 @@
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
>+/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } }
>*/
>+
>+void
>+__attribute__((interrupt))
>+fn (void *frame)
>+{
>+}
>+
>+typedef void (*fn_t) (void *) __attribute__((interrupt));
>+
>+fn_t fns[] =
>+{
>+  fn,
>+};
>+
>+/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } }

This matches ia32 and the others as well (x32 and amd64 or x86_64) doesn't it.
>*/
>+/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 }
>} } } */

So this is superfluous without a trailing anchor for the first, fwiw.
Thanks,

[PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()

[Joel Sherrill]

Change the preprocessor logic so RTEMS uses utime().
gcc/ada/
* adaint.c (__gnat_copy_attribs): RTEMS should use utime().
---
 gcc/ada/adaint.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index 0a90c92402c..d3b83f61076 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -3270,7 +3270,7 @@ __gnat_copy_attribs (char *from ATTRIBUTE_UNUSED, char 
*to ATTRIBUTE_UNUSED,
  return -1;
   }
 
-#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7)
+#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7) || defined(__rtems__)
 
   /* VxWorks prior to 7 only has utime.  */
 
-- 
2.24.4

Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel

[Bernhard Reutner-Fischer via Gcc-patches]

On 1 April 2021 20:31:13 CEST, Bernhard Reutner-Fischer  
wrote:
>On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
> wrote:
>>Since uiret should be used only for user interrupt handler return,
>>don't
>>generate uiret in interrupt handler return with -mcmodel=kernel even
>if
>>UINTR is enabled.
>>
>>gcc/
>>
>>  PR target/99870
>>  * config/i386/i386.md (interrupt_return): Don't generate uiret
>>  for -mcmodel=kernel.
>>
>>gcc/testsuite/
>>
>>  * gcc.target/i386/pr99870.c: New test.
>>---
>> gcc/config/i386/i386.md |  3 ++-
>> gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
>> 2 files changed, 21 insertions(+), 1 deletion(-)
>> create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
>>
>>diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
>>index 9ff35d9a607..1055b4187b2 100644
>>--- a/gcc/config/i386/i386.md
>>+++ b/gcc/config/i386/i386.md
>>@@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
>>(unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
>>   "reload_completed"
>> {
>>-  return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
>>+  return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
>>+  ? "uiret" : "iretq") : "iret";
>> })
>> 
>>;; Used by x86_machine_dependent_reorg to avoid penalty on single byte
>>RET
>>diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c
>>b/gcc/testsuite/gcc.target/i386/pr99870.c
>>new file mode 100644
>>index 000..0dafa001ba9
>>--- /dev/null
>>+++ b/gcc/testsuite/gcc.target/i386/pr99870.c
>>@@ -0,0 +1,19 @@
>>+/* { dg-do compile } */
>>+/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
>>+/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } }
>>*/
>>+
>>+void
>>+__attribute__((interrupt))
>>+fn (void *frame)

Oh and of course that named param should trigger an unused parm warning making 
the test fail as is.
Why wasn't that flagged? Isn't this warning on by default?

>>+{
>>+}
>>+
>>+typedef void (*fn_t) (void *) __attribute__((interrupt));
>>+
>>+fn_t fns[] =
>>+{
>>+  fn,
>>+};
>>+
>>+/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } }
>
>This matches ia32 and the others as well (x32 and amd64 or x86_64)
>doesn't it.
>>*/
>>+/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 }
>>} } } */
>
>So this is superfluous without a trailing anchor for the first, fwiw.
>Thanks,

Re: [PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()

[Bernhard Reutner-Fischer via Gcc-patches]

On 1 April 2021 20:32:34 CEST, Joel Sherrill  wrote:
>Change the preprocessor logic so RTEMS uses utime().
>gcc/ada/
>   * adaint.c (__gnat_copy_attribs): RTEMS should use utime().

RTEMS probably doesn't care alot about accurate time, from the looks. Otherwise 
it would not mandate use of the obsolescent utime() (AFA SUS is concerned WRT 
nanoseconds precision) it seems?
They probably know what they're doing I suppose.
thanks,
PS I shouldn't reply to none of my business, I know..
>---
> gcc/ada/adaint.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
>index 0a90c92402c..d3b83f61076 100644
>--- a/gcc/ada/adaint.c
>+++ b/gcc/ada/adaint.c
>@@ -3270,7 +3270,7 @@ __gnat_copy_attribs (char *from ATTRIBUTE_UNUSED,
>char *to ATTRIBUTE_UNUSED,
>  return -1;
>   }
> 
>-#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7)
>+#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7) ||
>defined(__rtems__)
> 
>   /* VxWorks prior to 7 only has utime.  */
> 

Re: [PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()

[Bernhard Reutner-Fischer via Gcc-patches]

On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer  
wrote:
>On 1 April 2021 20:32:34 CEST, Joel Sherrill  wrote:
>>Change the preprocessor logic so RTEMS uses utime().
>>gcc/ada/
>>  * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
>
>RTEMS probably doesn't care alot about accurate time, from the looks.
>Otherwise it would not mandate use of the obsolescent utime() (AFA SUS
>is concerned WRT nanoseconds precision) it seems?
>They probably know what they're doing I suppose.
>thanks,
>PS I shouldn't reply to none of my business, I know..

Meh. Okok. You got me. April 1st ;)
grats :)

Re: [PATCH] c++: GC collects live data when synthesizing operator== [PR99831]

[Jason Merrill via Gcc-patches]

On 4/1/21 2:15 PM, Marek Polacek wrote:

Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:

   if (kind == sfk_comparison)
 {
   /* If the function was declared constexpr, check that the definition
  qualifies.  Otherwise we can define the function lazily.  */
   if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
 synthesize_method (fn);
   return;
 }

which in this test triggers when we're processing the string<"a">{} in
the static_assert.  First, we create a CONSTRUCTOR for the "{}" in
cp_parser_functional_cast, then we call finish_compound_literal which
calls complete_type and that results in garbage collection, which then
frees the CONSTRUCTOR {} we created when parsing the braced-list in
string<"a">{} -- at this point, it's not referenced by anything.
(That's not the case for 'type' in finish_compound_literal: the symbol
table contains a node for operator==, so ggc_mark_roots goes and marks
the fn decl, its type, its arguments etc., as used, so we don't collect
it.)

We could just bump function_depth around the new call to
synthesize_method.  Alternatively, as in this patch, we can create a new
GC root to hold the expression list.  Since I'm adding a new global, I
felt compelled to get rid of one, and I actually did find an unused one!
So, 86 it.  But I'm also happy to just go with bumping function_depth.


I think bumping function_depth is the right solution; this patch only 
deals with one source of unreachable expressions that could be collected 
prematurely if complete_type results in GC running.



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

gcc/cp/ChangeLog:

PR c++/99831
* parser.c (cp_parser_functional_cast): Make the expression list
a GC root.
* pt.c: Remove the saved_trees global.

gcc/testsuite/ChangeLog:

PR c++/99831
* g++.dg/other/gc6.C: New test.
---
  gcc/cp/parser.c  | 20 
  gcc/cp/pt.c  |  1 -
  gcc/testsuite/g++.dg/other/gc6.C | 16 
  3 files changed, 28 insertions(+), 9 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/other/gc6.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0477c42afe..28d7a8be258 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30569,13 +30569,17 @@ cp_parser_simple_cast_expression (cp_parser *parser)
  }
  
  /* Parse a functional cast to TYPE.  Returns an expression

-   representing the cast.  */
+   representing the cast.  Preserve the expression list across
+   a garbage collect (by making it a GC root), which can occur
+   in finish_compound_literal -> complete_type, when we synthesize
+   a constexpr comparison function.  */
+
+static GTY(()) tree fncast_expression_list;
  
  static cp_expr

  cp_parser_functional_cast (cp_parser* parser, tree type)
  {
vec *vec;
-  tree expression_list;
cp_expr cast;
bool nonconst_p;
  
@@ -30588,12 +30592,12 @@ cp_parser_functional_cast (cp_parser* parser, tree type)

  {
cp_lexer_set_source_position (parser->lexer);
maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
-  expression_list = cp_parser_braced_list (parser, &nonconst_p);
-  CONSTRUCTOR_IS_DIRECT_INIT (expression_list) = 1;
+  fncast_expression_list = cp_parser_braced_list (parser, &nonconst_p);
+  CONSTRUCTOR_IS_DIRECT_INIT (fncast_expression_list) = 1;
if (TREE_CODE (type) == TYPE_DECL)
type = TREE_TYPE (type);
  
-  cast = finish_compound_literal (type, expression_list,

+  cast = finish_compound_literal (type, fncast_expression_list,
  tf_warning_or_error, fcl_functional);
/* Create a location of the form:
type_name{i, f}
@@ -30612,10 +30616,10 @@ cp_parser_functional_cast (cp_parser* parser, tree 
type)
 /*allow_expansion_p=*/true,
 /*non_constant_p=*/NULL);
if (vec == NULL)
-expression_list = error_mark_node;
+fncast_expression_list = error_mark_node;
else
  {
-  expression_list = build_tree_list_vec (vec);
+  fncast_expression_list = build_tree_list_vec (vec);
release_tree_vector (vec);
  }
  
@@ -30626,7 +30630,7 @@ cp_parser_functional_cast (cp_parser* parser, tree type)

   finishing at the closing paren.  */
location_t combined_loc = make_location (start_loc, start_loc,
   parser->lexer);
-  cast = build_functional_cast (combined_loc, type, expression_list,
+  cast = build_functional_cast (combined_loc, type, fncast_expression_list,
  tf_warning_or_error);

/* [expr.const]/1: In an integral constant expression "only type

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc6f2f37f9b..7956e83c1de 100644
--- a/gcc/cp/

Re: [PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()

[Joel Sherrill]

L

On Thu, Apr 1, 2021, 2:08 PM Bernhard Reutner-Fischer 
wrote:

> On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer <
> rep.dot@gmail.com> wrote:
> >On 1 April 2021 20:32:34 CEST, Joel Sherrill  wrote:
> >>Change the preprocessor logic so RTEMS uses utime().
> >>gcc/ada/
> >>  * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
> >
> >RTEMS probably doesn't care alot about accurate time, from the looks.
> >Otherwise it would not mandate use of the obsolescent utime() (AFA SUS
> >is concerned WRT nanoseconds precision) it seems?
> >They probably know what they're doing I suppose.
> >thanks,
> >PS I shouldn't reply to none of my business, I know.
>

RTEMS is a single address space real-time operating system.  It's not that
we don't care about nanoaecond accurate time. It's just that we don't
support the utimesat() call yet. Given a choice, I'll take still compiles
and works. :)

A filesystem is not required with RTEMS and few deployed systems would have
much beyond a static root filesystem anyway.


> Meh. Okok. You got me. April 1st ;)
> grats :)
>

We'd be happy to have help implementing the missing POSIX *at() methods.
And that's not an April Fools Day joke. :)

--joel

>

[pushed] c++: variadic lambda noexcept-specifier [PR99583]

[Jason Merrill via Gcc-patches]

The tree-walk looking for parameter packs didn't find this one because we
weren't stepping into TYPE_RAISES_EXCEPTIONS.

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

gcc/cp/ChangeLog:

PR c++/99583
PR c++/99584
* tree.c (cp_walk_subtrees) [FUNCTION_TYPE]: Walk into
TYPE_RAISES_EXCEPTIONS.

gcc/testsuite/ChangeLog:

PR c++/99583
* g++.dg/cpp0x/lambda/lambda-variadic12.C: New test.
---
 gcc/cp/tree.c | 5 +
 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C | 9 +
 2 files changed, 14 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index dca947bf52a..13cc61c3123 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -5415,6 +5415,11 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p, 
walk_tree_fn func,
}
   break;
 
+case FUNCTION_TYPE:
+case METHOD_TYPE:
+  WALK_SUBTREE (TYPE_RAISES_EXCEPTIONS (*tp));
+  break;
+
 default:
   return NULL_TREE;
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C
new file mode 100644
index 000..674615748e6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C
@@ -0,0 +1,9 @@
+// PR c++/99583
+// { dg-do compile { target c++11 } }
+
+void f(...);
+
+template 
+void g() {
+ f([]() noexcept(B) {} ...);
+}

base-commit: af78514a18ca5c9aaa10813bb4dc639d7ccdf0cc
-- 
2.27.0

Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel

[Uros Bizjak via Gcc-patches]

On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu  wrote:
>
> Since uiret should be used only for user interrupt handler return, don't
> generate uiret in interrupt handler return with -mcmodel=kernel even if
> UINTR is enabled.

NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch off SSE.

Uros.

> gcc/
>
> PR target/99870
> * config/i386/i386.md (interrupt_return): Don't generate uiret
> for -mcmodel=kernel.
>
> gcc/testsuite/
>
> * gcc.target/i386/pr99870.c: New test.
> ---
>  gcc/config/i386/i386.md |  3 ++-
>  gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
>  2 files changed, 21 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 9ff35d9a607..1055b4187b2 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
> (unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
>"reload_completed"
>  {
> -  return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
> +  return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
> +? "uiret" : "iretq") : "iret";
>  })
>
>  ;; Used by x86_machine_dependent_reorg to avoid penalty on single byte RET
> diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c 
> b/gcc/testsuite/gcc.target/i386/pr99870.c
> new file mode 100644
> index 000..0dafa001ba9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr99870.c
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
> +/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } } */
> +
> +void
> +__attribute__((interrupt))
> +fn (void *frame)
> +{
> +}
> +
> +typedef void (*fn_t) (void *) __attribute__((interrupt));
> +
> +fn_t fns[] =
> +{
> +  fn,
> +};
> +
> +/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } } */
> +/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 } } } } 
> */
> --
> 2.30.2
>

[PATCH] c++: placeholder type constraint inside range-for [PR99869]

[Patrick Palka via Gcc-patches]

In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in this case is
adc_unspecified.

We could safely relax the assert to also accept adc_unspecified, but it
seems the context should really be adc_variable_type in this case.

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

gcc/cp/ChangeLog:

PR c++/99869
* parser.c (do_range_for_auto_deduction): Pass adc_variable_type
to do_auto_deduction.

gcc/testsuite/ChangeLog:

PR c++/99869
* g++.dg/cpp2a/concepts-placeholder6.C: New test.
---
 gcc/cp/parser.c|  4 +++-
 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C | 10 ++
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0477c42afe..808e5b61b1e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12878,7 +12878,9 @@ do_range_for_auto_deduction (tree decl, tree range_expr)
RO_UNARY_STAR,
tf_warning_or_error);
  TREE_TYPE (decl) = do_auto_deduction (TREE_TYPE (decl),
-   iter_decl, auto_node);
+   iter_decl, auto_node,
+   tf_warning_or_error,
+   adc_variable_type);
}
 }
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
new file mode 100644
index 000..18e7b56d77f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
@@ -0,0 +1,10 @@
+// PR c++/99869
+// { dg-do compile { target c++20 } }
+
+template  concept same_as = __is_same(T, U);
+
+template 
+void f() {
+  for (same_as auto c : "") {} // dg-error "constraint" }
+  for (same_as auto c : "") {}
+}
-- 
2.31.1.133.g84d06cdc06

Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel

[Jan Hubicka]

> On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu  wrote:
> >
> > Since uiret should be used only for user interrupt handler return, don't
> > generate uiret in interrupt handler return with -mcmodel=kernel even if
> > UINTR is enabled.
> 
> NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch off 
> SSE.

Agreed, while kernel name might not be bit too suggestive, code models
was intended to be quite general, so it may make sense to compile things
that are not kernels with kernel cmodel...

Honza
> 
> Uros.
> 
> > gcc/
> >
> > PR target/99870
> > * config/i386/i386.md (interrupt_return): Don't generate uiret
> > for -mcmodel=kernel.
> >
> > gcc/testsuite/
> >
> > * gcc.target/i386/pr99870.c: New test.
> > ---
> >  gcc/config/i386/i386.md |  3 ++-
> >  gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
> >  2 files changed, 21 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
> >
> > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> > index 9ff35d9a607..1055b4187b2 100644
> > --- a/gcc/config/i386/i386.md
> > +++ b/gcc/config/i386/i386.md
> > @@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
> > (unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
> >"reload_completed"
> >  {
> > -  return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
> > +  return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
> > +? "uiret" : "iretq") : "iret";
> >  })
> >
> >  ;; Used by x86_machine_dependent_reorg to avoid penalty on single byte RET
> > diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c 
> > b/gcc/testsuite/gcc.target/i386/pr99870.c
> > new file mode 100644
> > index 000..0dafa001ba9
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr99870.c
> > @@ -0,0 +1,19 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
> > +/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } } */
> > +
> > +void
> > +__attribute__((interrupt))
> > +fn (void *frame)
> > +{
> > +}
> > +
> > +typedef void (*fn_t) (void *) __attribute__((interrupt));
> > +
> > +fn_t fns[] =
> > +{
> > +  fn,
> > +};
> > +
> > +/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } } */
> > +/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 } } } 
> > } */
> > --
> > 2.30.2
> >

Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel

[H.J. Lu via Gcc-patches]

On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka  wrote:
>
> > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu  wrote:
> > >
> > > Since uiret should be used only for user interrupt handler return, don't
> > > generate uiret in interrupt handler return with -mcmodel=kernel even if
> > > UINTR is enabled.
> >
> > NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch off 
> > SSE.
>
> Agreed, while kernel name might not be bit too suggestive, code models
> was intended to be quite general, so it may make sense to compile things
> that are not kernels with kernel cmodel...
>

Then kernel must be built with -mno-uintr if there are kernel interrupt handlers
in C.  That means that other UINTR intrinsics won't be available to
kernel source
and inline asm statement should be used instead.

-- 
H.J.

Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel

[Uros Bizjak via Gcc-patches]

On Thu, Apr 1, 2021 at 10:47 PM H.J. Lu  wrote:
>
> On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka  wrote:
> >
> > > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu  wrote:
> > > >
> > > > Since uiret should be used only for user interrupt handler return, don't
> > > > generate uiret in interrupt handler return with -mcmodel=kernel even if
> > > > UINTR is enabled.
> > >
> > > NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch 
> > > off SSE.
> >
> > Agreed, while kernel name might not be bit too suggestive, code models
> > was intended to be quite general, so it may make sense to compile things
> > that are not kernels with kernel cmodel...
> >
>
> Then kernel must be built with -mno-uintr if there are kernel interrupt 
> handlers
> in C.  That means that other UINTR intrinsics won't be available to
> kernel source
> and inline asm statement should be used instead.

This is what the kernel does anyway. It doesn't care for compiler builtins.

Uros.

Re: [PATCH v2] c++: GC collects live data when synthesizing operator== [PR99831]

[Marek Polacek via Gcc-patches]

On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote:
> On 4/1/21 2:15 PM, Marek Polacek wrote:
> > Here we crash in reshape_init because we're accessing ggc_freed
> > & poisoned data: since r277865 in defaulted_late_check we call
> > synthesize_method here:
> > 
> >if (kind == sfk_comparison)
> >  {
> >/* If the function was declared constexpr, check that the definition
> >   qualifies.  Otherwise we can define the function lazily.  */
> >if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
> >  synthesize_method (fn);
> >return;
> >  }
> > 
> > which in this test triggers when we're processing the string<"a">{} in
> > the static_assert.  First, we create a CONSTRUCTOR for the "{}" in
> > cp_parser_functional_cast, then we call finish_compound_literal which
> > calls complete_type and that results in garbage collection, which then
> > frees the CONSTRUCTOR {} we created when parsing the braced-list in
> > string<"a">{} -- at this point, it's not referenced by anything.
> > (That's not the case for 'type' in finish_compound_literal: the symbol
> > table contains a node for operator==, so ggc_mark_roots goes and marks
> > the fn decl, its type, its arguments etc., as used, so we don't collect
> > it.)
> > 
> > We could just bump function_depth around the new call to
> > synthesize_method.  Alternatively, as in this patch, we can create a new
> > GC root to hold the expression list.  Since I'm adding a new global, I
> > felt compelled to get rid of one, and I actually did find an unused one!
> > So, 86 it.  But I'm also happy to just go with bumping function_depth.
> 
> I think bumping function_depth is the right solution; this patch only deals
> with one source of unreachable expressions that could be collected
> prematurely if complete_type results in GC running.

Fair enough, let's go back to my original patch.

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

And now I should get back to

where we actually want a new GC root...

-- >8 --
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:

  if (kind == sfk_comparison)
{
  /* If the function was declared constexpr, check that the definition
 qualifies.  Otherwise we can define the function lazily.  */
  if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
synthesize_method (fn);
  return;
}

which in this test triggers when we're processing the string<"a">{} in
the static_assert.  First, we create a CONSTRUCTOR for the "{}" in
cp_parser_functional_cast, then we call finish_compound_literal which
calls complete_type and that results in garbage collection, which then
frees the CONSTRUCTOR {} we created when parsing the braced-list in
string<"a">{} -- at this point, it's not referenced by anything.
(That's not the case for 'type' in finish_compound_literal: the symbol
table contains a node for operator==, so ggc_mark_roots goes and marks
the fn decl, its type, its arguments etc., as used, so we don't collect
it.)

We could just bump function_depth around the new call to synthesize_method
to prevent GC.

gcc/cp/ChangeLog:

PR c++/99831
* method.c (defaulted_late_check): ++ and -- function_depth around
the call to synthesize_method.
* pt.c: Remove the saved_trees global.

gcc/testsuite/ChangeLog:

PR c++/99831
* g++.dg/other/gc6.C: New test.
---
 gcc/cp/method.c  |  7 ++-
 gcc/cp/pt.c  |  1 -
 gcc/testsuite/g++.dg/other/gc6.C | 16 
 3 files changed, 22 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/other/gc6.C

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 8ae7496f023..0f416bec35b 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -3131,7 +3131,12 @@ defaulted_late_check (tree fn)
   /* If the function was declared constexpr, check that the definition
 qualifies.  Otherwise we can define the function lazily.  */
   if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
-   synthesize_method (fn);
+   {
+ /* Prevent GC.  */
+ function_depth++;
+ synthesize_method (fn);
+ function_depth--;
+   }
   return;
 }
 
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc6f2f37f9b..7956e83c1de 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -65,7 +65,6 @@ static GTY(()) struct pending_template *last_pending_template;
 int processing_template_parmlist;
 static int template_header_count;
 
-static GTY(()) tree saved_trees;
 static vec inline_parm_levels;
 
 static GTY(()) struct tinst_level *current_tinst_level;
diff --git a/gcc/testsuite/g++.dg/other/gc6.C b/gcc/testsuite/g++.dg/other/gc6.C
new file mode 100644
index 000..ff45dd313d6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/other/g

Re: [PATCH v2] c++: GC collects live data when synthesizing operator== [PR99831]

[Jason Merrill via Gcc-patches]

On 4/1/21 5:12 PM, Marek Polacek wrote:

On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote:

On 4/1/21 2:15 PM, Marek Polacek wrote:

Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:

if (kind == sfk_comparison)
  {
/* If the function was declared constexpr, check that the definition
   qualifies.  Otherwise we can define the function lazily.  */
if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
  synthesize_method (fn);
return;
  }

which in this test triggers when we're processing the string<"a">{} in
the static_assert.  First, we create a CONSTRUCTOR for the "{}" in
cp_parser_functional_cast, then we call finish_compound_literal which
calls complete_type and that results in garbage collection, which then
frees the CONSTRUCTOR {} we created when parsing the braced-list in
string<"a">{} -- at this point, it's not referenced by anything.
(That's not the case for 'type' in finish_compound_literal: the symbol
table contains a node for operator==, so ggc_mark_roots goes and marks
the fn decl, its type, its arguments etc., as used, so we don't collect
it.)

We could just bump function_depth around the new call to
synthesize_method.  Alternatively, as in this patch, we can create a new
GC root to hold the expression list.  Since I'm adding a new global, I
felt compelled to get rid of one, and I actually did find an unused one!
So, 86 it.  But I'm also happy to just go with bumping function_depth.


I think bumping function_depth is the right solution; this patch only deals
with one source of unreachable expressions that could be collected
prematurely if complete_type results in GC running.


Fair enough, let's go back to my original patch.

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


OK.


And now I should get back to

where we actually want a new GC root...

-- >8 --
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:

   if (kind == sfk_comparison)
 {
   /* If the function was declared constexpr, check that the definition
  qualifies.  Otherwise we can define the function lazily.  */
   if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
 synthesize_method (fn);
   return;
 }

which in this test triggers when we're processing the string<"a">{} in
the static_assert.  First, we create a CONSTRUCTOR for the "{}" in
cp_parser_functional_cast, then we call finish_compound_literal which
calls complete_type and that results in garbage collection, which then
frees the CONSTRUCTOR {} we created when parsing the braced-list in
string<"a">{} -- at this point, it's not referenced by anything.
(That's not the case for 'type' in finish_compound_literal: the symbol
table contains a node for operator==, so ggc_mark_roots goes and marks
the fn decl, its type, its arguments etc., as used, so we don't collect
it.)

We could just bump function_depth around the new call to synthesize_method
to prevent GC.

gcc/cp/ChangeLog:

PR c++/99831
* method.c (defaulted_late_check): ++ and -- function_depth around
the call to synthesize_method.
* pt.c: Remove the saved_trees global.

gcc/testsuite/ChangeLog:

PR c++/99831
* g++.dg/other/gc6.C: New test.
---
  gcc/cp/method.c  |  7 ++-
  gcc/cp/pt.c  |  1 -
  gcc/testsuite/g++.dg/other/gc6.C | 16 
  3 files changed, 22 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/other/gc6.C

diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 8ae7496f023..0f416bec35b 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -3131,7 +3131,12 @@ defaulted_late_check (tree fn)
/* If the function was declared constexpr, check that the definition
 qualifies.  Otherwise we can define the function lazily.  */
if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
-   synthesize_method (fn);
+   {
+ /* Prevent GC.  */
+ function_depth++;
+ synthesize_method (fn);
+ function_depth--;
+   }
return;
  }
  
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c

index dc6f2f37f9b..7956e83c1de 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -65,7 +65,6 @@ static GTY(()) struct pending_template *last_pending_template;
  int processing_template_parmlist;
  static int template_header_count;
  
-static GTY(()) tree saved_trees;

  static vec inline_parm_levels;
  
  static GTY(()) struct tinst_level *current_tinst_level;

diff --git a/gcc/testsuite/g++.dg/other/gc6.C b/gcc/testsuite/g++.dg/other/gc6.C
new file mode 100644
index 000..ff45dd313d6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/other/gc6.C
@@ -0,0 +1,16 @@
+// PR c++/99831

Re: [PATCH] c++: placeholder type constraint inside range-for [PR99869]

[Jason Merrill via Gcc-patches]

On 4/1/21 4:09 PM, Patrick Palka wrote:

In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in this case is
adc_unspecified.

We could safely relax the assert to also accept adc_unspecified, but it
seems the context should really be adc_variable_type in this case.

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


OK.


gcc/cp/ChangeLog:

PR c++/99869
* parser.c (do_range_for_auto_deduction): Pass adc_variable_type
to do_auto_deduction.

gcc/testsuite/ChangeLog:

PR c++/99869
* g++.dg/cpp2a/concepts-placeholder6.C: New test.
---
  gcc/cp/parser.c|  4 +++-
  gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C | 10 ++
  2 files changed, 13 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0477c42afe..808e5b61b1e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12878,7 +12878,9 @@ do_range_for_auto_deduction (tree decl, tree range_expr)
RO_UNARY_STAR,
tf_warning_or_error);
  TREE_TYPE (decl) = do_auto_deduction (TREE_TYPE (decl),
-   iter_decl, auto_node);
+   iter_decl, auto_node,
+   tf_warning_or_error,
+   adc_variable_type);
}
  }
  }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
new file mode 100644
index 000..18e7b56d77f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
@@ -0,0 +1,10 @@
+// PR c++/99869
+// { dg-do compile { target c++20 } }
+
+template  concept same_as = __is_same(T, U);
+
+template 
+void f() {
+  for (same_as auto c : "") {} // dg-error "constraint" }
+  for (same_as auto c : "") {}
+}

Re: [PATCH v9] Practical improvement to libgcc complex divide

[Patrick McGehearty via Gcc-patches]

I would very much like to get all the details right on my next submission.
I'm submitting this query for feedback before I do the full submission.

Most changes requested require obvious fixes. One has me confused about
the best action to take.

- - - -

On the issue of alloca vs XALLOCAVEC, I discovered that XALLOCAVEC has
been around and recommended since at least 2010, but I could not find
any discussion of why XALLOCAVEC is preferred to alloca. Understanding
the purpose of making the change would help in resolve the following
decision.

Currently,in gcc/c-family/c-cppbuiltin.c, XALLOCAVEC does not appear
at all. alloca appears 13 times. Both appear in other files in the
same directory. In the routine I'm modifying, four current allocations
to macro_name use alloca.

I see four options:

1) Use alloca as that is consistent with the existing style within
the source file. That is my current choice, but disliked by the
reviewer.

2) If I use XALLOCAVEC just for my three new uses of alloca, which
also assign to macro_name, we will have an inconsistent coding
pattern. That violates the principle of maintaining existing style
within a source file or routine. This choice seems ugly.

3) If I use XALLOCATE for my three new uses for alloca and
change the other four allcoations to macro_name in the same
routine but leave the other 9 uses of alloca alone, we have
consistency in the modified routine but not the source file.
If this is the recommended procedure, I'm willing.

4) If I change all uses of alloc to XALLOCATE in the file, that makes
the file consistent but adds source file changes to the patch in
routines that are completely unrelated to my goal of improving complex
divide. It increases risk of causing subtle problems either through
my editing errors or lack of understanding by me of any differences
between alloca and XALLOCATE.  I'm less comfortable with this option.

- - - -
- - - -
The rest appear to be editing issues on my part.
I'll will make the following changes.

- - - -

I will fix the type of name_len to const size_t.

- - - -


I will fix abort/exit in the three test files to be:
extern void abort(void);
extern void exit(int status);

- - - -
I will proofread and fix the comments in the three test files.
than/that, missing "to", etc.

- - - -
In libgcc/config/rs6000/_divkc3.c

I see one additional blank line that will be removed.

- - - -
In libgcc/libgcc2.c

- - - -

I admit the names XCTYPE and XMTYPE are not very imaginative. My
intention was represent "extra precision" but the potential confusion
with extended precision did not occur to me at the time.  The
XCTYPE/XMTYPE is intended to be the next larger precision to allow the
same source code to be used for both the half precision and float
precision cases.

Maybe it would be better to think "additional precision",
and use ACTYPE and AMTYPE?

- - - -
Comment "...errors than can..." should be "...errors that can..."
Will make the change.


On 3/31/2021 12:03 PM, Bernhard Reutner-Fischer wrote:

On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches  wrote:


diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
index 9f993c4..c0d9e57 100644
--- a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -1277,8 +1277,10 @@ c_cpp_builtins (cpp_reader *pfile)
{
  scalar_float_mode mode = mode_iter.require ();
  const char *name = GET_MODE_NAME (mode);
+ const int name_len = strlen (name);

strlen returns a size_t

Funny that we do not have a pre-seeded mode_name_len array but call
strlen on modes over and over again.


+ char float_h_prefix[16] = "";
  char *macro_name
-   = (char *) alloca (strlen (name)
+   = (char *) alloca (name_len
   + sizeof ("__LIBGCC__MANT_DIG__"));
  sprintf (macro_name, "__LIBGCC_%s_MANT_DIG__", name);
  builtin_define_with_int_value (macro_name,
@@ -1286,20 +1288,29 @@ c_cpp_builtins (cpp_reader *pfile)
  if (!targetm.scalar_mode_supported_p (mode)
  || !targetm.libgcc_floating_mode_supported_p (mode))
continue;
- macro_name = (char *) alloca (strlen (name)
+ macro_name = (char *) alloca (name_len
+ sizeof ("__LIBGCC_HAS__MODE__"));
  sprintf (macro_name, "__LIBGCC_HAS_%s_MODE__", name);
  cpp_define (pfile, macro_name);
- macro_name = (char *) alloca (strlen (name)
+ macro_name = (char *) alloca (name_len
+ sizeof ("__LIBGCC__FUNC_EXT__"));
  sprintf (macro_name, "__LIBGCC_%s_FUNC_EXT__", name);

The above should have been split out as separate independent patchlet
to get it out of the way.

As noted already the use of alloca is a pre-existing (coding-style) bug
and we should use XALLOCAVEC or appropriately sized fixed buffers to
begin with. The amount of alloca in defining all these is amazing.


diff

[committed] analyzer: record per-enode saved_diagnostics

[David Malcolm via Gcc-patches]

Various places iterate through all of the saved_diagnostics to find
just the ones that are at a given enode.  This patch adds a per-enode
record of the diagnostics that are at each node, to save iterating
through all of the diagnostics each time.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 6e943d5a2e3c581e40ccab46bec986a1f22c70c2.

gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (diagnostic_manager::add_diagnostic): Make
enode param non-constant, and call add_diagnostic on it.  Add
enode index to log message.
(diagnostic_manager::add_diagnostic): Make enode param
non-constant.
* diagnostic-manager.h (diagnostic_manager::add_diagnostic):
Likewise for both decls.
* engine.cc
(impl_region_model_context::impl_region_model_context): Likewise
for enode_for_diag.
(impl_sm_context::impl_sm_context): Likewise.
(impl_sm_context::m_enode_for_diag): Likewise.
(exploded_node::dump_dot): Don't pass the diagnostic manager
to dump_saved_diagnostics.
(exploded_node::dump_saved_diagnostics): Drop param.  Iterate
directly through all saved diagnostics for the enode, rather
than all saved diagnostics in the diagnostic_manager and
filtering.
(exploded_node::on_stmt): Make non-const.
(exploded_node::on_edge): Likewise.
(exploded_node::on_longjmp): Likewise.
(exploded_node::detect_leaks): Likewise.
(exploded_graph::get_or_create_node): Make enode_for_diag param
non-const.
(exploded_graph_annotator::print_enode): Iterate
directly through all saved diagnostics for the enode, rather
than all saved diagnostics in the diagnostic_manager and
filtering.
* exploded-graph.h
(impl_region_model_context::impl_region_model_context): Make
enode_for_diag param non-constant.
(impl_region_model_context::m_enode_for_diag): Likewise.
(exploded_node::dump_saved_diagnostics): Drop param.
(exploded_node::on_stmt): Make non-const.
(exploded_node::on_edge): Likewise.
(exploded_node::on_longjmp): Likewise.
(exploded_node::detect_leaks): Likewise.
(exploded_node::add_diagnostic): New.
(exploded_node::get_num_diagnostics): New.
(exploded_node::get_saved_diagnostic): New.
(exploded_node::m_saved_diagnostics): New.
(exploded_graph::get_or_create_node): Make enode_for_diag param
non-constant.
* feasible-graph.cc (feasible_node::dump_dot): Drop
diagnostic_manager from call to dump_saved_diagnostics.
* program-state.cc (program_state::on_edge): Convert enode param
to non-const pointer.
(program_state::prune_for_point): Likewise for enode_for_diag
param.
* program-state.h (program_state::on_edge): Convert enode param
to non-const pointer.
(program_state::prune_for_point): Likewise for enode_for_diag
param.
---
 gcc/analyzer/diagnostic-manager.cc |  9 +++---
 gcc/analyzer/diagnostic-manager.h  |  4 +--
 gcc/analyzer/engine.cc | 52 +-
 gcc/analyzer/exploded-graph.h  | 34 +--
 gcc/analyzer/feasible-graph.cc |  5 ++-
 gcc/analyzer/program-state.cc  | 12 +++
 gcc/analyzer/program-state.h   |  4 +--
 7 files changed, 65 insertions(+), 55 deletions(-)

diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index a376755b7ee..9ec3e899e85 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -791,7 +791,7 @@ diagnostic_manager::diagnostic_manager (logger *logger, 
engine *eng,
 
 void
 diagnostic_manager::add_diagnostic (const state_machine *sm,
-   const exploded_node *enode,
+   exploded_node *enode,
const supernode *snode, const gimple *stmt,
stmt_finder *finder,
tree var,
@@ -809,16 +809,17 @@ diagnostic_manager::add_diagnostic (const state_machine 
*sm,
 = new saved_diagnostic (sm, enode, snode, stmt, finder, var, sval,
state, d, m_saved_diagnostics.length ());
   m_saved_diagnostics.safe_push (sd);
+  enode->add_diagnostic (sd);
   if (get_logger ())
-log ("adding saved diagnostic %i at SN %i: %qs",
+log ("adding saved diagnostic %i at SN %i to EN %i: %qs",
 sd->get_index (),
-snode->m_index, d->get_kind ());
+snode->m_index, enode->m_index, d->get_kind ());
 }
 
 /* Queue pending_diagnostic D at ENODE for later emission.  */
 
 void
-diagnostic_manager::add_diagnostic (const exploded_node *enode,
+diagnostic_manager::add_diagnostic (exploded_node *enode,
const supernode *snode, const gimple *stmt,
  

Re: [Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186

[Jerry DeLisle]

Paul,

This looks OK to me for Trunk. I believe 10 is in freeze so it may have 
to wait or get release manager approval.


Jerry

On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote:

This one is trivial. The wrong error message was transformed by my patch
for PR98897 into an ICE. This patch now produces the correct error.

Regtests OK on FC33/x86_64 - OK for the affected branches?

Paul

Fortran: Fix ICE on wrong code [PR99818].

2021-04-01  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/99818
* interface.c (compare_parameter): The codimension attribute is
applied to the _data field of class formal arguments.

gcc/testsuite/ChangeLog

PR fortran/99818
* gfortran.dg/coarray_48.f90: New test.