Re: [PATCH] Fix PR66552, Missed optimization when shift amount is result of signed modulus

[Richard Biener]

On Mon, 17 Feb 2020, Li Jia He wrote:

> Hi,
> 
> This patch wants to fix PR66552 on gimple and optimizes (x shift (n mod C))
> to (x shift (n bit_and (C - 1))) when C is a constant and power of two as
> discussed in PR66552.
> 
> The regression testing for the patch was done on GCC mainline on
> 
> powerpc64le-unknown-linux-gnu (Power 9 LE)
> 
> with no regressions.  Is it OK for GCC11 ?

I fail to see the connection with a shift operation, can you explain?

Thanks,
Richard.

> Thanks,
> Lijia He
> 
> gcc/ChangeLog
> 2020-02-17  Li Jia He  
> 
>   PR tree-optimization/66552
>   * match.pd (x shift (n mod pow2(c))): Optimizes to
>   (x shift (n bit_and (pow2(c) - 1)).
> 
> testsuite/ChangeLog
> 2019-02-17  Li Jia He  
> 
>   PR tree-optimization/66552
>   * testsuite/gcc.dg/pr66552.c: New testcase.
> ---
>  gcc/match.pd   |  6 ++
>  gcc/testsuite/gcc.dg/pr66552.c | 14 ++
>  2 files changed, 20 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/pr66552.c
> 
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 73834c25593..1d74f7dba7f 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -546,6 +546,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>   (simplify
>(mod (mod@2 @0 @1) @1)
>@2)
> + /* Optimize (x shift (n mod C)) to (x shift (n bit_and (C - 1))) when C is a
> +constant and power of two.  */
> + (for shift (lshift rshift)
> +  (simplify
> +   (shift @0 (mod @1 integer_pow2p@2))
> +   (shift @0 (bit_and @1 (minus @2 { build_int_cst (TREE_TYPE (@2), 1); 
> })
>   /* From extract_muldiv_1: (X * C1) % C2 is zero if C1 is a multiple of C2.  
> */
>   (simplify
>(mod (mult @0 INTEGER_CST@1) INTEGER_CST@2)
> diff --git a/gcc/testsuite/gcc.dg/pr66552.c b/gcc/testsuite/gcc.dg/pr66552.c
> new file mode 100644
> index 000..7583c9ad25a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr66552.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-lower" } */
> +
> +unsigned a(unsigned x, int n)
> +{
> +  return x >> (n % 32);
> +}
> +
> +unsigned b(unsigned x, int n)
> +{
> +  return x << (n % 32);
> +}
> +
> +/* { dg-final { scan-tree-dump-not " % " "lower" } } */
> 

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

Re: [PATCH] Fix PR66552, Missed optimization when shift amount is result of signed modulus

[Jakub Jelinek]

On Mon, Feb 17, 2020 at 09:01:13AM +0100, Richard Biener wrote:
> On Mon, 17 Feb 2020, Li Jia He wrote:
> > This patch wants to fix PR66552 on gimple and optimizes (x shift (n mod C))
> > to (x shift (n bit_and (C - 1))) when C is a constant and power of two as
> > discussed in PR66552.
> > 
> > The regression testing for the patch was done on GCC mainline on
> > 
> > powerpc64le-unknown-linux-gnu (Power 9 LE)
> > 
> > with no regressions.  Is it OK for GCC11 ?
> 
> I fail to see the connection with a shift operation, can you explain?

As mentioned in the PR, the reason why we can only optimize unsigned
mod C into bit_and C-1 (where C is pow2p) is that signed modulo can be negative 
for
negative values (is non-positive).  For shifts negative values would be UB
and so we can assume it will not be negative (i.e. x will be either positive
or a negative multiple of C) and can use bit_and then.

Jakub

Re: [PATCH] Fix PR66552, Missed optimization when shift amount is result of signed modulus

[Richard Biener]

On Mon, 17 Feb 2020, Jakub Jelinek wrote:

> On Mon, Feb 17, 2020 at 09:01:13AM +0100, Richard Biener wrote:
> > On Mon, 17 Feb 2020, Li Jia He wrote:
> > > This patch wants to fix PR66552 on gimple and optimizes (x shift (n mod 
> > > C))
> > > to (x shift (n bit_and (C - 1))) when C is a constant and power of two as
> > > discussed in PR66552.
> > > 
> > > The regression testing for the patch was done on GCC mainline on
> > > 
> > > powerpc64le-unknown-linux-gnu (Power 9 LE)
> > > 
> > > with no regressions.  Is it OK for GCC11 ?
> > 
> > I fail to see the connection with a shift operation, can you explain?
> 
> As mentioned in the PR, the reason why we can only optimize unsigned
> mod C into bit_and C-1 (where C is pow2p) is that signed modulo can be 
> negative for
> negative values (is non-positive).  For shifts negative values would be UB
> and so we can assume it will not be negative (i.e. x will be either positive
> or a negative multiple of C) and can use bit_and then.

That's clearly information that should be in the comment before the 
pattern.  We could also generally do the transform if we know
the other operand of the modulo is nonnegative.

Also the pattern doing the standalone transform does

/* Optimize TRUNC_MOD_EXPR by a power of two into a BIT_AND_EXPR,
   i.e. "X % C" into "X & (C - 1)", if X and C are positive.
   Also optimize A % (C << N)  where C is a power of 2,
   to A & ((C << N) - 1).  */
(match (power_of_two_cand @1)
 INTEGER_CST@1)
(match (power_of_two_cand @1)
 (lshift INTEGER_CST@1 @2))
(for mod (trunc_mod floor_mod)
 (simplify
  (mod @0 (convert?@3 (power_of_two_cand@1 @2)))
  (if ((TYPE_UNSIGNED (type)
|| tree_expr_nonnegative_p (@0))
&& tree_nop_conversion_p (type, TREE_TYPE (@3))
&& integer_pow2p (@2) && tree_int_cst_sgn (@2) > 0)
   (bit_and @0 (convert (minus @1 { build_int_cst (TREE_TYPE (@1), 1); 
}))

so it also checks whether @2 is not negative, the new pattern lacks
this and could make use of power_of_two_cand as well (in fact I'd
place it next to the pattern above.

Also the above applies for trunc_mod and floor_mod but the proposed
patch applies the transform for ceil_mod and round_mod as well.

Richard.

Re: [PATCH] c/86134 avoid errors for unrecognized -Wno- options

[Richard Biener]

On Fri, 14 Feb 2020, Joseph Myers wrote:

> On Fri, 14 Feb 2020, Richard Biener wrote:
> 
> > diff --git a/gcc/opts-global.c b/gcc/opts-global.c
> > index d5e308bf800..52ea083a6d5 100644
> > --- a/gcc/opts-global.c
> > +++ b/gcc/opts-global.c
> > @@ -139,8 +139,10 @@ print_ignored_options (void)
> >const char *opt;
> >  
> >opt = ignored_options.pop ();
> > -  warning_at (UNKNOWN_LOCATION, 0,
> > - "unrecognized command-line option %qs", opt);
> > +  /* Use inform, not warning_at, to avoid promoting these to errors.  
> > */
> > +  inform (UNKNOWN_LOCATION,
> > + "unrecognized command-line option %qs may have silenced "
> > + "earlier diagnostics", opt);
> 
> I agree with the principle of the patch, but I don't like the new message 
> text.  I don't think "may have silenced" is right; maybe something more 
> like "may have been intended to silence".

I've pushed the following variant then.

Thanks,
Richard.

>From b0215b75a41ffdddb8a5fd5bcc16dcc455e69006 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Fri, 14 Feb 2020 10:25:11 +0100
Subject: [PATCH] c/86134 avoid errors for unrecognized -Wno- options

This makes sure to not promote diagnostics about unrecognized -Wno-
options to errors and make the intent of the diagnostic clearer.

2020-02-17  Richard Biener  

PR c/86134
* opts-global.c (print_ignored_options): Use inform and
amend message.

* gcc.dg/pr86134.c: New testcase.
* gcc.dg/pr28322-2.c: Adjust.

diff --git a/gcc/opts-global.c b/gcc/opts-global.c
index d5e308bf800..c658805470e 100644
--- a/gcc/opts-global.c
+++ b/gcc/opts-global.c
@@ -139,8 +139,10 @@ print_ignored_options (void)
   const char *opt;
 
   opt = ignored_options.pop ();
-  warning_at (UNKNOWN_LOCATION, 0,
- "unrecognized command-line option %qs", opt);
+  /* Use inform, not warning_at, to avoid promoting these to errors.  */
+  inform (UNKNOWN_LOCATION,
+ "unrecognized command-line option %qs may have been intended "
+ "to silence earlier diagnostics", opt);
 }
 }
 
diff --git a/gcc/testsuite/gcc.dg/pr28322-2.c b/gcc/testsuite/gcc.dg/pr28322-2.c
index c9e5e228a7b..20adf5e92b8 100644
--- a/gcc/testsuite/gcc.dg/pr28322-2.c
+++ b/gcc/testsuite/gcc.dg/pr28322-2.c
@@ -8,5 +8,5 @@ int foo (void)
   return i;
 }
 
-/* { dg-warning "unrecognized command-line option .-Wno-foobar." "" { target 
*-*-* } 0 } */
+/* { dg-message "unrecognized command-line option .-Wno-foobar." "" { target 
*-*-* } 0 } */
 
diff --git a/gcc/testsuite/gcc.dg/pr86134.c b/gcc/testsuite/gcc.dg/pr86134.c
new file mode 100644
index 000..3fd21a32306
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr86134.c
@@ -0,0 +1,6 @@
+/* { dg-do compile } */
+/* { dg-options "-Wall -Werror -Wno-error=main -Wno-foobar" } */
+
+void main() {} /* { dg-warning "return type" } */
+
+/* { dg-message "unrecognized command-line option" "" { target *-*-* } 0 } */

RE: [PATCH] Fix bug in recursiveness check for function to be cloned (ipa/pr93707)

[Tamar Christina]

Hi Feng,

Thanks! The patch seems to work.

Hopefully it gets reviewed soon so we can fix the two benchmarks 😊

Thanks,
Tamar

> -Original Message-
> From: Feng Xue OS 
> Sent: Thursday, February 13, 2020 05:40
> To: Tamar Christina ; Martin Jambor
> ; Jan Hubicka ; gcc-
> patc...@gcc.gnu.org
> Cc: nd 
> Subject: [PATCH] Fix bug in recursiveness check for function to be cloned
> (ipa/pr93707)
> 
> I've submitted a bug tracker,
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93707.
> 
> The root cause is that for a self-recursive function, a for-all-contexts clone
> could generate an edge whose callee is not the function. Therefore, to check
> whether an edge stands for a recursive call during cloning, we should not use
> ordinary way of comparing caller and callee of the edge.
> 
> Bootstrapped/regtested on x86_64-linux and aarch64-linux, and also tested
> Spec 2017 with option "--param ipa-cp-eval-threshold=1".
> 
> Feng
> ---
> 2020-02-13  Feng Xue  
> 
> PR ipa/93707
> * ipa-cp.c (self_recursive_pass_through_p): Add a new parameter
> "node",
> and check recursiveness by comparing "node" and cs->caller.
> (self_recursive_agg_pass_through_p): Likewise.
> (find_more_scalar_values_for_callers_subset): Add "node" argument to
> self_recursive_pass_through_p call.
> (intersect_aggregates_with_edge): Add a new parameter "node", and
> add
> "node" argument to self_cursive_agg_pass_through_p call.
> (find_aggregate_values_for_callers_subset): Add "node" argument to
> self_recursive_pass_through_p and intersect_aggregates_with_edge
> calls.
> (cgraph_edge_brings_all_agg_vals_for_node): Add "node" argument to
> intersect_aggregates_with_edge call.
> 
> > 
> > From: gcc-patches-ow...@gcc.gnu.org 
> on
> > behalf of Tamar Christina 
> > Sent: Tuesday, February 11, 2020 6:05 PM
> > To: Feng Xue OS; Martin Jambor; Jan Hubicka; gcc-patches@gcc.gnu.org
> > Cc: nd
> > Subject: RE: [PATCH V2] Generalized value pass-through for
> > self-recursive function (ipa/pr93203)
> >
> > Hi Feng,
> >
> > This patch (commit a0f6a8cb414b687f22c9011a894d5e8e398c4be0) is
> > causing ICEs in the GCC and perlbench benchmark in Spec2017.
> >
> > during IPA pass: cp
> > lto1: internal compiler error: in
> > find_more_scalar_values_for_callers_subset,
> > at ipa-cp.c:4709
> > 0x1698187 find_more_scalar_values_for_callers_subset
> > ../.././gcc/ipa-cp.c:4709
> > 0x169f7d3 decide_about_value
> > ../.././gcc/ipa-cp.c:5490
> > 0x169fdc3 decide_whether_version_node
> > ../.././gcc/ipa-cp.c:5537
> > 0x169fdc3 ipcp_decision_stage
> > ../.././gcc/ipa-cp.c:5718
> > 0x169fdc3 ipcp_driver
> > ../.././gcc/ipa-cp.c:5901
> > Please submit a full bug report,
> >
> > Thanks,
> > Tamar
> >

Re: [PR47785] COLLECT_AS_OPTIONS

[Prathamesh Kulkarni]

On Thu, 6 Feb 2020 at 20:03, Prathamesh Kulkarni
 wrote:
>
> On Thu, 6 Feb 2020 at 18:42, Richard Biener  
> wrote:
> >
> > On Thu, Feb 6, 2020 at 1:48 PM Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Tue, 4 Feb 2020 at 19:44, Richard Biener  
> > > wrote:
> > > >
> > > > On Mon, Feb 3, 2020 at 12:37 PM Prathamesh Kulkarni
> > > >  wrote:
> > > > >
> > > > > On Thu, 30 Jan 2020 at 19:10, Richard Biener 
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, 28 Jan 2020 at 17:17, Richard Biener 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Mon, 20 Jan 2020 at 15:44, Richard Biener 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Jan 8, 2020 at 11:20 AM Prathamesh Kulkarni
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 5 Nov 2019 at 17:38, Richard Biener 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, 5 Nov 2019 at 03:57, H.J. Lu 
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sun, Nov 3, 2019 at 6:45 PM Kugan 
> > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks for the reviews.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Sat, 2 Nov 2019 at 02:49, H.J. Lu 
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:33 PM Kugan 
> > > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, 30 Oct 2019 at 03:11, H.J. Lu 
> > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Sun, Oct 27, 2019 at 6:33 PM Kugan 
> > > > > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, 23 Oct 2019 at 23:07, Richard 
> > > > > > > > > > > > > > > > > > > Biener  wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Mon, Oct 21, 2019 at 10:04 AM Kugan 
> > > > > > > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks for the pointers.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, 11 Oct 2019 at 22:33, Richard 
> > > > > > > > > > > > > > > > > > > > > Biener  
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 11, 2019 at 6:15 AM 
> > > > > > > > > > > > > > > > > > > > > > Kugan Vivekanandarajah
> > > > > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Wed, 2 Oct 2019 at 20:41, 
> > > > > > > > > > > > > > > > > > > > > > > Richard Biener 
> > > > > > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 2, 2019 at 10:39 AM 
> > > > > > > > > > > > > > > > > > > > > > > > Kugan Vivekanandarajah
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > As mentioned in the PR, 
> > > > > > > > > > > > > > > > > > > > > > > > > attached patch adds 
> > > > > > > > > > > > > > > > > > > > > > > > > COLLECT_AS_OPTIONS for
> > > > > > > > > > > > > > > > > 

Re: gcov: reduce code quality loss by reproducible topn merging [PR92924]

[Martin Liška]

On 2/13/20 2:35 PM, Jan Hubicka wrote:

Otherwise the patch is OK and thanks for working on this!
Honza


Hello.

There's updated version of the patch that comes with the
new option name.

If there's no comment I'm going to install it tomorrow.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Thanks,
Martin

>From c1d19157c6683e2b28abc93bc3bedd4771bdb9a5 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 5 Feb 2020 14:44:43 +0100
Subject: [PATCH] Introduce -fprofile-reproducibility and support it with TOP
 N.

gcc/ChangeLog:

2020-02-05  Martin Liska  

	PR ipa/92924
	* common.opt: Add -fprofile-reproducibility.
	* doc/invoke.texi: Document it.
	* value-prof.c (dump_histogram_value):
	Document and support behavior for counters[0]
	being a negative value.
	(get_nth_most_common_value): Handle negative
	counters[0] in respect to flag_profile_reproducible.

libgcc/ChangeLog:

2020-02-05  Martin Liska  

	PR ipa/92924
	* libgcov-merge.c (merge_topn_values_set): Record
	when a TOP N counter becomes invalid.  When merging
	remove a smallest value if the space is needed.
---
 gcc/common.opt | 16 ++
 gcc/coretypes.h|  7 ++
 gcc/doc/invoke.texi| 31 +-
 gcc/value-prof.c   | 29 ++--
 libgcc/libgcov-merge.c | 50 +-
 5 files changed, 110 insertions(+), 23 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 5692cd04374..fa9da505fc2 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2168,6 +2168,22 @@ fprofile-exclude-files=
 Common Joined RejectNegative Var(flag_profile_exclude_files)
 Instrument only functions from files where names do not match all the regular expressions (separated by a semi-colon).
 
+Enum
+Name(profile_reproducibility) Type(enum profile_reproducibility) UnknownError(unknown profile reproducibility method %qs)
+
+EnumValue
+Enum(profile_reproducibility) String(serial) Value(PROFILE_REPRODUCIBILITY_SERIAL)
+
+EnumValue
+Enum(profile_reproducibility) String(parallel-runs) Value(PROFILE_REPRODUCIBILITY_PARALLEL_RUNS)
+
+EnumValue
+Enum(profile_reproducibility) String(multithreaded) Value(PROFILE_REPRODUCIBILITY_MULTITHREADED)
+
+fprofile-reproducible
+Common Joined RejectNegative Var(flag_profile_reproducible) Enum(profile_reproducibility) Init(PROFILE_REPRODUCIBILITY_SERIAL)
+-fprofile-reproducible=[serial|parallel-runs|multithreaded] Control level of reproducibility of profile gathered by -fprofile-generate.
+
 Enum
 Name(profile_update) Type(enum profile_update) UnknownError(unknown profile update method %qs)
 
diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index d8fd50d79a4..cda22697cc3 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -212,6 +212,13 @@ enum profile_update {
   PROFILE_UPDATE_PREFER_ATOMIC
 };
 
+/* Type of profile reproducibility methods.  */
+enum profile_reproducibility {
+PROFILE_REPRODUCIBILITY_SERIAL,
+PROFILE_REPRODUCIBILITY_PARALLEL_RUNS,
+PROFILE_REPRODUCIBILITY_MULTITHREADED
+};
+
 /* Types of unwind/exception handling info that can be generated.  */
 
 enum unwind_info_type
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3e47d06f0d5..ba2b7e42520 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -562,7 +562,7 @@ Objective-C and Objective-C++ Dialects}.
 -fprofile-abs-path @gol
 -fprofile-dir=@var{path}  -fprofile-generate  -fprofile-generate=@var{path} @gol
 -fprofile-note=@var{path}  -fprofile-update=@var{method} @gol
--fprofile-filter-files=@var{regex}  -fprofile-exclude-files=@var{regex} @gol
+-fprofile-filter-files=@var{regex}  -fprofile-exclude-files=@var{regex} -fprofile-reproducibility @gol
 -fsanitize=@var{style}  -fsanitize-recover  -fsanitize-recover=@var{style} @gol
 -fasan-shadow-offset=@var{number}  -fsanitize-sections=@var{s1},@var{s2},... @gol
 -fsanitize-undefined-trap-on-error  -fbounds-check @gol
@@ -13360,6 +13360,35 @@ all the regular expressions (separated by a semi-colon).
 For example, @option{-fprofile-exclude-files=/usr/*} will prevent instrumentation
 of all files that are located in @file{/usr/} folder.
 
+@item -fprofile-reproducible
+@opindex fprofile-reproducible
+Control level of reproducibility of profile gathered by
+@code{-fprofile-generate}.  This makes it possible to rebuild program
+with same outcome which is useful, for example, for distribution
+packages.
+
+With @option{-fprofile-reproducibility=serial} the profile gathered by
+@option{-fprofile-generate} is reproducible provided the trained program
+behaves the same at each invocation of the train run, it is not
+multi-threaded and profile data streaming is always done in the same
+order.  Note that profile streaming happens at the end of program run but
+also before @code{fork} function is invoked.
+
+Note that it is quite common that execution counts of some part of
+programs depends, for example, on length of temporary file names or
+memory space randomization (that may aff

Re: [PATCH 2/4] Use const for some function arguments.

[Martin Liška]

On 2/7/20 6:21 PM, Segher Boessenkool wrote:

On Tue, Feb 04, 2020 at 02:55:14PM +0100, Martin Liska wrote:


gcc/ChangeLog:

2020-02-04  Martin Liska  

PR c/92472.


That trailing dot should not be there (in some other patches as well).


Sure. I'll fix it.

@Richi: May I install the patch once stage1 opens, or will it require
another review?

Martin




Segher

Re: [PATCH 2/4] Use const for some function arguments.

[Richard Biener]

On Mon, Feb 17, 2020 at 11:05 AM Martin Liška  wrote:
>
> On 2/7/20 6:21 PM, Segher Boessenkool wrote:
> > On Tue, Feb 04, 2020 at 02:55:14PM +0100, Martin Liska wrote:
> >>
> >> gcc/ChangeLog:
> >>
> >> 2020-02-04  Martin Liska  
> >>
> >>  PR c/92472.
> >
> > That trailing dot should not be there (in some other patches as well).
>
> Sure. I'll fix it.
>
> @Richi: May I install the patch once stage1 opens, or will it require
> another review?

Yes, OK for stage1.

> Martin
>
> >
> >
> > Segher
> >
>

Re: [PATCH] issues with configure --enable-checking option

[Roman Zhuykov]

Ping.  Proposed patch is docs-only (install.texi), and IMHO it's better
to push it into 8.4 and 9.3.

11.02.2020 17:46, Roman Zhuykov wrote:
> 07.02.2020 20:20, Richard Sandiford writes:
>> Roman Zhuykov  writes:
>>> Hi!
>>> I've investigated a bit, because some of the following confused me while 
>>> working with some local 9.2-based branch.
>>>
>>> Documentation issues:
>>> (0) See patch for install.texi at the bottom, two possible values are 
>>> not documented. Ok for master? Backports?
>>> (1) For me it seems confusing to have 'tree' and 'gimple' values, but 
>>> not sure how to solve this.
>>> (2) Developer has to look into configure scripts to understand which 
>>> macro will be defined. E.q. 'misc' means "CHECKING_P".
>>> (3) Install.texi IMHO doesn't properly describe what happens when 
>>> --enable-checking is used without "=list". Maybe we should explicitly 
>>> tell this means same as "=yes".
>>> (4) Statement "This is ‘yes,extra’ by default when building from the 
>>> source repository or snapshots." is wrong, because 'snapshots' may 
>>> relate to released branches (e.q. GCC 9-20200125 Snapshot), and 
>>> gcc/DEV-PHASE is empty there.
>>> (5) Statement "‘extra’ adds for ‘misc’ checking extra checks ..." is 
>>> also confusing, one can run 'configure --enable-checking=extra' and will 
>>> have only ENABLE_EXTRA_CHECKING, but not CHECKING_P, and in common.opt 
>>> flag_checking will have Init(0).
>>>
>>> Behavior issues:
>>> (6) It is not obvious to have default --enable-checking=release on any 
>>> commit in releases/* branches (DEV-PHASE is empty there). IMHO it's 
>>> enough 'experimental' when picking for example some commit between 9.1 
>>> and 9.2. This also can confuse 'git bisect run' scenario when good 
>>> revision is old enough and bad revision is on release branch. See also (4).
>>> (7) Running "configure --enable-checking" means less (!) checks on 
>>> master branch (where DEV-PHASE is experimental). Default is "yes+extra" 
>>> and you get only "yes" with that option.
>>> (8) Why we always start with "release" values ('assert'+'runtime') as 
>>> default? If developer runs "configure --enable-checking=df,rtl,tree" 
>>> probably it should mean only picked values are enabled. Why we silently 
>>> add 'assert' and 'runtime' into that set?
>>>
>>> I haven't tried to find additional issues with related 
>>> '--enable-stage1-checking' option.
>>>
>>> Roman
>>>
>>> PS. I see some lines have more than 80 chars in install.texi, few of 
>>> them were added recently while cleaning references to SVN. Patch fixes 
>>> this only forthe paragraph it touches.
>>> --
>>>
>>> gcc/ChangeLog:
>>>
>>> 2020-01-29  Roman Zhuykov 
>>>
>>>      * doc/install.texi: Document 'types' and 'gimple' values for
>>>      '--enable-checking' configure option.
>>>
>>> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>>> --- a/gcc/doc/install.texi
>>> +++ b/gcc/doc/install.texi
>>> @@ -1845,19 +1845,19 @@ consistency checks of the requested complexity.  
>>> This does not change the
>>>   generated code, but adds error checking within the compiler.  This will
>>>   slow down the compiler and may only work properly if you are building
>>>   the compiler with GCC@.  This is @samp{yes,extra} by default when building
>>> -from the source repository or snapshots, but @samp{release} for 
>>> releases.  The default
>>> -for building the stage1 compiler is @samp{yes}.  More control
>>> +from the source repository or snapshots, but @samp{release} for releases.
>>> +The default for building the stage1 compiler is @samp{yes}.  More control
>> Pre-existing problem, but: it looks like the current default is yes,types:
>>
>> [if test "x$enable_checking" = xno || test "x$enable_checking" = x; then
>>   # For --disable-checking or implicit --enable-checking=release, avoid
>>   # setting --enable-checking=gc in the default stage1 checking for LTO
>>   # bootstraps.  See PR62077.
>>   case $BUILD_CONFIG in
>> *lto*)
>>   
>> stage1_checking=--enable-checking=release,misc,gimple,rtlflag,tree,types;;
>> *)
>>   stage1_checking=--enable-checking=yes,types;;
>>   esac
>>   if test "x$enable_checking" = x && \
>>  test -d ${srcdir}/gcc && \
>>  test x"`cat ${srcdir}/gcc/DEV-PHASE`" = xexperimental; then
>> stage1_checking=--enable-checking=yes,types,extra
>>   fi
>> else
>>   stage1_checking=--enable-checking=$enable_checking,types
>> fi])
>>
>> Could you fix that while you're there?
> No change needed, documentation is correct here, that global
> configure.ac yes+types change was r126951 and a bit later in r133479 we
> have 'types' included into 'yes' set in gcc/configure.ac. In patch v1
> I've already included 'types' into 'yes' set description few lines below.
>
> I hope somebody will have a look at those behavior issues (6), (7), (8),
> probably on stage1 later. So, lets add
> (9) Remove unneeded 'types' item in stage1_checking in global configure.ac.
>
>>>   over the checks may be had by specifying @

[Regression, patch][Fortran] ICE in gfc_conv_constant_to_tree PR93604

[Mark Eggleston]

Please find attached patch for PR93604.

gcc/fortran/ChangeLog

    Steven G. Kargl  

    PR fortran/93604
    * decl.c (gfc_match_data) : Check whether the data expression
    is a derived type and is a constructor. If a BOZ constant
    is encountered in the constructor output an error and return
    MATCH_ERROR.

gcc/testsuite/ChangeLog

    Mark Eggleston  

    PR fortran/93604
    * gfortran.dg/pr93604.f90 : New test.

OK to commit?

--
https://www.codethink.co.uk/privacy.html

>From b4bd5742d842c860da5b35955301e3c1a1e06160 Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Thu, 6 Feb 2020 13:42:33 +
Subject: [PATCH] [Fortran] ICE in gfc_conv_constant_to_tree PR93604

Using a BOZ constant in a structure constructor in a data statement
resulted in an ICE. Output a "BOZ literal constant cannot appear in
a structure constructor" error message instead.

Original patch provided by Steven G. Kargl  .

Test case added later.

gcc/fortran/ChangeLog

	* decl.c (gfc_match_data) : Check whether the data expression
	is a derived type and is a constructor. If a BOZ constant
	is encountered in the constructor output an error and return
	MATCH_ERROR.

gcc/testsuite/ChangeLog

	* gfortran.dg/pr93604.f90 : New test.
---
 gcc/fortran/decl.c| 16 
 gcc/testsuite/gfortran.dg/pr93604.f90 | 10 ++
 2 files changed, 26 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr93604.f90

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 499d2429aba..7382fea03e4 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -716,6 +716,22 @@ gfc_match_data (void)
   new_data->next = gfc_current_ns->data;
   gfc_current_ns->data = new_data;
 
+  /* A BOZ literal constant cannot appear in a structure constructor.
+	 Check for that here for a data statement value.  */
+  if (new_data->value->expr->ts.type == BT_DERIVED
+	  && new_data->value->expr->value.constructor)
+	{
+	  gfc_constructor *c;
+	  c = gfc_constructor_first (new_data->value->expr->value.constructor);
+	  for (; c; c = gfc_constructor_next (c))
+	if (c->expr->ts.type == BT_BOZ)
+	  {
+		gfc_error ("BOZ literal constant at %L cannot appear in a "
+			   "structure constructor", &c->expr->where);
+		return MATCH_ERROR;
+	  }
+	}
+
   if (gfc_match_eos () == MATCH_YES)
 	break;
 
diff --git a/gcc/testsuite/gfortran.dg/pr93604.f90 b/gcc/testsuite/gfortran.dg/pr93604.f90
new file mode 100644
index 000..2c695d37829
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93604.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+
+program p
+   type t
+  integer :: a
+   end type
+   type(t) :: x
+   data x /t(z'1')/ ! { dg-error "cannot appear in a structure constructor" }
+end
+
-- 
2.11.0

Re: [PATCH] Fix PR66552, Missed optimization when shift amount is result of signed modulus

[Jiufu Guo]

Li Jia He  writes:

> Hi,
> @@ -546,6 +546,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>   (simplify
>(mod (mod@2 @0 @1) @1)
>@2)
> + /* Optimize (x shift (n mod C)) to (x shift (n bit_and (C - 1))) when C is a
> +constant and power of two.  */
> + (for shift (lshift rshift)
> +  (simplify
> +   (shift @0 (mod @1 integer_pow2p@2))
> +   (shift @0 (bit_and @1 (minus @2 { build_int_cst (TREE_TYPE (@2), 1); 
> })
>   /* From extract_muldiv_1: (X * C1) % C2 is zero if C1 is a multiple of C2.  
> */
>   (simplify
>(mod (mult @0 INTEGER_CST@1) INTEGER_CST@2)
> +unsigned a(unsigned x, int n)
> +{
> +  return x >> (n % 32);
> +}
> +

With this patch, the behavior will change on negtive @2. While this
would not be an issue because it is UB.

In below foo, r and r1 are not same after patch.
-
int __attribute__ ((noinline))
foo (unsigned x, int n, int t)
{
  int r = x >> (n % 4);
  int r1 = x >> t;
  __builtin_printf ("%d : %d\n", r, r1);  
  return r == r1;
}

int main()
{
  unsigned x = 0x12c;
  int n = -3;
  return foo (x, n, n %4);
}
-
For: "x=0x12c, n=-3; x >> (n % 4)"  without patch, it is 0; with patch
it is 0x96.

[PATCH] Drop MALLOC attribute for void functions.

[Martin Liška]

Hello.

As mentioned in the PR, we end up with a void function
call that has set MALLOC attribute. That causes problems in RTL
expansion.

I believe a proper fix is to drop the attribute when a callgraph
clone with void type is created.

I would like to see Martin's comment about the hunk in propagate_malloc
which is maybe suboptimal and one can find a better way?

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
It fixes LTO bootstrap on ppc64le.

Thanks,
Martin

gcc/ChangeLog:

2020-02-17  Martin Liska  

PR ipa/93583
* cgraph.c (cgraph_node::verify_node): Verify MALLOC attribute
and return type of functions.
* ipa-param-manipulation.c (ipa_param_adjustments::adjust_decl):
Drop MALLOC attribute for void functions.
* ipa-pure-const.c (propagate_malloc): Do not set malloc flag
for void functions.

gcc/testsuite/ChangeLog:

2020-02-17  Martin Liska  

PR ipa/93583
* gcc.dg/ipa/pr93583.c: New test.
---
 gcc/cgraph.c   |  6 ++
 gcc/ipa-param-manipulation.c   |  4 
 gcc/ipa-pure-const.c   |  9 ++---
 gcc/testsuite/gcc.dg/ipa/pr93583.c | 15 +++
 4 files changed, 31 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93583.c


diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 294b2d392fd..6e99fbb45f4 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3374,6 +3374,12 @@ cgraph_node::verify_node (void)
   error ("calls_comdat_local is set outside of a comdat group");
   error_found = true;
 }
+  if (DECL_IS_MALLOC (decl)
+  && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (decl
+{
+  error ("MALLOC attribute set on a void function");
+  error_found = true;
+}
   for (e = indirect_calls; e; e = e->next_callee)
 {
   if (e->aux)
diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
index 19ec87358fa..5f6f0575b06 100644
--- a/gcc/ipa-param-manipulation.c
+++ b/gcc/ipa-param-manipulation.c
@@ -410,6 +410,10 @@ ipa_param_adjustments::adjust_decl (tree orig_decl)
   DECL_VIRTUAL_P (new_decl) = 0;
   DECL_LANG_SPECIFIC (new_decl) = NULL;
 
+  /* Drop MALLOC attribute for a void function.  */
+  if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (new_decl
+DECL_IS_MALLOC (new_decl) = 0;
+
   return new_decl;
 }
 
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index ccd0918c120..315134d2a94 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1973,9 +1973,12 @@ propagate_malloc (void)
 		   node->dump_name ());
 
 	bool malloc_decl_p = DECL_IS_MALLOC (node->decl);
-	node->set_malloc_flag (true);
-	if (!malloc_decl_p && warn_suggest_attribute_malloc)
-		warn_function_malloc (node->decl);
+	if (!VOID_TYPE_P (TREE_TYPE (TREE_TYPE (node->decl
+	  {
+		node->set_malloc_flag (true);
+		if (!malloc_decl_p && warn_suggest_attribute_malloc)
+		  warn_function_malloc (node->decl);
+	  }
 	  }
   }
 
diff --git a/gcc/testsuite/gcc.dg/ipa/pr93583.c b/gcc/testsuite/gcc.dg/ipa/pr93583.c
new file mode 100644
index 000..30ef506553d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr93583.c
@@ -0,0 +1,15 @@
+/* PR ipa/93583 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+void *bar(const char*);
+static void *__attribute__((malloc,noinline)) foo(const char *p)
+{
+  return bar (p);
+}
+
+int main(int argc, char **argv)
+{
+  foo (argv[0]);
+  return 0;
+}

[PATCH][OBVIOUS] Fix a typo.

[Martin Liška]

Hi.

One obvious typo fix.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Thanks,
Martin

gcc/ChangeLog:

2020-02-17  Martin Liska  

PR other/93756
* config/rx/elf.opt: Fix typo.

libphobos/ChangeLog:

2020-02-17  Martin Liska  

PR other/93756
* src/std/algorithm/iteration.d: Fix typo.
---
 gcc/config/rx/elf.opt   | 2 +-
 libphobos/src/std/algorithm/iteration.d | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/gcc/config/rx/elf.opt b/gcc/config/rx/elf.opt
index d65c1ee94c4..f130e799680 100644
--- a/gcc/config/rx/elf.opt
+++ b/gcc/config/rx/elf.opt
@@ -29,7 +29,7 @@ Use the simulator runtime.
 
 mas100-syntax
 Target Mask(AS100_SYNTAX) Report
-Generate assembler output that is compatible with the Renesas AS100 assembler.  This may restrict some of the compiler's capabilities.  The default is to generate GAS compatable syntax.
+Generate assembler output that is compatible with the Renesas AS100 assembler.  This may restrict some of the compiler's capabilities.  The default is to generate GAS compatible syntax.
 
 ;---
 
diff --git a/libphobos/src/std/algorithm/iteration.d b/libphobos/src/std/algorithm/iteration.d
index 7e5782406d1..93cf1e7cfb3 100644
--- a/libphobos/src/std/algorithm/iteration.d
+++ b/libphobos/src/std/algorithm/iteration.d
@@ -3151,7 +3151,7 @@ The number of seeds must be correspondingly increased.
 static assert(!is(typeof(reduce!(min, max)(tuple(c), "hello";
 //"Seed (dchar, dchar, dchar) does not have the correct amount of fields (should be 2)"
 static assert(!is(typeof(reduce!(min, max)(tuple(c, c, c), "hello";
-//"Incompatable function/seed/element: all(alias pred = "a")/int/dchar"
+//"Incompatible function/seed/element: all(alias pred = "a")/int/dchar"
 static assert(!is(typeof(reduce!all(1, "hello";
 static assert(!is(typeof(reduce!(all, all)(tuple(1, 1), "hello";
 }

[PATCH][OBVIOUS] Fix double quoting.

[Martin Liška]

Hi.

The fix is about removal of redundant quotes.

Thanks,
Martin

gcc/ChangeLog:

2020-02-17  Martin Liska  

PR translation/93755
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Fix double quotes.
---
 gcc/config/rs6000/rs6000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 4c1c0e93a9b..f34e1ba70c6 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -3968,7 +3968,7 @@ rs6000_option_override_internal (bool global_init_p)
   if (!TARGET_VSX)
 	{
 	  if ((rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128_KEYWORD) != 0)
-	error ("%qs requires VSX support", "%<-mfloat128%>");
+	error ("%qs requires VSX support", "-mfloat128");
 
 	  TARGET_FLOAT128_TYPE = 0;
 	  rs6000_isa_flags &= ~(OPTION_MASK_FLOAT128_KEYWORD

[PATCH][OBVIOUS] Fix grammar in error message.

[Martin Liška]

Hi.

One obvious fix suggested by Andrew P.

Martin

gcc/ChangeLog:

2020-02-17  Martin Liska  

PR ipa/93760
* ipa-devirt.c (odr_types_equivalent_p): Fix grammar.

gcc/testsuite/ChangeLog:

2020-02-17  Martin Liska  

PR ipa/93760
* g++.dg/lto/odr-8_1.C: Fix grammar.
---
 gcc/ipa-devirt.c   | 2 +-
 gcc/testsuite/g++.dg/lto/odr-8_1.C | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index b04cae704f9..bd9f3441773 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1548,7 +1548,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool *warned,
   && COMPLETE_TYPE_P (t1) && COMPLETE_TYPE_P (t2))
 {
   warn_odr (t1, t2, NULL, NULL, warn, warned,
-		G_("one type needs to be constructed while other not"));
+		G_("one type needs to be constructed while the other does not"));
   gcc_checking_assert (RECORD_OR_UNION_TYPE_P (t1));
   return false;
 }
diff --git a/gcc/testsuite/g++.dg/lto/odr-8_1.C b/gcc/testsuite/g++.dg/lto/odr-8_1.C
index cbcd15d76ad..501dbbdd1b2 100644
--- a/gcc/testsuite/g++.dg/lto/odr-8_1.C
+++ b/gcc/testsuite/g++.dg/lto/odr-8_1.C
@@ -1,4 +1,4 @@
-struct a {char c; a() {} a(struct a &) {}}; // { dg-lto-message "one type needs to be constructed while other not" }
+struct a {char c; a() {} a(struct a &) {}}; // { dg-lto-message "one type needs to be constructed while the other does not" }
 extern int test (struct a *a);
 int
 main()

Re: [PATCH] Drop MALLOC attribute for void functions.

[Martin Jambor]

Hi,

On Mon, Feb 17 2020, Martin Liška wrote:
> Hello.
>
> As mentioned in the PR, we end up with a void function
> call that has set MALLOC attribute. That causes problems in RTL
> expansion.
>
> I believe a proper fix is to drop the attribute when a callgraph
> clone with void type is created.
>
> I would like to see Martin's comment about the hunk in propagate_malloc
> which is maybe suboptimal and one can find a better way?
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> It fixes LTO bootstrap on ppc64le.
>

It looks sensible to me.  I did not quite took into consideration that
ipa-pure-const can add the attribute and only dropped in tree-inline's
tree_function_versioning.  Just the hunk in
ipa_param_adjustments::adjust_decl could be simplified a tiny bit...

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-02-17  Martin Liska  
>
>   PR ipa/93583
>   * cgraph.c (cgraph_node::verify_node): Verify MALLOC attribute
>   and return type of functions.
>   * ipa-param-manipulation.c (ipa_param_adjustments::adjust_decl):
>   Drop MALLOC attribute for void functions.
>   * ipa-pure-const.c (propagate_malloc): Do not set malloc flag
>   for void functions.
>
> gcc/testsuite/ChangeLog:
>
> 2020-02-17  Martin Liska  
>
>   PR ipa/93583
>   * gcc.dg/ipa/pr93583.c: New test.
> ---
>   gcc/cgraph.c   |  6 ++
>   gcc/ipa-param-manipulation.c   |  4 
>   gcc/ipa-pure-const.c   |  9 ++---
>   gcc/testsuite/gcc.dg/ipa/pr93583.c | 15 +++
>   4 files changed, 31 insertions(+), 3 deletions(-)
>   create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93583.c
>

[...]

> diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
> index 19ec87358fa..5f6f0575b06 100644
> --- a/gcc/ipa-param-manipulation.c
> +++ b/gcc/ipa-param-manipulation.c
> @@ -410,6 +410,10 @@ ipa_param_adjustments::adjust_decl (tree orig_decl)
>DECL_VIRTUAL_P (new_decl) = 0;
>DECL_LANG_SPECIFIC (new_decl) = NULL;
>  
> +  /* Drop MALLOC attribute for a void function.  */
> +  if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (new_decl
> +DECL_IS_MALLOC (new_decl) = 0;

by just testing m_skip_return here (but it is no big deal).

Thanks!

Martin

Re: [PATCH] c++: Fix poor diagnostic for array initializer [PR93710]

[Christophe Lyon]

On Wed, 12 Feb 2020 at 21:06, Marek Polacek  wrote:
>
> A small improvement for an error in build_user_type_conversion_1:
> instead of
>
> array-init1.C:11:1: error: conversion from ‘long int’ to ‘A’ is ambiguous
>11 | };
>   | ^
>
> we will print
>
> array-init1.C:8:3: error: conversion from ‘long int’ to ‘A’ is ambiguous
> 8 |   0L,
>   |   ^~
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2020-02-12  Marek Polacek  
>
> PR c++/93710 - poor diagnostic for array initializer.
> * call.c (build_user_type_conversion_1): Use cp_expr_loc_or_input_loc
> for an error call.
>
> * g++.dg/diagnostic/array-init1.C: New test.
> ---
>  gcc/cp/call.c |  5 +++--
>  gcc/testsuite/g++.dg/diagnostic/array-init1.C | 11 +++
>  2 files changed, 14 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/diagnostic/array-init1.C
>
> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index 51621b7dd87..f47f96bf1c2 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -4172,8 +4172,9 @@ build_user_type_conversion_1 (tree totype, tree expr, 
> int flags,
>if (complain & tf_error)
> {
>   auto_diagnostic_group d;
> - error ("conversion from %qH to %qI is ambiguous",
> -fromtype, totype);
> + error_at (cp_expr_loc_or_input_loc (expr),
> +   "conversion from %qH to %qI is ambiguous",
> +   fromtype, totype);
>   print_z_candidates (location_of (expr), candidates);
> }
>
> diff --git a/gcc/testsuite/g++.dg/diagnostic/array-init1.C 
> b/gcc/testsuite/g++.dg/diagnostic/array-init1.C
> new file mode 100644
> index 000..78580ad6b83
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/diagnostic/array-init1.C
> @@ -0,0 +1,11 @@
> +// PR c++/93710 - poor diagnostic for array initializer.
> +
> +struct A { A (int); A (char*); int i; };
> +
> +int x;
> +
> +A a1[] = {
> +  0L, // { dg-error "3:conversion from .long int. to .A. is ambiguous" }
> +  &x, // { dg-error "3:invalid conversion from .int\\*. to .int." }
> +  __builtin_offsetof (A, i) // { dg-error "23:conversion from .long unsigned 
> int. to .A. is ambiguous" }

Hi,

This test fails on arm (and i586 according to gcc-testresults:
/gcc/testsuite/g++.dg/diagnostic/array-init1.C:10:23: error:
conversion from 'unsigned int' to 'A' is ambiguous

Note sure if you want to make the dg-error conditional or match '.*
unsigned int' ?

Christophe

> +};
>
> base-commit: 5bfc8303ffe2d86e938d45f13cd99a39469dac4f
> --
> Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
>

[PATCH] tree-optimization/93586 - bogus path-based disambiguation

[Richard Biener]

This fixes bogus path-based disambiguation of mismatched array shape
accesses.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Honza, is this the correct place to detect this or were we not
supposed to arrive there?

Thanks,
Richard.

2020-02-17  Richard Biener  

PR tree-optimization/93586
* tree-ssa-alias.c (nonoverlapping_array_refs_p): Fail when
we're obviously not looking at same-shaped array accesses.

* gcc.dg/torture/pr93586.c: New testcase.
---
 gcc/testsuite/gcc.dg/torture/pr93586.c | 21 +
 gcc/tree-ssa-alias.c   |  5 +
 2 files changed, 26 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr93586.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr93586.c 
b/gcc/testsuite/gcc.dg/torture/pr93586.c
new file mode 100644
index 000..e861bdcd78e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr93586.c
@@ -0,0 +1,21 @@
+/* { dg-do run } */
+/* { dg-additional-options "-fgimple" } */
+
+int __GIMPLE(ssa) foo(int j)
+{
+  int c[1][10][1];
+  int _1;
+
+__BB(2):
+  c[0][1][0] = 1;
+  c[0][1] = _Literal (int[1]) {};
+  _1 = c[0][j_2(D)][0];
+  return _1;
+}
+
+int main()
+{
+  if (foo (1) != 0)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index b8df66ac1f2..e7caf9bee77 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -1291,6 +1291,11 @@ nonoverlapping_array_refs_p (tree ref1, tree ref2)
 
   tree elmt_type1 = TREE_TYPE (TREE_TYPE (TREE_OPERAND (ref1, 0)));
   tree elmt_type2 = TREE_TYPE (TREE_TYPE (TREE_OPERAND (ref2, 0)));
+  /* If one element is an array but not the other there's an obvious
+ mismatch in dimensionality.  */
+  if ((TREE_CODE (elmt_type1) == ARRAY_TYPE)
+  != (TREE_CODE (elmt_type2) == ARRAY_TYPE))
+return -1;
 
   if (TREE_OPERAND (ref1, 3))
 {
-- 
2.16.4

[Regression, patch][Fortran] ICE in gfc_typenode_for_spec PR93603

[Mark Eggleston]

Please find attached fix for PR fortran/93603.

gcc/fortran/ChangeLog

    Steven G. Kargl  

    PR fortran/93603
    * match.c (gfc_match_associate) : If target expression
    has the type BT_BOZ output an error and goto
    assocListError.

gcc/testsuite/ChangeLog

    Mark Eggleston  

    PR fortran/93603
    * gfortran.dg/pr93603.f90 : New test.

Tested using make with check-fortran on master at:

https://gcc.gnu.org/g:f82617f229b336d856c18313339b14657e05c129

OK to commit?

--
https://www.codethink.co.uk/privacy.html

>From 42e66ff8910e995e6b8fb9bb597a09ec7be07def Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Fri, 7 Feb 2020 11:39:37 +
Subject: [PATCH] [Fortran] ICE in gfc_typenode_for_spec PR93603

Associating a symbol with a BOZ constant caused an ICE.  Output
an error message as an association target cannot be a BOZ
constant.

Original patch provided by Steven G. Kargl  .

gcc/fortran/ChangeLog

	PR fortran/93603
	* match.c (gfc_match_associate) : If target expression
	has the type BT_BOZ output an error and goto
	assocListError.

gcc/testsuite/ChangeLog

	PR fortran/93603
	* gfortran.dg/pr93603.f90 : New test.
---
 gcc/fortran/match.c   | 8 
 gcc/testsuite/gfortran.dg/pr93603.f90 | 7 +++
 2 files changed, 15 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr93603.f90

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index a74cb8c5c19..9c2ec41c49c 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -1957,6 +1957,14 @@ gfc_match_associate (void)
 	  goto assocListError;
 	}
 
+  /* The target expression cannot be a BOZ literal constant.  */
+  if (newAssoc->target->ts.type == BT_BOZ)
+	{
+	  gfc_error ("Association target at %L cannot be a BOZ literal "
+		 "constant", &newAssoc->target->where);
+	  goto assocListError;
+	}
+
   /* The `variable' field is left blank for now; because the target is not
 	 yet resolved, we can't use gfc_has_vector_subscript to determine it
 	 for now.  This is set during resolution.  */
diff --git a/gcc/testsuite/gfortran.dg/pr93603.f90 b/gcc/testsuite/gfortran.dg/pr93603.f90
new file mode 100644
index 000..fd452e52ca2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93603.f90
@@ -0,0 +1,7 @@
+! { dg-do compile }
+
+program p
+  associate (y => z'1') ! { dg-error "cannot be a BOZ literal constant" }
+  end associate ! { dg-error "Expecting END PROGRAM" }
+end
+
-- 
2.11.0

[committed] libstdc++: Implement "Safe Integral Comparisons" (P0586R2)

[Jonathan Wakely]

* include/std/type_traits (__is_standard_integer): New helper trait.
* include/std/utility (cmp_equal, cmp_not_equal, cmp_less, cmp_greater)
(cmp_less_equal, cmp_greater_equal, in_range): Define for C++20.
* include/std/version (__cpp_lib_integer_comparison_functions): Define.
* testsuite/20_util/integer_comparisons/1.cc: New test.
* testsuite/20_util/integer_comparisons/2.cc: New test.
* testsuite/20_util/integer_comparisons/equal.cc: New test.
* testsuite/20_util/integer_comparisons/equal_neg.cc: New test.
* testsuite/20_util/integer_comparisons/greater_equal.cc: New test.
* testsuite/20_util/integer_comparisons/greater_equal_neg.cc: New test.
* testsuite/20_util/integer_comparisons/greater_neg.cc: New test.
* testsuite/20_util/integer_comparisons/in_range.cc: New test.
* testsuite/20_util/integer_comparisons/in_range_neg.cc: New test.
* testsuite/20_util/integer_comparisons/less.cc: New test.
* testsuite/20_util/integer_comparisons/less_equal.cc: New test.
* testsuite/20_util/integer_comparisons/less_equal_neg.cc: New test.
* testsuite/20_util/integer_comparisons/less_neg.cc: New test.
* testsuite/20_util/integer_comparisons/not_equal.cc: New test.
* testsuite/20_util/integer_comparisons/not_equal_neg.cc: New test.

Tested powerpc64le-linux, committed to master.

commit 98cf2c265962e260f2f95617983915c754f446ea
Author: Jonathan Wakely 
Date:   Mon Feb 17 13:20:57 2020 +

libstdc++: Implement "Safe Integral Comparisons" (P0586R2)

* include/std/type_traits (__is_standard_integer): New helper trait.
* include/std/utility (cmp_equal, cmp_not_equal, cmp_less, 
cmp_greater)
(cmp_less_equal, cmp_greater_equal, in_range): Define for C++20.
* include/std/version (__cpp_lib_integer_comparison_functions): 
Define.
* testsuite/20_util/integer_comparisons/1.cc: New test.
* testsuite/20_util/integer_comparisons/2.cc: New test.
* testsuite/20_util/integer_comparisons/equal.cc: New test.
* testsuite/20_util/integer_comparisons/equal_neg.cc: New test.
* testsuite/20_util/integer_comparisons/greater_equal.cc: New test.
* testsuite/20_util/integer_comparisons/greater_equal_neg.cc: New 
test.
* testsuite/20_util/integer_comparisons/greater_neg.cc: New test.
* testsuite/20_util/integer_comparisons/in_range.cc: New test.
* testsuite/20_util/integer_comparisons/in_range_neg.cc: New test.
* testsuite/20_util/integer_comparisons/less.cc: New test.
* testsuite/20_util/integer_comparisons/less_equal.cc: New test.
* testsuite/20_util/integer_comparisons/less_equal_neg.cc: New test.
* testsuite/20_util/integer_comparisons/less_neg.cc: New test.
* testsuite/20_util/integer_comparisons/not_equal.cc: New test.
* testsuite/20_util/integer_comparisons/not_equal_neg.cc: New test.

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 6aa2cedfa0a..684a792d02c 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -622,6 +622,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
  >;
 
+  // Check if a type is one of the signed or unsigned integer types.
+  template
+using __is_standard_integer
+  = __or_<__is_signed_integer<_Tp>, __is_unsigned_integer<_Tp>>;
 
   // __void_t (std::void_t for C++11)
   template using __void_t = void;
diff --git a/libstdc++-v3/include/std/utility b/libstdc++-v3/include/std/utility
index 991113e1c8a..380c059395c 100644
--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -75,6 +75,10 @@
 #include 
 #include 
 
+#if __cplusplus > 201703L
+#include 
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -397,6 +401,76 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 void as_const(const _Tp&&) = delete;
 
+#if __cplusplus > 201703L
+#define __cpp_lib_integer_comparison_functions 202002L
+
+  template
+constexpr bool
+cmp_equal(_Tp __t, _Up __u) noexcept
+{
+  static_assert(__is_standard_integer<_Tp>::value);
+  static_assert(__is_standard_integer<_Up>::value);
+
+  if constexpr (is_signed_v<_Tp> == is_signed_v<_Up>)
+   return __t == __u;
+  else if constexpr (is_signed_v<_Tp>)
+   return __t >= 0 && make_unsigned_t<_Tp>(__t) == __u;
+  else
+   return __u >= 0 && __t == make_unsigned_t<_Up>(__u);
+}
+
+  template
+constexpr bool
+cmp_not_equal(_Tp __t, _Up __u) noexcept
+{ return !std::cmp_equal(__t, __u); }
+
+  template
+constexpr bool
+cmp_less(_Tp __t, _Up __u) noexcept
+{
+  static_assert(__is_standard_integer<_Tp>::value);
+  static_assert(__is_standard_integer<_Up>::value);
+
+   

[committed] libstdc++: Fix regression in libstdc++-prettyprinters/cxx20.cc

[Jonathan Wakely]

* python/libstdcxx/v6/printers.py (StdCmpCatPrinter.to_string): Update
value for partial_ordering::unordered.

Tested powerpc64le-linux, committed to master.


commit 4540ef781bcefffe779a8b31950ea737733f06a4
Author: Jonathan Wakely 
Date:   Mon Feb 17 13:20:57 2020 +

libstdc++: Fix regression in libstdc++-prettyprinters/cxx20.cc

* python/libstdcxx/v6/printers.py (StdCmpCatPrinter.to_string): 
Update
value for partial_ordering::unordered.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 7f69b0be9f1..e4da8dfe5b6 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1435,7 +1435,7 @@ class StdCmpCatPrinter:
 if self.typename == 'strong_ordering' and self.val == 0:
 name = 'equal'
 else:
-names = {-127:'unordered', -1:'less', 0:'equivalent', 1:'greater'}
+names = {2:'unordered', -1:'less', 0:'equivalent', 1:'greater'}
 name = names[int(self.val)]
 return 'std::{}::{}'.format(self.typename, name)
 

[committed] libstdc++: Make "implicit expression variants" more explicit (P2102R0)

[Jonathan Wakely]

* include/bits/iterator_concepts.h (indirectly_copyable_storable): Add
const-qualified expression variations.
* include/std/concepts (copyable): Likewise.

Tested powerpc64le-linux, committed to master.
commit d6dfa3dafc0a69a84002f1c0be17a70b0996cc72
Author: Jonathan Wakely 
Date:   Mon Feb 17 13:20:57 2020 +

libstdc++: Make "implicit expression variants" more explicit (P2102R0)

* include/bits/iterator_concepts.h (indirectly_copyable_storable): 
Add
const-qualified expression variations.
* include/std/concepts (copyable): Likewise.

diff --git a/libstdc++-v3/include/bits/iterator_concepts.h 
b/libstdc++-v3/include/bits/iterator_concepts.h
index 04c862a4b97..792b3262106 100644
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -693,7 +693,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 concept indirectly_copyable_storable = indirectly_copyable<_In, _Out>
+  && indirectly_writable<_Out, iter_value_t<_In>&>
   && indirectly_writable<_Out, const iter_value_t<_In>&>
+  && indirectly_writable<_Out, iter_value_t<_In>&&>
+  && indirectly_writable<_Out, const iter_value_t<_In>&&>
   && copyable>
   && constructible_from, iter_reference_t<_In>>
   && assignable_from&, iter_reference_t<_In>>;
diff --git a/libstdc++-v3/include/std/concepts 
b/libstdc++-v3/include/std/concepts
index db614899942..acc9dd2599d 100644
--- a/libstdc++-v3/include/std/concepts
+++ b/libstdc++-v3/include/std/concepts
@@ -251,7 +251,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 concept copyable = copy_constructible<_Tp> && movable<_Tp>
-  && assignable_from<_Tp&, const _Tp&>;
+  && assignable_from<_Tp&, _Tp&> && assignable_from<_Tp&, const _Tp&>
+  && assignable_from<_Tp&, const _Tp>;
 
   template
 concept semiregular = copyable<_Tp> && default_initializable<_Tp>;

[Regression, patch][Fortran] ICE: Invalid expression in gfc_element_size PR93601

[Mark Eggleston]

Please find attached a fix for PR93601.

gcc/fortran/ChangeLogs

    Steven G. Kargl  

    PR fortran/93601
    * match.c (gfc_match_assignment) : Reject assignment if
    the lhs stype is BT_CLASS and the rhs type is BT_BOZ.

gcc/testsuite/ChangeLogs

    Mark Eggleston  

    PR fortran/93601
    * gfortran.dg/pr93601.f90 : New test.

Test using make with check-fortran on master at

https://gcc.gnu.org/g:f82617f229b336d856c18313339b14657e05c129

OK to commit?

--
https://www.codethink.co.uk/privacy.html

>From d5e4dab84324f3c31eeaf3bf22dd96503d34e654 Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Fri, 7 Feb 2020 15:33:38 +
Subject: [PATCH] [Fortran] ICE: Invalid expression in gfc_element_size PR93601

ICE occurs when assigning a BOZ constant to an class(*) variable
with the allocatable attribute. Use of BOZ constants outside
data statements and int/real/dble/cmplx intrinsics is not allowed.

Original patch provided by Steven G. Kargl  .

gcc/fortran/ChangeLog

	PR fortran/93601
	* match.c (gfc_match_assignment) : Reject assignment if
	the lhs stype is BT_CLASS and the rhs type is BT_BOZ.

gcc/testsuite/ChangeLog

	PR fortran/93601
	* gfortran.dg/pr93601.f90 : New test.
---
 gcc/fortran/match.c   | 10 ++
 gcc/testsuite/gfortran.dg/pr93601.f90 |  7 +++
 2 files changed, 17 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr93601.f90

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index a74cb8c5c19..5713dc20180 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -1348,6 +1348,16 @@ gfc_match_assignment (void)
   rvalue = NULL;
   m = gfc_match (" %e%t", &rvalue);
 
+  if (m == MATCH_YES
+  && rvalue->ts.type == BT_BOZ
+  && lvalue->ts.type == BT_CLASS)
+{
+  m = MATCH_ERROR;
+  gfc_error ("BOZ literal constant at %L is neither a DATA statement "
+		 "value nor an actual argument of INT/REAL/DBLE/CMPLX "
+		 "intrinsic subprogram", &rvalue->where);
+}
+
   if (lvalue->expr_type == EXPR_CONSTANT)
 {
   /* This clobbers %len and %kind.  */
diff --git a/gcc/testsuite/gfortran.dg/pr93601.f90 b/gcc/testsuite/gfortran.dg/pr93601.f90
new file mode 100644
index 000..495447c637b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93601.f90
@@ -0,0 +1,7 @@
+! { dg-do compile }
+
+program p
+   class(*), allocatable :: z
+   z = z'1' ! { dg-error "BOZ literal constant at" }
+end
+
-- 
2.11.0

Re: [PR47785] COLLECT_AS_OPTIONS

[Richard Biener]

On Mon, Feb 17, 2020 at 10:28 AM Prathamesh Kulkarni
 wrote:
>
> On Thu, 6 Feb 2020 at 20:03, Prathamesh Kulkarni
>  wrote:
> >
> > On Thu, 6 Feb 2020 at 18:42, Richard Biener  
> > wrote:
> > >
> > > On Thu, Feb 6, 2020 at 1:48 PM Prathamesh Kulkarni
> > >  wrote:
> > > >
> > > > On Tue, 4 Feb 2020 at 19:44, Richard Biener 
> > > >  wrote:
> > > > >
> > > > > On Mon, Feb 3, 2020 at 12:37 PM Prathamesh Kulkarni
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, 30 Jan 2020 at 19:10, Richard Biener 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Tue, 28 Jan 2020 at 17:17, Richard Biener 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, 20 Jan 2020 at 15:44, Richard Biener 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Jan 8, 2020 at 11:20 AM Prathamesh Kulkarni
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 5 Nov 2019 at 17:38, Richard Biener 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, 5 Nov 2019 at 03:57, H.J. Lu 
> > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Sun, Nov 3, 2019 at 6:45 PM Kugan 
> > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks for the reviews.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Sat, 2 Nov 2019 at 02:49, H.J. Lu 
> > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:33 PM Kugan 
> > > > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, 30 Oct 2019 at 03:11, H.J. Lu 
> > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Sun, Oct 27, 2019 at 6:33 PM Kugan 
> > > > > > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, 23 Oct 2019 at 23:07, Richard 
> > > > > > > > > > > > > > > > > > > > Biener  
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Mon, Oct 21, 2019 at 10:04 AM 
> > > > > > > > > > > > > > > > > > > > > Kugan Vivekanandarajah
> > > > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks for the pointers.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, 11 Oct 2019 at 22:33, 
> > > > > > > > > > > > > > > > > > > > > > Richard Biener 
> > > > > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 11, 2019 at 6:15 AM 
> > > > > > > > > > > > > > > > > > > > > > > Kugan Vivekanandarajah
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > > > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2 Oct 2019 at 20:41, 
> > > > > > > > > > > > > > > > > > > > > > > > Richard Biener 
> > > > > > > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 2, 2019 at 10:39 
> > > > > > > > > > > > > > > > > > > > > > > > > AM Kugan Vivekanandarajah
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >

Re: [PATCH] Drop MALLOC attribute for void functions.

[Richard Biener]

On Mon, Feb 17, 2020 at 1:16 PM Martin Liška  wrote:
>
> Hello.
>
> As mentioned in the PR, we end up with a void function
> call that has set MALLOC attribute. That causes problems in RTL
> expansion.
>
> I believe a proper fix is to drop the attribute when a callgraph
> clone with void type is created.
>
> I would like to see Martin's comment about the hunk in propagate_malloc
> which is maybe suboptimal and one can find a better way?
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> It fixes LTO bootstrap on ppc64le.

Is the ipa-pure-const.c hunk really necessary? malloc_candidate_p shouldn't
see any such function as candidate.  If so it should be fixed there?

Thanks,
Richard.

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-02-17  Martin Liska  
>
> PR ipa/93583
> * cgraph.c (cgraph_node::verify_node): Verify MALLOC attribute
> and return type of functions.
> * ipa-param-manipulation.c (ipa_param_adjustments::adjust_decl):
> Drop MALLOC attribute for void functions.
> * ipa-pure-const.c (propagate_malloc): Do not set malloc flag
> for void functions.
>
> gcc/testsuite/ChangeLog:
>
> 2020-02-17  Martin Liska  
>
> PR ipa/93583
> * gcc.dg/ipa/pr93583.c: New test.
> ---
>   gcc/cgraph.c   |  6 ++
>   gcc/ipa-param-manipulation.c   |  4 
>   gcc/ipa-pure-const.c   |  9 ++---
>   gcc/testsuite/gcc.dg/ipa/pr93583.c | 15 +++
>   4 files changed, 31 insertions(+), 3 deletions(-)
>   create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93583.c
>
>

Re: [PATCH] Drop MALLOC attribute for void functions.

[Martin Liška]

On 2/17/20 3:25 PM, Richard Biener wrote:

On Mon, Feb 17, 2020 at 1:16 PM Martin Liška  wrote:


Hello.

As mentioned in the PR, we end up with a void function
call that has set MALLOC attribute. That causes problems in RTL
expansion.

I believe a proper fix is to drop the attribute when a callgraph
clone with void type is created.

I would like to see Martin's comment about the hunk in propagate_malloc
which is maybe suboptimal and one can find a better way?

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
It fixes LTO bootstrap on ppc64le.


Is the ipa-pure-const.c hunk really necessary?


Yes.


malloc_candidate_p shouldn't
see any such function as candidate.  If so it should be fixed there?


I've got hopefully a proper fix. Which is where we clone funct_state_summary_t
summary for the newly cloned IPA SRA function.

I'm going to test the patch.
Martin



Thanks,
Richard.


Thanks,
Martin

gcc/ChangeLog:

2020-02-17  Martin Liska  

 PR ipa/93583
 * cgraph.c (cgraph_node::verify_node): Verify MALLOC attribute
 and return type of functions.
 * ipa-param-manipulation.c (ipa_param_adjustments::adjust_decl):
 Drop MALLOC attribute for void functions.
 * ipa-pure-const.c (propagate_malloc): Do not set malloc flag
 for void functions.

gcc/testsuite/ChangeLog:

2020-02-17  Martin Liska  

 PR ipa/93583
 * gcc.dg/ipa/pr93583.c: New test.
---
   gcc/cgraph.c   |  6 ++
   gcc/ipa-param-manipulation.c   |  4 
   gcc/ipa-pure-const.c   |  9 ++---
   gcc/testsuite/gcc.dg/ipa/pr93583.c | 15 +++
   4 files changed, 31 insertions(+), 3 deletions(-)
   create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93583.c




>From c49949575f661d67afc7cc77d8e6f5f8bea922a2 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 17 Feb 2020 12:33:28 +0100
Subject: [PATCH] Drop MALLOC attribute for void functions.

gcc/ChangeLog:

2020-02-17  Martin Liska  

	PR ipa/93583
	* cgraph.c (cgraph_node::verify_node): Verify MALLOC attribute
	and return type of functions.
	* ipa-param-manipulation.c (ipa_param_adjustments::adjust_decl):
	Drop MALLOC attribute for void functions.
	* ipa-pure-const.c (funct_state_summary_t::duplicate): Drop
	malloc_state for a new VOID clone.

gcc/testsuite/ChangeLog:

2020-02-17  Martin Liska  

	PR ipa/93583
	* gcc.dg/ipa/pr93583.c: New test.
---
 gcc/cgraph.c   |  6 ++
 gcc/ipa-param-manipulation.c   |  4 
 gcc/ipa-pure-const.c   | 14 ++
 gcc/testsuite/gcc.dg/ipa/pr93583.c | 15 +++
 4 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93583.c

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 294b2d392fd..6e99fbb45f4 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3374,6 +3374,12 @@ cgraph_node::verify_node (void)
   error ("calls_comdat_local is set outside of a comdat group");
   error_found = true;
 }
+  if (DECL_IS_MALLOC (decl)
+  && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (decl
+{
+  error ("MALLOC attribute set on a void function");
+  error_found = true;
+}
   for (e = indirect_calls; e; e = e->next_callee)
 {
   if (e->aux)
diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
index 19ec87358fa..839bd2ef870 100644
--- a/gcc/ipa-param-manipulation.c
+++ b/gcc/ipa-param-manipulation.c
@@ -410,6 +410,10 @@ ipa_param_adjustments::adjust_decl (tree orig_decl)
   DECL_VIRTUAL_P (new_decl) = 0;
   DECL_LANG_SPECIFIC (new_decl) = NULL;
 
+  /* Drop MALLOC attribute for a void function.  */
+  if (m_skip_return)
+DECL_IS_MALLOC (new_decl) = 0;
+
   return new_decl;
 }
 
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index ccd0918c120..a2d0792b0ce 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1157,11 +1157,14 @@ funct_state_summary_t::insert (cgraph_node *node, funct_state_d *state)
 /* Called when new clone is inserted to callgraph late.  */
 
 void
-funct_state_summary_t::duplicate (cgraph_node *, cgraph_node *,
+funct_state_summary_t::duplicate (cgraph_node *src, cgraph_node *dst,
   funct_state_d *src_data,
   funct_state_d *dst_data)
 {
   new (dst_data) funct_state_d (*src_data);
+  if (dst_data->malloc_state == STATE_MALLOC
+  && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (dst->decl
+dst_data->malloc_state = STATE_MALLOC_BOTTOM;
 }
 
 
@@ -1973,9 +1976,12 @@ propagate_malloc (void)
 		   node->dump_name ());
 
 	bool malloc_decl_p = DECL_IS_MALLOC (node->decl);
-	node->set_malloc_flag (true);
-	if (!malloc_decl_p && warn_suggest_attribute_malloc)
-		warn_function_malloc (node->decl);
+	if (!VOID_TYPE_P (TREE_TYPE (TREE_TYPE (node->decl
+	  {
+		node->set_malloc_flag (true);
+		if (!malloc_decl_p && warn_suggest_attribute_malloc)
+		  warn_function_malloc (node->decl);
+	  }
 	  }
   }
 
diff --git a/gcc/tes

Re: [PATCH] Drop MALLOC attribute for void functions.

[Martin Liška]

Sorry, I attached wrong patch.

Martin
>From c215a4d5d5d5aa72729c16408805eb9ddf5f0d38 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 17 Feb 2020 12:33:28 +0100
Subject: [PATCH] Drop MALLOC attribute for void functions.

gcc/ChangeLog:

2020-02-17  Martin Liska  

	PR ipa/93583
	* cgraph.c (cgraph_node::verify_node): Verify MALLOC attribute
	and return type of functions.
	* ipa-param-manipulation.c (ipa_param_adjustments::adjust_decl):
	Drop MALLOC attribute for void functions.
	* ipa-pure-const.c (funct_state_summary_t::duplicate): Drop
	malloc_state for a new VOID clone.

gcc/testsuite/ChangeLog:

2020-02-17  Martin Liska  

	PR ipa/93583
	* gcc.dg/ipa/pr93583.c: New test.
---
 gcc/cgraph.c   |  6 ++
 gcc/ipa-param-manipulation.c   |  4 
 gcc/ipa-pure-const.c   |  5 -
 gcc/testsuite/gcc.dg/ipa/pr93583.c | 15 +++
 4 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93583.c

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 294b2d392fd..6e99fbb45f4 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3374,6 +3374,12 @@ cgraph_node::verify_node (void)
   error ("calls_comdat_local is set outside of a comdat group");
   error_found = true;
 }
+  if (DECL_IS_MALLOC (decl)
+  && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (decl
+{
+  error ("MALLOC attribute set on a void function");
+  error_found = true;
+}
   for (e = indirect_calls; e; e = e->next_callee)
 {
   if (e->aux)
diff --git a/gcc/ipa-param-manipulation.c b/gcc/ipa-param-manipulation.c
index 19ec87358fa..839bd2ef870 100644
--- a/gcc/ipa-param-manipulation.c
+++ b/gcc/ipa-param-manipulation.c
@@ -410,6 +410,10 @@ ipa_param_adjustments::adjust_decl (tree orig_decl)
   DECL_VIRTUAL_P (new_decl) = 0;
   DECL_LANG_SPECIFIC (new_decl) = NULL;
 
+  /* Drop MALLOC attribute for a void function.  */
+  if (m_skip_return)
+DECL_IS_MALLOC (new_decl) = 0;
+
   return new_decl;
 }
 
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index ccd0918c120..564c6629c92 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1157,11 +1157,14 @@ funct_state_summary_t::insert (cgraph_node *node, funct_state_d *state)
 /* Called when new clone is inserted to callgraph late.  */
 
 void
-funct_state_summary_t::duplicate (cgraph_node *, cgraph_node *,
+funct_state_summary_t::duplicate (cgraph_node *, cgraph_node *dst,
   funct_state_d *src_data,
   funct_state_d *dst_data)
 {
   new (dst_data) funct_state_d (*src_data);
+  if (dst_data->malloc_state == STATE_MALLOC
+  && VOID_TYPE_P (TREE_TYPE (TREE_TYPE (dst->decl
+dst_data->malloc_state = STATE_MALLOC_BOTTOM;
 }
 
 
diff --git a/gcc/testsuite/gcc.dg/ipa/pr93583.c b/gcc/testsuite/gcc.dg/ipa/pr93583.c
new file mode 100644
index 000..30ef506553d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr93583.c
@@ -0,0 +1,15 @@
+/* PR ipa/93583 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+void *bar(const char*);
+static void *__attribute__((malloc,noinline)) foo(const char *p)
+{
+  return bar (p);
+}
+
+int main(int argc, char **argv)
+{
+  foo (argv[0]);
+  return 0;
+}
-- 
2.25.0

Re: [PATCH] Drop MALLOC attribute for void functions.

[Martin Jambor]

Hi,

On Mon, Feb 17 2020, Richard Biener wrote:
> On Mon, Feb 17, 2020 at 1:16 PM Martin Liška  wrote:
>>
>> Hello.
>>
>> As mentioned in the PR, we end up with a void function
>> call that has set MALLOC attribute. That causes problems in RTL
>> expansion.
>>
>> I believe a proper fix is to drop the attribute when a callgraph
>> clone with void type is created.
>>
>> I would like to see Martin's comment about the hunk in propagate_malloc
>> which is maybe suboptimal and one can find a better way?
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>> It fixes LTO bootstrap on ppc64le.
>
> Is the ipa-pure-const.c hunk really necessary? malloc_candidate_p shouldn't
> see any such function as candidate.  If so it should be fixed there?

malloc_candidate_p runs at summary building phase (LTO compile time) and
IPA-SRA WPA phase, which actually removes the return value, runs between
that and ipa-pure-const WPA phase. So without the hunk, the pass could
now happily re-introduce the flag.

I have not analyzed the original bug report but I actually believe that
the ipa-pure-const hunk is actually the one fixing the core issue there.
Otherwise, removal of the attribute in tree-inline.c would have been
enough.

If we don't like adding another look at the trees in a WPA phase of an
IPA pass, ipa-pure const could alternatively test:

  if (node->param_adjustments && node->param_adjustments->m_skip_return)
continue;

Martin


>
> Thanks,
> Richard.
>
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2020-02-17  Martin Liska  
>>
>> PR ipa/93583
>> * cgraph.c (cgraph_node::verify_node): Verify MALLOC attribute
>> and return type of functions.
>> * ipa-param-manipulation.c (ipa_param_adjustments::adjust_decl):
>> Drop MALLOC attribute for void functions.
>> * ipa-pure-const.c (propagate_malloc): Do not set malloc flag
>> for void functions.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2020-02-17  Martin Liska  
>>
>> PR ipa/93583
>> * gcc.dg/ipa/pr93583.c: New test.
>> ---
>>   gcc/cgraph.c   |  6 ++
>>   gcc/ipa-param-manipulation.c   |  4 
>>   gcc/ipa-pure-const.c   |  9 ++---
>>   gcc/testsuite/gcc.dg/ipa/pr93583.c | 15 +++
>>   4 files changed, 31 insertions(+), 3 deletions(-)
>>   create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93583.c
>>
>>

Re: [PATCH] Drop MALLOC attribute for void functions.

[Jakub Jelinek]

On Mon, Feb 17, 2020 at 03:44:53PM +0100, Martin Liška wrote:
> +  error ("MALLOC attribute set on a void function");

Why the capitals?  Either malloc or % IMSHO.
What is special about void functions, missing lhs?  That can be missing
for other functions (where you just don't use the return value, or e.g.
noreturn even if you do)?  And otherwise, shouldn't the test be rather
whether the return type is a pointer type?  E.g. float or int return
type for malloc attribute isn't very meaningful.

Jakub

Re: [PATCH v2][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch.

[Kyrill Tkachov]

Hi Srinath,

On 2/14/20 4:26 PM, Srinath Parvathaneni wrote:

Hi Kyrill,

> This patch series depends on upstream patches "Armv8.1-M Mainline 
Security Extension" [4],
> "CLI and multilib support for Armv8.1-M Mainline MVE extensions" [5] 
and "support for Armv8.1-M

> Mainline scalar shifts" [6].

Patch (version v1) was approved before. The above patches on which 
this patch (version v1) depends are

committed to trunk last month.

(version v1) https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01338.html

This patch (Version v2) is re-based on latest trunk resolving few 
conflicts.


Regression tested on arm-none-eabi and found no regressions.


Can you please also test armeb-none-eabi to make sure big-endian works.




Ok for trunk? If ok, please commit on my behalf. I don't have the 
commit rights.


Ok, thanks.

Please apply for a commit access using the form at 
https://sourceware.org/cgi-bin/pdw/ps_form.cgi using my name/email as 
approver.


More details at https://gcc.gnu.org/gitwrite.html

Then you can commit them yourself :)

Thanks,

Kyrill




Thanks,
Srinath

##

Hello,

This patch creates the required framework for MVE ACLE intrinsics.

The following changes are done in this patch to support MVE ACLE 
intrinsics.


Header file arm_mve.h is added to source code, which contains the 
definitions of MVE ACLE intrinsics
and different data types used in MVE. Machine description file mve.md 
is also added which contains the

RTL patterns defined for MVE.

A new reigster "p0" is added which is used in by MVE predicated 
patterns. A new register class "VPR_REG"

is added and its contents are defined in REG_CLASS_CONTENTS.

The vec-common.md file is modified to support the standard move 
patterns. The prefix of neon functions

which are also used by MVE is changed from "neon_" to "simd_".
eg: neon_immediate_valid_for_move changed to 
simd_immediate_valid_for_move.


In the patch standard patterns mve_move, mve_store and move_load for 
MVE are added and neon.md and vfp.md

files are modified to support this common patterns.

Please refer to Arm reference manual [1] for more details.

[1] https://developer.arm.com/docs/ddi0553/latest

Regression tested on arm-none-eabi and found no regressions.

Ok for trunk?

Thanks,
Srinath

gcc/ChangeLog:

2020-02-10  Andre Vieira 
    Mihail Ionescu  
    Srinath Parvathaneni 

    * config.gcc (arm_mve.h): Include mve intrinsics header file.
    * config/arm/aout.h (p0): Add new register name for MVE predicated
    cases.
    * config/arm-builtins.c (ARM_BUILTIN_SIMD_LANE_CHECK): Define 
macro

    common to Neon and MVE.
    (ARM_BUILTIN_NEON_LANE_CHECK): Renamed to 
ARM_BUILTIN_SIMD_LANE_CHECK.

    (arm_init_simd_builtin_types): Disable poly types for MVE.
    (arm_init_neon_builtins): Move a check to arm_init_builtins 
function.

    (arm_init_builtins): Use ARM_BUILTIN_SIMD_LANE_CHECK instead of
    ARM_BUILTIN_NEON_LANE_CHECK.
    (mve_dereference_pointer): Add function.
    (arm_expand_builtin_args): Call to mve_dereference_pointer 
when MVE is

    enabled.
    (arm_expand_neon_builtin): Moved to arm_expand_builtin function.
    (arm_expand_builtin): Moved from arm_expand_neon_builtin function.
    * config/arm/arm-c.c (__ARM_FEATURE_MVE): Define macro for MVE 
and MVE

    with floating point enabled.
    * config/arm/arm-protos.h (neon_immediate_valid_for_move): 
Renamed to

    simd_immediate_valid_for_move.
    (simd_immediate_valid_for_move): Renamed from
    neon_immediate_valid_for_move function.
    * config/arm/arm.c (arm_options_perform_arch_sanity_checks): 
Generate

    error if vfpv2 feature bit is disabled and mve feature bit is also
    disabled for HARD_FLOAT_ABI.
    (use_return_insn): Check to not push VFP regs for MVE.
    (aapcs_vfp_allocate): Add MVE check to have same Procedure 
Call Standard

    as Neon.
    (aapcs_vfp_allocate_return_reg): Likewise.
    (thumb2_legitimate_address_p): Check to return 0 on valid Thumb-2
    address operand for MVE.
    (arm_rtx_costs_internal): MVE check to determine cost of rtx.
    (neon_valid_immediate): Rename to simd_valid_immediate.
    (simd_valid_immediate): Rename from neon_valid_immediate.
    (simd_valid_immediate): MVE check on size of vector is 128 bits.
    (neon_immediate_valid_for_move): Rename to
    simd_immediate_valid_for_move.
    (simd_immediate_valid_for_move): Rename from
    neon_immediate_valid_for_move.
    (neon_immediate_valid_for_logic): Modify call to 
neon_valid_immediate

    function.
    (neon_make_constant): Modify call to neon_valid_immediate 
function.
    (neon_vector_mem_operand): Return VFP register for POST_INC or 
PRE_DEC

    for MVE.
    (output_move_neon): Add MVE check to generate vldm/vstm 
instrcutions.
    (arm_compute_frame_layout): Ca

Re: [PATCH v2][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch.

[Kyrill Tkachov]

Hi Srinath,

On 2/14/20 4:34 PM, Srinath Parvathaneni wrote:

Hello Kyrill,

In this patch (v2) all the review comments mentioned in previous patch 
(v1) are

addressed.

(v1) https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01395.html

#

Hello,

This patch is part of MVE ACLE intrinsics framework.
This patches add support to update (read/write) the APSR (Application 
Program Status Register)
register and FPSCR (Floating-point Status and Control Register) 
register for MVE.

This patch also enables thumb2 mov RTL patterns for MVE.

A new feature bit vfp_base is added. This bit is enabled for all VFP, 
MVE and MVE with floating point
extensions. This bit is used to enable the macro TARGET_VFP_BASE. For 
all the VFP instructions, RTL patterns,
status and control registers are guarded by TARGET_HAVE_FLOAT. But 
this patch modifies that and the
common instructions, RTL patterns, status and control registers 
bewteen MVE and VFP are guarded by

TARGET_VFP_BASE macro.

The RTL pattern set_fpscr and get_fpscr are updated to use 
VFPCC_REGNUM because few MVE intrinsics

set/get carry bit of FPSCR register.

Please refer to Arm reference manual [1] for more details.
[1] https://developer.arm.com/docs/ddi0553/latest

Regression tested on arm-none-eabi and found no regressions.

Ok for trunk?


Ok (please test a big-endian target as well, as per the 1st framework 
patch).


Thanks,

Kyrill




Thanks,
Srinath
gcc/ChangeLog:

2020-20-11  Andre Vieira 
    Mihail Ionescu  
    Srinath Parvathaneni 

    * common/config/arm/arm-common.c (arm_asm_auto_mfpu): When 
vfp_base
    feature bit is on and -mfpu=auto is passed as compiler option, 
do not
    generate error on not finding any match fpu. Because in this 
case fpu

    is not required.
    * config/arm/arm-cpus.in (vfp_base): Define feature bit, this 
bit is

    enabled for MVE and also for all VFP extensions.
    (VFPv2): Modify fgroup to enable vfp_base feature bit when 
ever VFPv2

    is enabled.
    (MVE): Define fgroup to enable feature bits mve, vfp_base and 
armv7em.
    (MVE_FP): Define fgroup to enable feature bits is fgroup MVE 
and FPv5

    along with feature bits mve_float.
    (mve): Modify add options in armv8.1-m.main arch for MVE.
    (mve.fp): Modify add options in armv8.1-m.main arch for MVE with
    floating point.
    * config/arm/arm.c (use_return_insn): Replace the
    check with TARGET_VFP_BASE.
    (thumb2_legitimate_index_p): Replace TARGET_HARD_FLOAT with
    TARGET_VFP_BASE.
    (arm_rtx_costs_internal): Replace "TARGET_HARD_FLOAT || 
TARGET_HAVE_MVE"
    with TARGET_VFP_BASE, to allow cost calculations for copies in 
MVE as

    well.
    (arm_get_vfp_saved_size): Replace TARGET_HARD_FLOAT with
    TARGET_VFP_BASE, to allow space calculation for VFP registers 
in MVE

    as well.
    (arm_compute_frame_layout): Likewise.
    (arm_save_coproc_regs): Likewise.
    (arm_fixed_condition_code_regs): Modify to enable using 
VFPCC_REGNUM

    in MVE as well.
    (arm_hard_regno_mode_ok): Replace "TARGET_HARD_FLOAT || 
TARGET_HAVE_MVE"

    with equivalent macro TARGET_VFP_BASE.
    (arm_expand_epilogue_apcs_frame): Likewise.
    (arm_expand_epilogue): Likewise.
    (arm_conditional_register_usage): Likewise.
    (arm_declare_function_name): Add check to skip printing .fpu 
directive
    in assembly file when TARGET_VFP_BASE is enabled and 
fpu_to_print is

    "softvfp".
    * config/arm/arm.h (TARGET_VFP_BASE): Define.
    * config/arm/arm.md (arch): Add "mve" to arch.
    (eq_attr "arch" "mve"): Enable on TARGET_HAVE_MVE is true.
    (vfp_pop_multiple_with_writeback): Replace "TARGET_HARD_FLOAT
    || TARGET_HAVE_MVE" with equivalent macro TARGET_VFP_BASE.
    * config/arm/constraints.md (Uf): Define for MVE.
    * config/arm/thumb2.md (thumb2_movsfcc_soft_insn): Modify 
target guard

    to not allow for MVE.
    * config/arm/unspecs.md (UNSPEC_GET_FPSCR): Move to volatile 
unspecs

    enum.
    (VUNSPEC_GET_FPSCR): Define.
    * config/arm/vfp.md (thumb2_movhi_vfp): Add support for VMSR 
and VMRS
    instructions which move to general-purpose Register from 
Floating-point

    Special register and vice-versa.
    (thumb2_movhi_fp16): Likewise.
    (thumb2_movsi_vfp): Add support for VMSR and VMRS instructions 
along
    with MCR and MRC instructions which set and get Floating-point 
Status

    and Control Register (FPSCR).
    (movdi_vfp): Modify pattern to enable Single-precision scalar 
float move

    in MVE.
    (thumb2_movdf_vfp): Modify pattern to enable Double-precision 
scalar

    float move patterns in MVE.
    (thumb2_movsfcc_vfp): Modify pattern to enable single float 
conditional
    code move patterns of VFP also in MVE by adding 
TARGET_VFP_BASE chec

Re: [PATCH v2][ARM][GCC][3/x]: MVE ACLE intrinsics framework patch.

[Kyrill Tkachov]

On 2/14/20 4:34 PM, Srinath Parvathaneni wrote:

Hello Kyrill,

In this patch (v2) all the review comments mentioned in previous patch 
(v1) are

addressed.

(v1) https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01401.html

#

Hello,

This patch is part of MVE ACLE intrinsics framework.

The patch supports the use of emulation for the single-precision 
arithmetic
operations for MVE. This changes are to support the MVE ACLE 
intrinsics which

operates on vector floating point arithmetic operations.

Please refer to Arm reference manual [1] for more details.
[1] 
https://static.docs.arm.com/ddi0553/bh/DDI0553B_h_armv8m_arm.pdf?_ga=2.102521798.659307368.1572453718-1501600630.1548848914


Regression tested on arm-none-eabi and found no regressions.

Ok for trunk?


Ok.

Thanks,

Kyrill



Thanks,
Srinath.

gcc/ChangeLog:

2019-11-11  Andre Vieira 
    Srinath Parvathaneni 

    * config/arm/arm.c (arm_libcall_uses_aapcs_base): Modify 
function to add

    emulator calls for dobule precision arithmetic operations for MVE.


### Attachment also inlined for ease of reply    
###



>From af9d1eb4470c26564b69518bbec3fce297501fdd Mon Sep 17 00:00:00 2001
From: Srinath Parvathaneni 
Date: Tue, 11 Feb 2020 18:42:20 +
Subject: [PATCH] [PATCH][ARM][GCC][3/x]: MVE ACLE intrinsics framework 
patch.


---
 gcc/config/arm/arm.c   | 22 ++-
 .../gcc.target/arm/mve/intrinsics/mve_libcall1.c   | 70 
++
 .../gcc.target/arm/mve/intrinsics/mve_libcall2.c   | 70 
++

 3 files changed, 159 insertions(+), 3 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
 create mode 100644 
gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c


diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 037f298..e00024b 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -5754,9 +5754,25 @@ arm_libcall_uses_aapcs_base (const_rtx libcall)
   /* Values from double-precision helper functions are returned 
in core

  registers if the selected core only supports single-precision
  arithmetic, even if we are using the hard-float ABI.  The 
same is

-    true for single-precision helpers, but we will never be using the
-    hard-float ABI on a CPU which doesn't support single-precision
-    operations in hardware.  */
+    true for single-precision helpers except in case of MVE, 
because in
+    MVE we will be using the hard-float ABI on a CPU which 
doesn't support
+    single-precision operations in hardware.  In MVE the 
following check

+    enables use of emulation for the single-precision arithmetic
+    operations.  */
+  if (TARGET_HAVE_MVE)
+   {
+ add_libcall (libcall_htab, optab_libfunc (add_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (sdiv_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (smul_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (neg_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (sub_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (eq_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (lt_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (le_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (ge_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (gt_optab, SFmode));
+ add_libcall (libcall_htab, optab_libfunc (unord_optab, SFmode));
+   }
   add_libcall (libcall_htab, optab_libfunc (add_optab, DFmode));
   add_libcall (libcall_htab, optab_libfunc (sdiv_optab, DFmode));
   add_libcall (libcall_htab, optab_libfunc (smul_optab, DFmode));
diff --git 
a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c

new file mode 100644
index 000..45f46b1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
@@ -0,0 +1,70 @@
+/* { dg-do compile  } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
+
+float
+foo (float a, float b, float c)
+{
+  return a + b + c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fadd" }  } */
+/* { dg-final { scan-assembler-times "bl\\t__aeabi_fadd" 2 } } */
+
+float
+foo1 (float a, float b, float c)
+{
+  return a - b - c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fsub" }  } */
+/* { dg-final { scan-assembler-times "bl\\t__aeabi_fsub" 2 } } */
+
+float
+foo2 (float a, float b, float c)
+{
+  return a * b * c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fmul" }  } */
+/* { dg-final { scan-assembler-times "bl\\t__aeabi_fmul" 2 } } */
+
+float
+foo3 (float b, float c)
+{
+  return b / c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fdiv" }  } */
+
+int
+foo4 (float b, float c)
+{
+  return

Re: One more patch for PR91333

[Maxim Kuvyrkov]

Hi Vladimir,

This patch increases code size at -Os on arm-linux-gnueabihf by 1% (with no 
code-size reductions) on several SPEC CPU2006 benchmarks:

400.perlbench,perlbench_base.default ,580842,583842
429.mcf,mcf_base.default ,7867,7955
403.gcc,gcc_base.default ,1726449,1736149
433.milc,milc_base.default   ,66328,66816
456.hmmer,hmmer_base.default ,148394,149434
482.sphinx3,sphinx_livepretend_base.default  ,99183,99863

Could you look into whether these regressions can be avoided?

Thanks,

--
Maxim Kuvyrkov
https://www.linaro.org

> On Feb 2, 2020, at 7:46 PM, Vladimir Makarov  wrote:
> 
>   The previous patch for
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333
> 
> resulted in aarch64 testsuite failures.
> 
> The following patch solves some of the failures and modified the PR test as 
> the generated code changed.
> 
> The patch was successfully bootstrapped on x86-64 and benchmarked on SPEC2000.
> 
> 
> 

Re: [PATCH] Drop MALLOC attribute for void functions.

[Martin Liška]

On 2/17/20 3:48 PM, Jakub Jelinek wrote:

On Mon, Feb 17, 2020 at 03:44:53PM +0100, Martin Liška wrote:

+  error ("MALLOC attribute set on a void function");


Why the capitals?  Either malloc or % IMSHO.


Sure, I'll fix it.


What is special about void functions, missing lhs?  That can be missing
for other functions (where you just don't use the return value, or e.g.
noreturn even if you do)?  And otherwise, shouldn't the test be rather
whether the return type is a pointer type?  E.g. float or int return
type for malloc attribute isn't very meaningful.


Hopefully one can't set malloc attribute to a symbol that does not
return a pointer type:

head malloc.c
float bar(const char*);
static float __attribute__((malloc,noinline)) foo(const char *p)
{
  return bar (p);
}

$ gcc malloc.c -c -O2
malloc.c:3:1: warning: ‘malloc’ attribute ignored [-Wattributes]
3 | {

Martin



Jakub

[PATCH] Compare more sensitive FIX_TRUNC_EXPR in IPA ICF.

[Martin Liška]

Hi.

The patch is extension of 446096148ca9775cb56f9ee924fa283babcd0b76 commit
where we need to handle FIX_TRUNC_EXPR in compare_gimple_assign.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-02-17  Martin Liska  

PR ipa/92518
* ipa-icf-gimple.c (func_checker::compare_gimple_assign):
Consider also FIX_TRUNC_EXPR.
---
 gcc/ipa-icf-gimple.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index fa71a028c66..4a4f06b79b4 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -621,7 +621,9 @@ func_checker::compare_gimple_assign (gimple *s1, gimple *s2)
   arg2 = gimple_op (s2, i);
 
   /* LHS types of NOP_EXPR must be compatible.  */
-  if (CONVERT_EXPR_CODE_P (code1) && i == 0)
+  if ((CONVERT_EXPR_CODE_P (code1)
+	   || code1 == FIX_TRUNC_EXPR)
+	  && i == 0)
 	{
 	  if (!compatible_types_p (TREE_TYPE (arg1), TREE_TYPE (arg2)))
 	return return_false_with_msg ("GIMPLE NOP LHS type mismatch");

[committed] libstdc++: Add lightweight replacement for std::numeric_limits (PR 92546)

[Jonathan Wakely]

Many uses of std::numeric_limits in C++17 and C++20 features only really
need the min(), max() and digits constants for integral types. By adding
__detail::__int_limits we can avoid including the whole  header.

The  header isn't especially large, but avoiding it still gives
small savings in compilation time and memory usage for the compiler.

There are also C++11 features that could benefit from this change (e.g.
 and ) but I won't
change those until stage 1.

The implementation of __int_limits assumes two's complement integers,
which is true for all targets supported by GCC.

PR libstdc++/92546 (partial)
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/int_limits.h: New header.
* include/bits/parse_numbers.h (__select_int::_Select_int): Replace
numeric_limits with __detail::__int_limits.
* include/std/bit (__rotl, __rotr, __countl_zero, __countl_one)
(__countr_zero, __countr_one, __popcount, __ceil2, __floor2, __log2p1):
Likewise.
* include/std/charconv (__to_chars_8, __from_chars_binary)
(__from_chars_alpha_to_num, from_chars): Likewise.
* include/std/memory_resource (polymorphic_allocator::allocate)
(polymorphic_allocator::allocate_object): Likewise.
* include/std/string_view (basic_string_view::_S_compare): Likewise.
* include/std/utility (in_range): Likewise.
* testsuite/20_util/integer_comparisons/in_range_neg.cc: Adjust for
extra error about incomplete type __int_limits.
* testsuite/26_numerics/bit/bit.count/countl_one.cc: Include .
* testsuite/26_numerics/bit/bit.count/countl_zero.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/countr_one.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/countr_zero.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/popcount.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/ceil2_neg.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/ceil2.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/floor2.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/ispow2.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/log2p1.cc: Likewise.
* testsuite/26_numerics/bit/bit.rotate/rotl.cc: Likewise.
* testsuite/26_numerics/bit/bit.rotate/rotr.cc: Likewise.

Tested powerpc64le-linux, committed to master.


commit c03b53da9129ae2d5ac9629c4b874d0981a7d418
Author: Jonathan Wakely 
Date:   Mon Feb 17 14:30:02 2020 +

libstdc++: Add lightweight replacement for std::numeric_limits (PR 92546)

Many uses of std::numeric_limits in C++17 and C++20 features only really
need the min(), max() and digits constants for integral types. By adding
__detail::__int_limits we can avoid including the whole  header.

The  header isn't especially large, but avoiding it still gives
small savings in compilation time and memory usage for the compiler.

There are also C++11 features that could benefit from this change (e.g.
 and ) but I won't
change those until stage 1.

The implementation of __int_limits assumes two's complement integers,
which is true for all targets supported by GCC.

PR libstdc++/92546 (partial)
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/int_limits.h: New header.
* include/bits/parse_numbers.h (__select_int::_Select_int): Replace
numeric_limits with __detail::__int_limits.
* include/std/bit (__rotl, __rotr, __countl_zero, __countl_one)
(__countr_zero, __countr_one, __popcount, __ceil2, __floor2, 
__log2p1):
Likewise.
* include/std/charconv (__to_chars_8, __from_chars_binary)
(__from_chars_alpha_to_num, from_chars): Likewise.
* include/std/memory_resource (polymorphic_allocator::allocate)
(polymorphic_allocator::allocate_object): Likewise.
* include/std/string_view (basic_string_view::_S_compare): Likewise.
* include/std/utility (in_range): Likewise.
* testsuite/20_util/integer_comparisons/in_range_neg.cc: Adjust for
extra error about incomplete type __int_limits.
* testsuite/26_numerics/bit/bit.count/countl_one.cc: Include 
.
* testsuite/26_numerics/bit/bit.count/countl_zero.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/countr_one.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/countr_zero.cc: Likewise.
* testsuite/26_numerics/bit/bit.count/popcount.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/ceil2_neg.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/ceil2.cc: Likewise.
* testsuite/26_numerics/bit/bit.pow.two/floor2.cc: Likewise.
* testsuite/26_numerics/bit/b

Re: [PATCH] aarch64: Allow -mcpu=generic -march=armv8.5-a

[Richard Sandiford]

"Richard Earnshaw (lists)"  writes:
> On 14/02/2020 10:41, Andrew Pinski wrote:
>> On Fri, Feb 14, 2020 at 2:12 AM Richard Earnshaw (lists)
>>  wrote:
>>>
>>> On 14/02/2020 03:18, apin...@marvell.com wrote:
 From: Andrew Pinski 

 Right if someone supplies a -mcpu= option and then overrides
 that option with -march=*, we get a warning when they conflict.
 What we need is a generic cpu for each arch level but that is not
 that useful because the only difference would be the arch level.
 The best option is to allow -mcpu=generic -march=armv8.5-a not to
 warn and that is now a generic armv8.5-a arch.

>>>
>>> Then they should use -mtune=generic, rather than -mcpu.
>> 
>> Does it make sense to run:
>> "make check RUNTESTFLAGS="--target_board=unix/{,-mcpu=octeontx2}"
>> to make sure there are no latent bugs floating around with slightly
>> different tuning/scheduling?
>> The majority of the aarch64.exp failures are due to that warning.
>> If not how would suggest to test a -mcpu= option?
>> 
>> There is another use case:
>> A specific object file is to be run only on armv8.5-a processors but
>> someone sets CFLAGS to include -mcpu=octeontx2.
>> How would you suggest going about handling this case?
>> 
>> These are the two major cases where having a -mcpu=generic which
>> overrides a previous -mcpu= option and still able to select a higher
>> -march= option.
>> 
>
> -mcpu=generic should behave *exactly* the same way as specifying the CPU 
> you have, so to take an example, if your cpu is a Cortex-A72, then 
> -mcpu=generic and -mcpu=cortex-a72 should result in exactly the same 
> compiler output and diagnostics should be generated as if you'd 
> specified the latter.  Changing the behaviour just for generic therefore 
> does not make sense.

Are you sure?  That sounds more like -mcpu=native than -mcpu=generic.

AFAICT, -mcpu=generic always selects base Armv8 with generic tuning (i.e. the
default choice for default configure-time arguments).

It sounds like the use case here is to nullify the effect of a previous -mcpu,
a bit like "-mno-cpu" would if it was allowed.  If so, I guess that would need
to be a new option.  But could you test using:

"make check 
RUNTESTFLAGS="--target_board=unix/{,-march=armv8.2-a+.../-mtune=octeontx2}"

instead?  It's more awkward to specify, but probably easier than making sure
that the "-mno-cpu" equivalent is used in every test that needs it.

Thanks,
Richard

[committed] libstdc++: Reduce header dependencies for C++20 (PR 92546)

[Jonathan Wakely]

Another patch to reduce the size of preprocessed code in C++20, this
time reducing .

Tested powerpc64le-linux, committed to master.

commit 9cd4eeefcc641dd70d026e08e9d218101b826c52
Author: Jonathan Wakely 
Date:   Mon Feb 17 15:25:33 2020 +

libstdc++: Reduce header dependencies for C++20 (PR 92546)

In C++20  depends on  which
depends on  just for a single concept. Including
 also requires including , which is huge due to
the C++17 special functions.

This change moves the concept to the  internal
header that exists so that  doesn't need to include
.

PR libstdc++/92546 (partial)
* include/bits/random.h (uniform_random_bit_generator): Move definition
to .
* include/bits/ranges_algo.h: Include  instead
of .
* include/bits/ranges_algobase.h: Do not include .
* include/bits/uniform_int_dist.h (uniform_random_bit_generator):
Move here.
* include/std/ranges: Do not include .
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error lineno.

diff --git a/libstdc++-v3/include/bits/random.h b/libstdc++-v3/include/bits/random.h
index d4aebf45af0..19307fbc3ca 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -33,9 +33,6 @@
 
 #include 
 #include 
-#if __cplusplus > 201703L
-# include 
-#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -51,18 +48,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @{
*/
 
-#ifdef __cpp_lib_concepts
-  /// Requirements for a uniform random bit generator.
-  template
-concept uniform_random_bit_generator
-  = invocable<_Gen&> && unsigned_integral>
-  && requires
-  {
-	{ _Gen::min() } -> same_as>;
-	{ _Gen::max() } -> same_as>;
-	requires bool_constant<(_Gen::min() < _Gen::max())>::value;
-  };
-#endif
+  // std::uniform_random_bit_generator is defined in 
 
   /**
* @brief A function template for converting the output of a (integral)
diff --git a/libstdc++-v3/include/bits/ranges_algo.h b/libstdc++-v3/include/bits/ranges_algo.h
index ff1b40f6ace..f3a349ef839 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -33,7 +33,7 @@
 #if __cplusplus > 201703L
 
 #include 
-#include  // concept uniform_random_bit_generator
+#include  // concept uniform_random_bit_generator
 
 #if __cpp_lib_concepts
 namespace std _GLIBCXX_VISIBILITY(default)
diff --git a/libstdc++-v3/include/bits/ranges_algobase.h b/libstdc++-v3/include/bits/ranges_algobase.h
index cc24483b2d3..eedd29f570a 100644
--- a/libstdc++-v3/include/bits/ranges_algobase.h
+++ b/libstdc++-v3/include/bits/ranges_algobase.h
@@ -32,7 +32,6 @@
 
 #if __cplusplus > 201703L
 
-#include 
 #include 
 #include 
 // #include 
diff --git a/libstdc++-v3/include/bits/uniform_int_dist.h b/libstdc++-v3/include/bits/uniform_int_dist.h
index d2a01570635..e3d7934e997 100644
--- a/libstdc++-v3/include/bits/uniform_int_dist.h
+++ b/libstdc++-v3/include/bits/uniform_int_dist.h
@@ -33,11 +33,27 @@
 
 #include 
 #include 
+#if __cplusplus > 201703L
+# include 
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+#ifdef __cpp_lib_concepts
+  /// Requirements for a uniform random bit generator.
+  template
+concept uniform_random_bit_generator
+  = invocable<_Gen&> && unsigned_integral>
+  && requires
+  {
+	{ _Gen::min() } -> same_as>;
+	{ _Gen::max() } -> same_as>;
+	requires bool_constant<(_Gen::min() < _Gen::max())>::value;
+  };
+#endif
+
   namespace __detail
   {
 /* Determine whether number is a power of 2.  */
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 970e904bddd..b9ac528fdff 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc b/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
index 91e5566c54a..f808132e9ea 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
@@ -10,6 +10,6 @@ std::__detail::_Adaptor aurng(urng);
 auto x = std::generate_canonical::digits>(urng);
 
-// { dg-error "static assertion failed: template argument must be a floating point type" "" { target *-*-* } 172 }
+// { dg-error "static assertion failed: template argument must be a floating point type" "" { target *-*-* } 158 }
 
 // { dg-error "static assertion failed: template argument must be a floating point type" "" { target *-*-* } 3281 }

Re: [PATCH] aarch64: Allow -mcpu=generic -march=armv8.5-a

[Richard Earnshaw (lists)]

On 17/02/2020 15:42, Richard Sandiford wrote:

"Richard Earnshaw (lists)"  writes:

On 14/02/2020 10:41, Andrew Pinski wrote:

On Fri, Feb 14, 2020 at 2:12 AM Richard Earnshaw (lists)
 wrote:


On 14/02/2020 03:18, apin...@marvell.com wrote:

From: Andrew Pinski 

Right if someone supplies a -mcpu= option and then overrides
that option with -march=*, we get a warning when they conflict.
What we need is a generic cpu for each arch level but that is not
that useful because the only difference would be the arch level.
The best option is to allow -mcpu=generic -march=armv8.5-a not to
warn and that is now a generic armv8.5-a arch.



Then they should use -mtune=generic, rather than -mcpu.


Does it make sense to run:
"make check RUNTESTFLAGS="--target_board=unix/{,-mcpu=octeontx2}"
to make sure there are no latent bugs floating around with slightly
different tuning/scheduling?
The majority of the aarch64.exp failures are due to that warning.
If not how would suggest to test a -mcpu= option?

There is another use case:
A specific object file is to be run only on armv8.5-a processors but
someone sets CFLAGS to include -mcpu=octeontx2.
How would you suggest going about handling this case?

These are the two major cases where having a -mcpu=generic which
overrides a previous -mcpu= option and still able to select a higher
-march= option.



-mcpu=generic should behave *exactly* the same way as specifying the CPU
you have, so to take an example, if your cpu is a Cortex-A72, then
-mcpu=generic and -mcpu=cortex-a72 should result in exactly the same
compiler output and diagnostics should be generated as if you'd
specified the latter.  Changing the behaviour just for generic therefore
does not make sense.


Are you sure?  That sounds more like -mcpu=native than -mcpu=generic.

AFAICT, -mcpu=generic always selects base Armv8 with generic tuning (i.e. the
default choice for default configure-time arguments).

It sounds like the use case here is to nullify the effect of a previous -mcpu,
a bit like "-mno-cpu" would if it was allowed.  If so, I guess that would need
to be a new option.  But could you test using:

"make check 
RUNTESTFLAGS="--target_board=unix/{,-march=armv8.2-a+.../-mtune=octeontx2}"

instead?  It's more awkward to specify, but probably easier than making sure
that the "-mno-cpu" equivalent is used in every test that needs it.

Thanks,
Richard



My apologies, yes, you're right.  I was thinking about 'native' rather 
than generic.


However, the real problem is that -mcpu=generic is (and always has been) 
misnamed.  Generic what?  What it should have is an architecture version 
in the name directly, so generic-armv8-a, generic-armv8.1-a, etc.


R.

[committed] libstdc++: Add comment to explaining C++14 status

[Jonathan Wakely]

This header is intentionally valid in C++14 mode, because no conforming
C++14 program will try to include  and so it's OK to add new
(non-reserved in C++14) names to namespace std. However, other headers
must not include  transitively prior to C++17, so that we
don't add those non-reserved names without the user requesting it.

This adds a comment to the header explaining that.

* include/std/charconv: Add comment.

Tested powerpc64le-linux, committed to master.

commit cfbc8fbb37e7b406ab2567ac35629793d4b499e7
Author: Jonathan Wakely 
Date:   Mon Feb 17 15:44:03 2020 +

libstdc++: Add comment to  explaining C++14 status

This header is intentionally valid in C++14 mode, because no conforming
C++14 program will try to include  and so it's OK to add new
(non-reserved in C++14) names to namespace std. However, other headers
must not include  transitively prior to C++17, so that we
don't add those non-reserved names without the user requesting it.

This adds a comment to the header explaining that.

* include/std/charconv: Add comment.

diff --git a/libstdc++-v3/include/std/charconv 
b/libstdc++-v3/include/std/charconv
index 9b5a1f7cab8..ff7dfa12268 100644
--- a/libstdc++-v3/include/std/charconv
+++ b/libstdc++-v3/include/std/charconv
@@ -31,6 +31,10 @@
 
 #pragma GCC system_header
 
+// As an extension we support  in C++14, but this header should not
+// be included by any other library headers in C++14 mode. This ensures that
+// the names defined in this header are not added to namespace std unless a
+// user explicitly includes  in C++14 code.
 #if __cplusplus >= 201402L
 
 #include 

Re: [committed] libstdc++: Add lightweight replacement for std::numeric_limits (PR 92546)

[Daniel Krügler]

Am Mo., 17. Feb. 2020 um 16:33 Uhr schrieb Jonathan Wakely :
>
> Many uses of std::numeric_limits in C++17 and C++20 features only really
> need the min(), max() and digits constants for integral types. By adding
> __detail::__int_limits we can avoid including the whole  header.

numeric_limits has specializations for cv-qualified types, but for
__ini_limits there is only an undefined specialization for bool.
Shouldn't the same undefined specialization be provided for cv bool?
It may be that currently all usages of that trait apply on already
unqualified types, but this might be a fragile assumption.

- Daniel

[committed] libstdc++ P1956R1 On the names of low-level bit manipulation functions

[Jonathan Wakely]

Implement this change for C++20 that was just approved in Prague.

P1956R1 On the names of low-level bit manipulation functions
* include/bits/hashtable_policy.h: Update comment.
* include/std/bit (__ispow2, __ceil2, __floor2, __log2p1): Rename.
(ispow2, ceil2, floor2, log2p1): Likewise.
(__cpp_lib_int_pow2): Add feature test macro.
* include/std/charconv (__to_chars_len_2): Adjust use of __log2p1.
* include/std/memory (assume_aligned): Adjust use of ispow2.
* include/std/version (__cpp_lib_int_pow2): Add.
* libsupc++/new_opa.cc: Adjust use of __ispow2.
* src/c++17/memory_resource.cc: Likewise, and for __ceil2 and __log2p1.
* testsuite/17_intro/freestanding.cc: Adjust use of ispow2.
* testsuite/26_numerics/bit/bit.pow.two/ceil2.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/bit_ceil.cc: ... here.
* testsuite/26_numerics/bit/bit.pow.two/ceil2_neg.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/bit_ceil_neg.cc: ... here.
* testsuite/26_numerics/bit/bit.pow.two/floor2.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/bit_floor.cc: ... here.
* testsuite/26_numerics/bit/bit.pow.two/log2p1.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/bit_width.cc: ... here.
* testsuite/26_numerics/bit/bit.pow.two/ispow2.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/has_single_bit.cc: ... here.

Tested powerpc64le-linux, committed to master.

commit 9866abe31ec47f493ff40f525ad970bb60906c4b
Author: Jonathan Wakely 
Date:   Mon Feb 17 16:03:48 2020 +

libstdc++ P1956R1 On the names of low-level bit manipulation functions

Implement this change for C++20 that was just approved in Prague.

P1956R1 On the names of low-level bit manipulation functions
* include/bits/hashtable_policy.h: Update comment.
* include/std/bit (__ispow2, __ceil2, __floor2, __log2p1): Rename.
(ispow2, ceil2, floor2, log2p1): Likewise.
(__cpp_lib_int_pow2): Add feature test macro.
* include/std/charconv (__to_chars_len_2): Adjust use of __log2p1.
* include/std/memory (assume_aligned): Adjust use of ispow2.
* include/std/version (__cpp_lib_int_pow2): Add.
* libsupc++/new_opa.cc: Adjust use of __ispow2.
* src/c++17/memory_resource.cc: Likewise, and for __ceil2 and 
__log2p1.
* testsuite/17_intro/freestanding.cc: Adjust use of ispow2.
* testsuite/26_numerics/bit/bit.pow.two/ceil2.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/bit_ceil.cc: ... here.
* testsuite/26_numerics/bit/bit.pow.two/ceil2_neg.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/bit_ceil_neg.cc: ... here.
* testsuite/26_numerics/bit/bit.pow.two/floor2.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/bit_floor.cc: ... here.
* testsuite/26_numerics/bit/bit.pow.two/log2p1.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/bit_width.cc: ... here.
* testsuite/26_numerics/bit/bit.pow.two/ispow2.cc: Rename to ...
* testsuite/26_numerics/bit/bit.pow.two/has_single_bit.cc: ... here.

diff --git a/libstdc++-v3/include/bits/hashtable_policy.h 
b/libstdc++-v3/include/bits/hashtable_policy.h
index 4024e6c37fa..22bc4472e32 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -508,7 +508,7 @@ namespace __detail
   inline std::size_t
   __clp2(std::size_t __n) noexcept
   {
-// Equivalent to return __n ? std::ceil2(__n) : 0;
+// Equivalent to return __n ? std::bit_ceil(__n) : 0;
 if (__n < 2)
   return __n;
 const unsigned __lz = sizeof(size_t) > sizeof(long)
diff --git a/libstdc++-v3/include/std/bit b/libstdc++-v3/include/std/bit
index dc0a77e1a5f..69e955458f3 100644
--- a/libstdc++-v3/include/std/bit
+++ b/libstdc++-v3/include/std/bit
@@ -211,12 +211,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 constexpr bool
-__ispow2(_Tp __x) noexcept
+__has_single_bit(_Tp __x) noexcept
 { return std::__popcount(__x) == 1; }
 
   template
 constexpr _Tp
-__ceil2(_Tp __x) noexcept
+__bit_ceil(_Tp __x) noexcept
 {
   using std::__detail::__int_limits;
   constexpr auto _Nd = __int_limits<_Tp>::digits;
@@ -249,7 +249,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 constexpr _Tp
-__floor2(_Tp __x) noexcept
+__bit_floor(_Tp __x) noexcept
 {
   constexpr auto _Nd = __detail::__int_limits<_Tp>::digits;
   if (__x == 0)
@@ -259,7 +259,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 constexpr _Tp
-__log2p1(_Tp __x) noexcept
+__bit_width(_Tp __x) noexcept
 {
   constexpr auto _Nd = __detail::__int_limits<_Tp>::digits;
   return _Nd - 

Re: [committed] libstdc++: Add lightweight replacement for std::numeric_limits (PR 92546)

[Jonathan Wakely]

On 17/02/20 17:26 +0100, Daniel Krügler wrote:

Am Mo., 17. Feb. 2020 um 16:33 Uhr schrieb Jonathan Wakely :


Many uses of std::numeric_limits in C++17 and C++20 features only really
need the min(), max() and digits constants for integral types. By adding
__detail::__int_limits we can avoid including the whole  header.


numeric_limits has specializations for cv-qualified types, but for
__ini_limits there is only an undefined specialization for bool.
Shouldn't the same undefined specialization be provided for cv bool?
It may be that currently all usages of that trait apply on already
unqualified types, but this might be a fragile assumption.


The specialization for bool is only there to catch misuses by the
library, it's not really necessary. But I agree that also catching
errors for const bool makes sense. I don't think we need to care about
volatile.

I'm tempted to make __int_limits an error though, it's not
needed.

Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Sat, 15 Feb 2020, Maciej W. Rozycki wrote:

> > > Thank you, Mike, for your input.  That is what v1 did, but it seems to 
> > > clash with some people's expectations, as discussed here:
> > > 
> > > 
> > 
> > I didn't see any clash with expectations.  They expect in the build tree 
> > testing to work, they expect install testing to work.  I expect both, 
> > you expect both; I just don't think we differ on this.  Where I think 
> > things went wrong is there is a change to their testing environment that 
> > you didn't fully account for in your patch. You didn't intend to break 
> > it, but there is just a little more work to be done to not break it, 
> > that's all.

 FAOD the clash with expectations is in that you want a fix in `site.exp' 
while Chung-Lin wants one outside `site.exp'.  The status quo does not 
clash with either of you, but it does not meet my requirements, though I 
don't care where the fix goes.  I hope this makes things clear here.

  Maciej

Re: [PATCH] avoid user-constructible types in reshape_init_array (PR 90938)

[Jason Merrill]

On 2/14/20 9:06 PM, Martin Sebor wrote:

On 2/13/20 3:59 PM, Jason Merrill wrote:

On 2/12/20 9:21 PM, Martin Sebor wrote:

On 2/11/20 5:28 PM, Jason Merrill wrote:

On 2/11/20 9:00 PM, Martin Sebor wrote:

r270155, committed in GCC 9, introduced a transformation that strips
redundant trailing zero initializers from array initializer lists in
order to support string literals as template arguments.

The transformation neglected to consider the case of array elements
of trivial class types with user-defined conversion ctors and either
defaulted or deleted default ctors.  (It didn't occur to me that
those qualify as trivial types despite the user-defined ctors.)  As
a result, some valid initialization expressions are rejected when
the explicit zero-initializers are dropped in favor of the (deleted)
default ctor,


Hmm, a type with only a deleted default constructor is not trivial, 
that should have been OK already.


For Marek's test case:
   struct A { A () == delete; A (int) = delete; };

trivial_type_p() returns true (as does __is_trivial (A) in both GCC
and Clang).

[class.prop] says that

   A trivial class is a class that is trivially copyable and has one
   or more default constructors (10.3.4.1), all of which are either
   trivial or deleted and at least one of which is not deleted.

That sounds like A above is not trivial because it doesn't have
at least one default ctor that's not deleted, but both GCC and
Clang say it is.  What am I missing?  Is there some other default
constructor hiding in there that I don't know about?


and others are eliminated in favor of the defaulted
ctor instead of invoking a user-defined conversion ctor, leading to
wrong code.


This seems like a bug in type_initializer_zero_p; it shouldn't treat 
0 as a zero initializer for any class.


That does fix it, and it seems like the right solution to me as well.
Thanks for the suggestion.  I'm a little unsure about the condition
I put in place though.

Attached is an updated patch rested on x86_64-linux.



-  if (sized_array_p && trivial_type_p (elt_type))
+  if (sized_array_p
+  && trivial_type_p (elt_type)
+  && !TYPE_NEEDS_CONSTRUCTING (elt_type))


Do we still need this change?  If so, please add a comment about the 
trivial_type_p bug.


The change isn't needed with my patch as it was, but it would still
be needed with the changes you suggested (even then it doesn't help
with the problem I describe below).




   if (TREE_CODE (init) != CONSTRUCTOR

I might change this to

  if (!CP_AGGREGATE_TYPE_P (type))
    return initializer_zerop (init);


This behaves differently in C++ 2a mode (the whole condition evaluates
to true for class A below) than in earlier modes and causes a failure
in the new array55.C test:


True, my suggestion above does the wrong thing for non-aggregate classes.


+  /* A class can only be initialized by a non-class type if it has
+a ctor that converts from that type.  Such classes are excluded
+since their semantics are unknown.  */
+  if (RECORD_OR_UNION_TYPE_P (type)
+ && !RECORD_OR_UNION_TYPE_P (TREE_TYPE (init)))
+   return false;


How about if (!SCALAR_TYPE_P (type)) here?

More broadly, it seems like doing this optimization here at all is 
questionable, since we don't yet know whether there's a valid conversion 
from the zero-valued initializer to the element type.  It would seem 
better to do it in process_init_constructor_array after the call to 
massage_init_elt, when we know the actual value of the element.


Jason

Re: [PATCH] aarch64: Allow -mcpu=generic -march=armv8.5-a

[Andrew Pinski]

On Mon, Feb 17, 2020 at 7:56 AM Richard Earnshaw (lists)
 wrote:
>
> On 17/02/2020 15:42, Richard Sandiford wrote:
> > "Richard Earnshaw (lists)"  writes:
> >> On 14/02/2020 10:41, Andrew Pinski wrote:
> >>> On Fri, Feb 14, 2020 at 2:12 AM Richard Earnshaw (lists)
> >>>  wrote:
> 
>  On 14/02/2020 03:18, apin...@marvell.com wrote:
> > From: Andrew Pinski 
> >
> > Right if someone supplies a -mcpu= option and then overrides
> > that option with -march=*, we get a warning when they conflict.
> > What we need is a generic cpu for each arch level but that is not
> > that useful because the only difference would be the arch level.
> > The best option is to allow -mcpu=generic -march=armv8.5-a not to
> > warn and that is now a generic armv8.5-a arch.
> >
> 
>  Then they should use -mtune=generic, rather than -mcpu.
> >>>
> >>> Does it make sense to run:
> >>> "make check RUNTESTFLAGS="--target_board=unix/{,-mcpu=octeontx2}"
> >>> to make sure there are no latent bugs floating around with slightly
> >>> different tuning/scheduling?
> >>> The majority of the aarch64.exp failures are due to that warning.
> >>> If not how would suggest to test a -mcpu= option?
> >>>
> >>> There is another use case:
> >>> A specific object file is to be run only on armv8.5-a processors but
> >>> someone sets CFLAGS to include -mcpu=octeontx2.
> >>> How would you suggest going about handling this case?
> >>>
> >>> These are the two major cases where having a -mcpu=generic which
> >>> overrides a previous -mcpu= option and still able to select a higher
> >>> -march= option.
> >>>
> >>
> >> -mcpu=generic should behave *exactly* the same way as specifying the CPU
> >> you have, so to take an example, if your cpu is a Cortex-A72, then
> >> -mcpu=generic and -mcpu=cortex-a72 should result in exactly the same
> >> compiler output and diagnostics should be generated as if you'd
> >> specified the latter.  Changing the behaviour just for generic therefore
> >> does not make sense.
> >
> > Are you sure?  That sounds more like -mcpu=native than -mcpu=generic.
> >
> > AFAICT, -mcpu=generic always selects base Armv8 with generic tuning (i.e. 
> > the
> > default choice for default configure-time arguments).
> >
> > It sounds like the use case here is to nullify the effect of a previous 
> > -mcpu,
> > a bit like "-mno-cpu" would if it was allowed.  If so, I guess that would 
> > need
> > to be a new option.  But could you test using:
> >
> > "make check 
> > RUNTESTFLAGS="--target_board=unix/{,-march=armv8.2-a+.../-mtune=octeontx2}"
> >
> > instead?  It's more awkward to specify, but probably easier than making sure
> > that the "-mno-cpu" equivalent is used in every test that needs it.
> >
> > Thanks,
> > Richard
> >
>
> My apologies, yes, you're right.  I was thinking about 'native' rather
> than generic.
>
> However, the real problem is that -mcpu=generic is (and always has been)
> misnamed.  Generic what?  What it should have is an architecture version
> in the name directly, so generic-armv8-a, generic-armv8.1-a, etc.

Then how about we add those (keeping generic as ARMv8-a though).  Is
adding those a good idea?
Something like:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index b58aca652b2..d9e42c790f8 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1278,6 +1278,10 @@ static const struct processor all_cores[] =
 #include "aarch64-cores.def"
   {"generic", generic, cortexa53, AARCH64_ARCH_8A, 8,
 AARCH64_FL_FOR_ARCH8, &generic_tunings},
+#define AARCH64_ARCH(NAME, CORE, ARCH_IDENT, ARCH_REV, FLAGS) \
+  {"generic-" NAME, CORE, cortexa53, AARCH64_ARCH_##ARCH_IDENT, \
+  ARCH_REV, FLAGS, &generic_tunings },
+#include "aarch64-arches.def"
   {NULL, aarch64_none, aarch64_none, aarch64_no_arch, 0, 0, NULL}
 };

Will add "generic-armv8.1-a", etc.  And then we can use that in the testsuite.

Thanks,
Andrew Pinski


Thanks,
Andrew Pinski

>
> R.

[GCC][PATCH][AArch64] Add bfloat16 vdup and vreinterpret ACLE intrinsics

[Mihail Ionescu]

Hi,

This patch adds support for the bf16 duplicate and reinterpret intrinsics.
ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Regression tested on aarch64-none-linux-gnu.


Is it ok for trunk?


gcc/ChangeLog:

2020-02-17  Mihail Ionescu  

* config/aarch64/iterators.md (VDQF_F16) Add V4BF and V8BF.
(VALL_F16): Likewise.
(VALLDI_F16): Likewise.
(Vtype): Likewise.
(Vetype): Likewise.
(vswap_width_name): Likewise.
(VSWAP_WIDTH): Likewise.
(Vel): Likewise.
(VEL): Likewise.
(q): Likewise.
* config/aarch64/aarch64-simd.md
(vec_init): Add vector init pattern for bf16.
(aarch64_simd_dup): Change pattern iterator to include bf16.
(aarch64_dup_lane): Likewise.
(aarch64_get_lane): Likewise.
(vec_extract): Likewise.
* config/aarch64/arm_bf16.h
(vset_lane_bf16, vsetq_lane_bf16): New.
(vget_lane_bf16, vgetq_lane_bf16): New.
(vcreate_bf16): New.
(vdup_n_bf16, vdupq_n_bf16): New.
(vdup_lane_bf16, vdup_laneq_bf16): New.
(vdupq_lane_bf16, vdupq_laneq_bf16): New.
(vduph_lane_bf16, vduph_laneq_bf16): New.
(vreinterpret_bf16_u8, vreinterpretq_bf16_u8): New.
(vreinterpret_bf16_u16, vreinterpretq_bf16_u16): New.
(vreinterpret_bf16_u32, vreinterpretq_bf16_u32): New.
(vreinterpret_bf16_u64, vreinterpretq_bf16_u64): New.
(vreinterpret_bf16_s8, vreinterpretq_bf16_s8): New.
(vreinterpret_bf16_s16, vreinterpretq_bf16_s16): New.
(vreinterpret_bf16_s32, vreinterpretq_bf16_s32): New.
(vreinterpret_bf16_s64, vreinterpretq_bf16_s64): New.
(vreinterpret_bf16_p8, vreinterpretq_bf16_p8): New.
(vreinterpret_bf16_p16, vreinterpretq_bf16_p16): New.
(vreinterpret_bf16_p64, vreinterpretq_bf16_p64): New
(vreinterpret_bf16_f16, vreinterpretq_bf16_f16): New
(vreinterpret_bf16_f32, vreinterpretq_bf16_f32): New.
(vreinterpret_bf16_f64, vreinterpretq_bf16_f64): New.
(vreinterpretq_bf16_p128): New.
(vreinterpret_s8_bf16, vreinterpretq_s8_bf16): New.
(vreinterpret_s16_bf16, vreinterpretq_s16_bf16): New.
(vreinterpret_s32_bf16, vreinterpretq_s32_bf16): New.
(vreinterpret_s64_bf16, vreinterpretq_s64_bf16): New.
(vreinterpret_u8_bf16, vreinterpretq_u8_bf16): New.
(vreinterpret_u16_bf16, vreinterpretq_u16_bf16): New.
(vreinterpret_u32_bf16, vreinterpretq_u32_bf16): New.
(vreinterpret_u64_bf16, vreinterpretq_u64_bf16): New.
(vreinterpret_p8_bf16, vreinterpretq_p8_bf16): New.
(vreinterpret_p16_bf16, vreinterpretq_p16_bf16): New.
(vreinterpret_p64_bf16, vreinterpretq_p64_bf16): New.
(vreinterpret_f32_bf16, vreinterpretq_f32_bf16): New.
(vreinterpret_f64_bf16,vreinterpretq_f64_bf16): New.
(vreinterpret_f16_bf16,vreinterpretq_f16_bf16): New.
(vreinterpretq_p128_bf16): New.


gcc/testsuite/ChangeLog:

2020-02-17  Mihail Ionescu  

* gcc.target/aarch64/advsimd-intrinsics/bf16_dup.c: New test.
* gcc.target/aarch64/advsimd-intrinsics/bf16_reinterpret.c: New test.

Regards,
Mihail


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 
7f05c3f9eca844b0e7b824a191223a4906c825b1..3cc3ace83fabf25d8e2e6e70382d335afd974290
 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -34614,6 +34614,507 @@ vrnd64xq_f64 (float64x2_t __a)
 #pragma GCC push_options
 #pragma GCC target ("arch=armv8.2-a+bf16")
 
+__extension__ extern __inline bfloat16x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vset_lane_bf16 (bfloat16_t __elem, bfloat16x4_t __vec, const int __index)
+{
+  return __aarch64_vset_lane_any (__elem, __vec, __index);
+}
+
+__extension__ extern __inline bfloat16x8_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vsetq_lane_bf16 (bfloat16_t __elem, bfloat16x8_t __vec, const int __index)
+{
+  return __aarch64_vset_lane_any (__elem, __vec, __index);
+}
+
+__extension__ extern __inline bfloat16_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vget_lane_bf16 (bfloat16x4_t __a, const int __b)
+{
+  return __aarch64_vget_lane_any (__a, __b);
+}
+
+__extension__ extern __inline bfloat16_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vgetq_lane_bf16 (bfloat16x8_t __a, const int __b)
+{
+  return __aarch64_vget_lane_any (__a, __b);
+}
+
+__extension__ extern __inline bfloat16x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcreate_bf16 (uint64_t __a)
+{
+  return (bfloat16x4_t) __a;
+}
+
+/* vdup */
+
+__extension__ extern __inline bfloat16x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, 

[GCC][PATCH][AArch64] Add bfloat16 vldn/vstn intrinsics

[Mihail Ionescu]

Hi,

This patch adds the load/store bfloat16 intrinsics to the AArch64 back-end.
ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Regression tested on aarch64-none-linux-gnu.

Is it ok for trunk?

gcc/ChangeLog:

2020-02-17  Mihail Ionescu  

* config/aarch64/aarch64-builtins.c (aarch64_scalar_builtin_types):
Add simd_bf.
(aarch64_init_simd_builtin_scalar_types): Register simd_bf.
(VAR14, VAR15): New.
* config/aarch64/iterators.md
(VDC): Enable for V4BF and V8BF.
(VALLDIF): Likewise.
(V_INT_EQUIV, v_int_equiv): Likewise.
(VD): Enable for V4BF.
(VQ): Enable for V8BF.
(VQ2): Enable for V8BF.
(VQ_NO2E): Enable for V8BF.
(VDBL): Add V4BF.
(Vdbl): Likewise.
* config/aarch64/arm_bf16.h (bfloat16_t): New typedef.
(bfloat16x4x2_t): Likewise.
(bfloat16x8x2_t): Likewise.
(bfloat16x4x3_t): Likewise.
(bfloat16x8x3_t): Likewise.
(bfloat16x4x4_t): Likewise.
(bfloat16x8x4_t): Likewise.
(vcombine_bf16): New.
(vld1_bf16,vld1_bf16_x2): New.
(vld1_bf16_x3, vld1_bf16_x4): New.
(vld1q_bf16,vld1q_bf16_x2): New.
(vld1q_bf16_x3, vld1q_bf16_x4): New.
(vld1_lane_bf16): New.
(vld1q_lane_bf16): New.
(vld1_dup_bf16): New.
(vld1q_dup_bf16): New.
(vld2_bf16): New.
(vld2q_bf16): New.
(vld2_dup_bf16): New.
(vld2q_dup_bf16): New.
(vld3_bf16): New.
(vld3q_bf16): New.
(vld3_dup_bf16): New.
(vld3q_dup_bf16): New.
(vld4_bf16): New.
(vld4q_bf16): New.
(vld4_dup_bf16): New.
(vld4q_dup_bf16): New.
(vst1_bf16, vst1_bf16_x2): New.
(vst1_bf16_x3, vst1_bf16_x4): New.
(vst1q_bf16, vst1q_bf16_x2): New.
(vst1q_bf16_x3, vst1q_bf16_x4): New.
(vst1_lane_bf16): New.
(vst1q_lane_bf16): New.
(vst2_bf16): New.
(vst2q_bf16): New.
(vst3_bf16): New.
(vst3q_bf16): New.
(vst4_bf16): New.
(vst4q_bf16): New.
(vld2_bf16): New.
(vld2q_bf16): New.
(vld3_bf16): New.
(vld3q_bf16): New.
(vld4_bf16): New.
(vld4q_bf16): New.


gcc/testsuite/ChangeLog:

2020-02-17  Mihail Ionescu  

* gcc.target/arm/simd/bf16_stn_1.c: New test.
* gcc.target/arm/simd/bf16_ldn_1.c: New test.


Regards,
Mihail


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/aarch64/aarch64-builtins.c 
b/gcc/config/aarch64/aarch64-builtins.c
index 
33245e4b87934b783ccfe5c8512ba375ba80b329..74fcce8355038993fb66986ce5385d6b4ee1f0c6
 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -370,6 +370,12 @@ 
aarch64_types_storestruct_lane_qualifiers[SIMD_MAX_BUILTIN_ARGS]
 #define VAR14(T, X, MAP, A, B, C, D, E, F, G, H, I, J, K, L, M, N) \
   VAR13 (T, X, MAP, A, B, C, D, E, F, G, H, I, J, K, L, M) \
   VAR1 (T, X, MAP, N)
+#define VAR15(T, X, MAP, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O) \
+  VAR14 (T, X, MAP, A, B, C, D, E, F, G, H, I, J, K, L, M, N) \
+  VAR1 (T, X, MAP, O)
+#define VAR16(T, X, MAP, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P) \
+  VAR15 (T, X, MAP, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O) \
+  VAR1 (T, X, MAP, P)
 
 #include "aarch64-builtin-iterators.h"
 
@@ -534,6 +540,7 @@ const char *aarch64_scalar_builtin_types[] = {
   "__builtin_aarch64_simd_oi",
   "__builtin_aarch64_simd_ci",
   "__builtin_aarch64_simd_xi",
+  "__builtin_aarch64_simd_bf",
   NULL
 };
 
@@ -847,6 +854,8 @@ aarch64_init_simd_builtin_scalar_types (void)
 "__builtin_aarch64_simd_poly128");
   (*lang_hooks.types.register_builtin_type) (intTI_type_node,
 "__builtin_aarch64_simd_ti");
+  (*lang_hooks.types.register_builtin_type) (aarch64_bf16_type_node,
+"__builtin_aarch64_simd_bf");
   /* Unsigned integer types for various mode sizes.  */
   (*lang_hooks.types.register_builtin_type) (unsigned_intQI_type_node,
 "__builtin_aarch64_simd_uqi");
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 
34553f7c20a7beba9e569479a18795ebacc7c805..486e460f01167379cf92c171b2cda7952bf1f6a0
 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -76,6 +76,36 @@ typedef double float64_t;
 typedef __Bfloat16x4_t bfloat16x4_t;
 typedef __Bfloat16x8_t bfloat16x8_t;
 
+typedef struct bfloat16x4x2_t
+{
+  bfloat16x4_t val[2];
+} bfloat16x4x2_t;
+
+typedef struct bfloat16x8x2_t
+{
+  bfloat16x8_t val[2];
+} bfloat16x8x2_t;
+
+typedef struct bfloat16x4x3_t
+{
+  bfloat16x4_t val[3];
+} bfloat16x4x3_t;
+
+typedef struct bfloat16x8x3_t
+{
+  

[committed] libstdc++: P1970R2 Consistency for size() functions: Add ranges::ssize

[Jonathan Wakely]

This defines ranges::ssize as approved in Prague. It's unclear what is
supposed to happen for types for which range_difference_t is not a valid
type. I've assumed they are not meant to be usable with ranges::ssize,
despite being usable with ranges::size.

* include/bits/range_access.h (_SSize, ssize): Define for C++20.
* testsuite/std/ranges/access/ssize.cc: New test.

Tested powerpc64le-linux, committed to master.


commit 7ab36231a17d8a78f4355289ebbd9d32bb8ede7b
Author: Jonathan Wakely 
Date:   Mon Feb 17 17:58:09 2020 +

libstdc++: P1970R2 Consistency for size() functions: Add ranges::ssize

This defines ranges::ssize as approved in Prague. It's unclear what is
supposed to happen for types for which range_difference_t is not a valid
type. I've assumed they are not meant to be usable with ranges::ssize,
despite being usable with ranges::size.

* include/bits/range_access.h (_SSize, ssize): Define for C++20.
* testsuite/std/ranges/access/ssize.cc: New test.

diff --git a/libstdc++-v3/include/bits/range_access.h 
b/libstdc++-v3/include/bits/range_access.h
index 8b546a58840..8bac0efc6ed 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -35,6 +35,7 @@
 #if __cplusplus >= 201103L
 #include 
 #include 
+#include 
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -723,6 +724,32 @@ namespace ranges
}
 };
 
+struct _SSize
+{
+  template
+   requires requires (_Tp&& __e)
+ {
+   _Begin{}(std::forward<_Tp>(__e));
+   _Size{}(std::forward<_Tp>(__e));
+ }
+   constexpr auto
+   operator()(_Tp&& __e) const
+   noexcept(noexcept(_Size{}(std::forward<_Tp>(__e
+   {
+ using __iter_type = decltype(_Begin{}(std::forward<_Tp>(__e)));
+ using __diff_type = iter_difference_t<__iter_type>;
+ using std::__detail::__int_limits;
+ auto __size = _Size{}(std::forward<_Tp>(__e));
+ if constexpr (integral<__diff_type>)
+   {
+ if constexpr (__int_limits<__diff_type>::digits
+   < __int_limits::digits)
+   return static_cast(__size);
+   }
+ return static_cast<__diff_type>(__size);
+   }
+};
+
 template
   concept __member_empty = requires(_Tp&& __t)
{ bool(std::forward<_Tp>(__t).empty()); };
@@ -834,6 +861,7 @@ namespace ranges
 inline constexpr __cust_access::_CRBegin crbegin{};
 inline constexpr __cust_access::_CREnd crend{};
 inline constexpr __cust_access::_Size size{};
+inline constexpr __cust_access::_SSize ssize{};
 inline constexpr __cust_access::_Empty empty{};
 inline constexpr __cust_access::_Data data{};
 inline constexpr __cust_access::_CData cdata{};
diff --git a/libstdc++-v3/testsuite/std/ranges/access/ssize.cc 
b/libstdc++-v3/testsuite/std/ranges/access/ssize.cc
new file mode 100644
index 000..5aa05be8f20
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/access/ssize.cc
@@ -0,0 +1,98 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+#include 
+
+using std::ptrdiff_t;
+
+void
+test01()
+{
+  constexpr int a[10] = { };
+  static_assert( std::same_as );
+  static_assert( std::ranges::ssize(a) == 10 );
+  static_assert( noexcept(std::ranges::ssize(a)) );
+
+  int a2[2];
+  static_assert( std::same_as );
+  VERIFY( std::ranges::ssize(a2) == 2);
+  static_assert( noexcept(std::ranges::ssize(a2)) );
+
+  struct Incomplete;
+  using A = Incomplete[2]; // bounded array of incomplete type
+  extern A& f();
+  static_assert( std::same_as );
+}
+
+void
+test02()
+{
+  int a[3] = { };
+  __gnu_test::test_sized_range ri(a);
+  VERIFY( std::ranges::ssize(ri) == 3 );
+  static_assert( noexcept(std::ranges::ssize(ri)) );
+}
+
+void
+test04()
+{
+  int a[] = { 0, 1 };
+  __gnu_test::test_range r(a);
+  VERIFY( std::ranges::ssize(r) == std::ranges::end(r) - std::ranges::begin(r) 
);
+}
+
+struct R5
+{
+  int size() const noexcept { return 0; }
+  R5* begin() { return this; }
+  R5* end() { return this + 1; }
+};
+
+template<>
+constexpr bool std::ranges

[committed] libstdc++: P1964R2 Wording for boolean-testable

[Jonathan Wakely]

This removes the complicated std::boolean concept, as agreed in Prague.

* include/bits/ranges_algo.h (__find_fn, __find_first_of_fn)
(__adjacent_find_fn): Cast result of predicate to bool.
* include/std/concepts (__boolean): Remove.
(__detail::__boolean_testable_impl, __detail::__boolean_testable): Add
new helper concepts.
(__detail::__weakly_eq_cmp_with, totally_ordered, totally_ordered_with)
(predicate): Use __boolean_testable instead of boolean.
* libsupc++/compare (__detail::__partially_ordered, _Synth3way):
Likewise.

Tested powerpc64le-linux, committed to master.

commit c5e1c1d3aba39e960cc5fb0dcd77e447e5dee7eb
Author: Jonathan Wakely 
Date:   Mon Feb 17 18:15:00 2020 +

libstdc++: P1964R2 Wording for boolean-testable

This removes the complicated std::boolean concept, as agreed in Prague.

* include/bits/ranges_algo.h (__find_fn, __find_first_of_fn)
(__adjacent_find_fn): Cast result of predicate to bool.
* include/std/concepts (__boolean): Remove.
(__detail::__boolean_testable_impl, __detail::__boolean_testable): 
Add
new helper concepts.
(__detail::__weakly_eq_cmp_with, totally_ordered, 
totally_ordered_with)
(predicate): Use __boolean_testable instead of boolean.
* libsupc++/compare (__detail::__partially_ordered, _Synth3way):
Likewise.

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index f3a349ef839..83f295722e9 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -206,7 +206,7 @@ namespace ranges
 const _Tp& __value, _Proj __proj = {}) const
   {
while (__first != __last
-   && !(std::__invoke(__proj, *__first) == __value))
+   && !(bool)(std::__invoke(__proj, *__first) == __value))
  ++__first;
return __first;
   }
@@ -295,9 +295,9 @@ namespace ranges
   {
for (; __first1 != __last1; ++__first1)
  for (auto __iter = __first2; __iter != __last2; ++__iter)
-   if (std::__invoke(__pred,
- std::__invoke(__proj1, *__first1),
- std::__invoke(__proj2, *__iter)))
+   if ((bool)std::__invoke(__pred,
+   std::__invoke(__proj1, *__first1),
+   std::__invoke(__proj2, *__iter)))
  return __first1;
return __first1;
   }
@@ -687,9 +687,9 @@ namespace ranges
auto __next = __first;
for (; ++__next != __last; __first = __next)
  {
-   if (std::__invoke(__pred,
- std::__invoke(__proj, *__first),
- std::__invoke(__proj, *__next)))
+   if ((bool)std::__invoke(__pred,
+   std::__invoke(__proj, *__first),
+   std::__invoke(__proj, *__next)))
  return __first;
  }
return __next;
diff --git a/libstdc++-v3/include/std/concepts 
b/libstdc++-v3/include/std/concepts
index acc9dd2599d..f3db40b798f 100644
--- a/libstdc++-v3/include/std/concepts
+++ b/libstdc++-v3/include/std/concepts
@@ -259,27 +259,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // [concepts.compare], comparison concepts
 
-  /// [concept.boolean], concept boolean
-  template
-concept boolean
-  = movable>
-  && requires(__detail::__cref<_Bp> __b1, __detail::__cref<_Bp> __b2,
- const bool __a) {
-   { __b1 } -> convertible_to;
-   { !__b1 } -> convertible_to;
-   { __b1 && __b2 } -> same_as;
-   { __b1 && __a  } -> same_as;
-   { __a  && __b2 } -> same_as;
-   { __b1 || __b2 } -> same_as;
-   { __b1 || __a  } -> same_as;
-   { __a  || __b2 } -> same_as;
-   { __b1 == __b2 } -> convertible_to;
-   { __b1 == __a  } -> convertible_to;
-   { __a  == __b2 } -> convertible_to;
-   { __b1 != __b2 } -> convertible_to;
-   { __b1 != __a  } -> convertible_to;
-   { __a  != __b2 } -> convertible_to;
-  };
+  // [concept.booleantestable], Boolean testability
+  namespace __detail
+  {
+template
+  concept __boolean_testable_impl = convertible_to<_Tp, bool>;
+
+template
+  concept __boolean_testable
+   = __boolean_testable_impl<_Tp>
+ && requires(_Tp&& __t)
+ { { !static_cast<_Tp&&>(__t) } -> __boolean_testable_impl; };
+  } // namespace __detail
 
   // [concept.equalitycomparable], concept equality_comparable
 
@@ -288,10 +279,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 template
   concept __weakly_eq_cmp_with
= requires(__detail::__cref<_Tp> __t, __detail::__cref<_Up> __u) {
- { __t == __u } -> boolean;
- { __t != __u } -> boolean;
- { __u == __t } -> boolean;
- { __u != __t } -> boolean

[COMMITTED][AArch64] Fix PR93565 testcase for ILP32.

[Wilco Dijkstra]

Fix PR93565 testcase for ILP32.

Committed as obvious.

testsuite/
* gcc.target/aarch64/pr93565.c: Fix test for ilp32.

--
diff --git a/gcc/testsuite/gcc.target/aarch64/pr93565.c 
b/gcc/testsuite/gcc.target/aarch64/pr93565.c
index 7200f80..fb64f5c 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr93565.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr93565.c
@@ -14,13 +14,13 @@ static const char table[64] = {
  9, 30, 45, 41,  8, 40,  7,  6,
 };
 
-static inline int ctz1 (unsigned long  b)
+static inline int ctz1 (unsigned long long  b)
 {
-  unsigned long lsb = b & -b;
+  unsigned long long lsb = b & -b;
   return table[(lsb * magic) >> 58];
 }
 
-void f (unsigned long x, int *p)
+void f (unsigned long long x, int *p)
 {
   if (x != 0)
 {

Re: Update gcc.target/powerpc/pr92132-fp test for power7 and older

[will schmidt]

On Thu, 2020-02-13 at 17:23 -0600, Segher Boessenkool wrote:
> On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote:
> >   Attempting to clean up some more testcase failures.
> > This test in particular exercises the -ftree-vectorize
> > option, and by inspection I see this fails out with assorted
> > "conversion not supported by target" messages on power7 and
> > earlier systems.
> > 
> > Thus, this would limits the scan-dump check of "LOOP VECTORIZED" to
> > those targets supporting power8 vector support.
> > The testcase itself otherwise runs fine, so limiting the test
> > itself seems unnecessary.
> > -/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" }
> > } */
> > +/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" {
> > target p8vector_hw } } } */
> 
> That actually checks if the hardware is p8 or later, while what you
> care
> about is what options are compiled with.  Say, if running on a p8 but
> compiling for a p7 this will fail?

Right...

I did some experimentation and havn't come up with anything I'm
completely satisfied with.   The powerpc_p8vector_ok check doesn't
fail out like I'd expect it to on a power7 target.

Ok, so it appears check_effective_target_powerpc_p8vector_ok () inserts
a "-mpower8-vector" option as part of it's test, so as long as the
compiler on a power7 system is able to generate power8 code, that
power8-vector check will pass, even if we have not otherwise indicated
power8 in our test incantation.

I'll think on this one some more...
thanks
-Will


> 
> 
> Segher

Re: [committed] libstdc++: P1964R2 Wording for boolean-testable

[Tim Song]

On Mon, Feb 17, 2020 at 12:34 PM Jonathan Wakely  wrote:

> This removes the complicated std::boolean concept, as agreed in Prague.
>
> * include/bits/ranges_algo.h (__find_fn, __find_first_of_fn)
> (__adjacent_find_fn): Cast result of predicate to bool.



Um, why? These look fine without the cast. (The WP was doing == false,
which is a different matter.)



> * include/std/concepts (__boolean): Remove.
> (__detail::__boolean_testable_impl, __detail::__boolean_testable):
> Add
> new helper concepts.
> (__detail::__weakly_eq_cmp_with, totally_ordered,
> totally_ordered_with)
> (predicate): Use __boolean_testable instead of boolean.
> * libsupc++/compare (__detail::__partially_ordered, _Synth3way):
> Likewise.
>
> Tested powerpc64le-linux, committed to master.
>
>

[PATCH 2/2] libstdc++: P2106R0 Alternative wording for GB315 and GB316

[Patrick Palka]

libstdc++-v3/ChangeLog:

P2106R0
* include/bits/ranges_algo.h (in_fun_result): New.
(for_each_result, for_each_n_result): Change into an alias of
in_fun_result.
(in_in_result): New.
(mismatch_result): Change into an alias of in_in_result.
(copy_if_result): Change into an alias of in_out_result.
(swap_ranges_result): Change into an alias of in_in_result.
(unary_transform_result): Change into an alias of in_out_result.
(in_in_out_result): New.
(binary_transform_result): Change into an alias of in_in_out_result.
(replace_copy_result, replace_copy_if_result, remove_copy_if_result,
remove_copy_result, unique_copy_result, reverse_copy_result,
rotate_copy_result, partial_sort_copy_result): Change into an alias of
in_out_result.
(in_out_out_result): New.
(partition_copy_result, merge_result): Change into an alias of
in_out_out_result.
(set_union_result, set_intersection_result): Change into an alias of
in_in_out_result.
(set_difference_result): Change into an alias of in_out_result.
(set_symmetric_difference): Change into an alias of in_in_out_result.
(min_max_result): New.
(minmax_result, minmax_element_result): Change into an alias of
min_max_result.
(in_found_result): New.
(next_permutation_result, prev_permutation_result): Change into an alias
of in_found_result.
(__next_permutation_fn::operator(), __prev_permutation_fn::operator()):
Adjust following changes to next_permutation_result and
prev_permutation_result.
* include/bits/ranges_algobase.h (in_out_result): New.
(copy_result, move_result, move_backward_result, copy_backward_result,
copy_n_result): Change into an alias of in_out_result.
* include/bits/ranges_uninitialized.h (uninitialized_copy_result,
uninitialized_copy_n_result, uninitialized_move_result,
uninitialized_move_n_result): Likewise.
* testsuite/25_algorithms/next_permutation/constrained.cc: Adjust uses 
of
structured bindings.
* testsuite/25_algorithms/prev_permutation/constrained.cc: Likewise.
---
 libstdc++-v3/include/bits/ranges_algo.h   | 137 +++---
 libstdc++-v3/include/bits/ranges_algobase.h   |  19 ++-
 .../include/bits/ranges_uninitialized.h   |   8 +-
 .../next_permutation/constrained.cc   |   4 +-
 .../prev_permutation/constrained.cc   |   4 +-
 5 files changed, 108 insertions(+), 64 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index c50b369c6c0..31b1bf0d448 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -152,7 +152,7 @@ namespace ranges
   inline constexpr __none_of_fn none_of{};
 
   template
-struct for_each_result
+struct in_fun_result
 {
   [[no_unique_address]] _Iter in;
   [[no_unique_address]] _Fp fun;
@@ -160,15 +160,20 @@ namespace ranges
   template
requires convertible_to
  && convertible_to
-   operator for_each_result<_Iter2, _F2p>() const &
+   constexpr
+   operator in_fun_result<_Iter2, _F2p>() const &
{ return {in, fun}; }
 
   template
requires convertible_to<_Iter, _Iter2> && convertible_to<_Fp, _F2p>
-   operator for_each_result<_Iter2, _F2p>() &&
+   constexpr
+   operator in_fun_result<_Iter2, _F2p>() &&
{ return {std::move(in), std::move(fun)}; }
 };
 
+  template
+using for_each_result = in_fun_result<_Iter, _Fp>;
+
   struct __for_each_fn
   {
 template _Sent,
@@ -196,7 +201,7 @@ namespace ranges
   inline constexpr __for_each_fn for_each{};
 
   template
-using for_each_n_result = for_each_result<_Iter, _Fp>;
+using for_each_n_result = in_fun_result<_Iter, _Fp>;
 
   struct __for_each_n_fn
   {
@@ -416,7 +421,7 @@ namespace ranges
   inline constexpr __count_if_fn count_if{};
 
   template
-struct mismatch_result
+struct in_in_result
 {
   [[no_unique_address]] _Iter1 in1;
   [[no_unique_address]] _Iter2 in2;
@@ -424,16 +429,21 @@ namespace ranges
   template
requires convertible_to
  && convertible_to
-   operator mismatch_result<_IIter1, _IIter2>() const &
+   constexpr
+   operator in_in_result<_IIter1, _IIter2>() const &
{ return {in1, in2}; }
 
   template
requires convertible_to<_Iter1, _IIter1>
  && convertible_to<_Iter2, _IIter2>
-   operator mismatch_result<_IIter1, _IIter2>() &&
+   constexpr
+   operator in_in_result<_IIter1, _IIter2>() &&
{ return {std::move(in1), std::move(in2)}; }
 };
 
+  template
+using mismatch_result = in_in_result<_Iter1, _Iter2>;
+
   struct __mismatch_fn
   {
 template _Sent1,
@@ -830,7 +840,7 @@ namespace ranges
   inline constexpr 

[PATCH 1/2] libstdc++: P1243R4 Rangify new algorithms

[Patrick Palka]

This adds rangified overloads for for_each_n, sample and clamp as per P1243R4.

libstdc++-v3/ChangeLog:

P1243R4
* include/bits/ranges_algo.h (for_each_n_result, __for_each_n_fn,
for_each_n, __sample_fn, sample, __clamp_fn, clamp): New.
* testsuite/25_algorithms/clamp/constrained.cc: New test.
* testsuite/25_algorithms/for_each/constrained.cc: Augment test.
* testsuite/25_algorithms/sample/constrained.cc: New test.
---
 libstdc++-v3/include/bits/ranges_algo.h   | 115 ++
 .../25_algorithms/clamp/constrained.cc|  58 +
 .../25_algorithms/for_each/constrained.cc |  44 +++
 .../25_algorithms/sample/constrained.cc   |  68 +++
 4 files changed, 285 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/clamp/constrained.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/sample/constrained.cc

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index 83f295722e9..c50b369c6c0 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -195,6 +195,39 @@ namespace ranges
 
   inline constexpr __for_each_fn for_each{};
 
+  template
+using for_each_n_result = for_each_result<_Iter, _Fp>;
+
+  struct __for_each_n_fn
+  {
+template> _Fun>
+  constexpr for_each_n_result<_Iter, _Fun>
+  operator()(_Iter __first, iter_difference_t<_Iter> __n,
+_Fun __f, _Proj __proj = {}) const
+  {
+   if constexpr (random_access_iterator<_Iter>)
+ {
+   if (__n <= 0)
+ return {std::move(__first), std::move(__f)};
+   auto __last = __first + __n;
+   return ranges::for_each(std::move(__first), std::move(__last),
+   std::move(__f), std::move(__proj));
+ }
+   else
+ {
+   while (__n-- > 0)
+ {
+   std::__invoke(__f, std::__invoke(__proj, *__first));
+   ++__first;
+ }
+   return {std::move(__first), std::move(__f)};
+ }
+  }
+  };
+
+  inline constexpr __for_each_n_fn for_each_n{};
+
   struct __find_fn
   {
 template _Sent, typename _Tp,
@@ -1694,6 +1727,64 @@ namespace ranges
 
   inline constexpr __rotate_copy_fn rotate_copy{};
 
+  struct __sample_fn
+  {
+template _Sent,
+weakly_incrementable _Out, typename _Gen>
+  requires (forward_iterator<_Iter> || random_access_iterator<_Out>)
+   && indirectly_copyable<_Iter, _Out>
+   && uniform_random_bit_generator>
+  _Out
+  operator()(_Iter __first, _Sent __last, _Out __out,
+iter_difference_t<_Iter> __n, _Gen&& __g) const
+  {
+   if constexpr (forward_iterator<_Iter>)
+ {
+   // FIXME: Forwarding to std::sample here requires computing __lasti
+   // which may take linear time.
+   auto __lasti = ranges::next(__first, __last);
+   return std::sample(std::move(__first), std::move(__lasti),
+  std::move(__out), __n, std::forward<_Gen>(__g));
+ }
+   else
+ {
+   using __distrib_type
+ = uniform_int_distribution>;
+   using __param_type = typename __distrib_type::param_type;
+   __distrib_type __d{};
+   iter_difference_t<_Iter> __sample_sz = 0;
+   while (__first != __last && __sample_sz != __n)
+ {
+   __out[__sample_sz++] = *__first;
+   ++__first;
+ }
+   for (auto __pop_sz = __sample_sz; __first != __last;
+   ++__first, (void) ++__pop_sz)
+ {
+   const auto __k = __d(__g, __param_type{0, __pop_sz});
+   if (__k < __n)
+ __out[__k] = *__first;
+ }
+   return __out + __sample_sz;
+ }
+  }
+
+template
+  requires (forward_range<_Range> || random_access_iterator<_Out>)
+   && indirectly_copyable, _Out>
+   && uniform_random_bit_generator>
+  _Out
+  operator()(_Range&& __r, _Out __out,
+range_difference_t<_Range> __n, _Gen&& __g) const
+  {
+   return (*this)(ranges::begin(__r), ranges::end(__r),
+  std::move(__out), __n,
+  std::forward<_Gen>(__g));
+  }
+  };
+
+  inline constexpr __sample_fn sample{};
+
 #ifdef _GLIBCXX_USE_C99_STDINT_TR1
   struct __shuffle_fn
   {
@@ -3102,6 +3193,30 @@ namespace ranges
 
   inline constexpr __max_fn max{};
 
+  struct __clamp_fn
+  {
+template> _Comp
+  = ranges::less>
+  constexpr const _Tp&
+  operator()(const _Tp& __val, const _Tp& __lo, const _Tp& __hi,
+_Comp __comp = {}, _Proj __proj = {}) const
+  {
+   __glibcxx_assert(!(std::__invoke(__comp,
+std::__invoke(__proj, __hi),
+ 

[patch, libfortran] Fix race condition in asynchronous I/O

[Thomas Koenig]

Hello world,

as you can see from the PR, async_io_4.f90 exhibited a race condition
every few thousands to tens of thousands of cases.

This was difficult to track down, and took some thinking, discussion
with Nicolas and enabling of the debugging feature of the async I/O,
which finally produced a failure which could then be analyzed.

The solution was to remove the mutexes for the different conditions that
can happen in the async library, relying on the lock that protects the
async I/O queue instead.

Tested by Bill Seurer (thanks!) with a previous version of the patch,
and with valgrind --tool=helgrind and valgrind --tool=drd, both of
which showed no (new) failures for all of the async_io_*.f90 tests.

So, OK for trunk and gcc-9?

Regards

Thomas

2020-02-17  Thomas Koenig  

PR fortran/93599
* io/async.c (destroy_adv_cond): Do not destroy lock.
(async_io): Make sure au->lock is locked for finishing of thread.
Do not lock/unlock around signalling emptysignal. Unlock au->lock
before return.
(init_adv_cond): Do not initialize lock.
(enqueue_transfer): Unlock after signal.
(enqueue_done_id): Likewise.
(enqueue_done): Likewise.
(enqueue_close): Likewise.
(enqueue_data_transfer): Likewise.
(async_wait_id): Do not lock/unlock around signalling au->work.
(async_wait): Unlock after signal.
* io/async.h (SIGNAL): Add comment about needed au->lock.
Remove locking/unlocking of advcond->lock.
(WAIT_SIGNAL_MUTEX): Add comment. Remove locking/unlocking of
advcond->lock.  Unlock mutex only at the end.  Loop on
__ghread_cond_wait returning zero.
(REVOKE_SIGNAL): Add comment. Remove locking/unlocking of
advcond->lock.
(struct adv_cond): Remove mutex from struct.
diff --git a/libgfortran/io/async.c b/libgfortran/io/async.c
index ab214af8a66..63b9158c0ba 100644
--- a/libgfortran/io/async.c
+++ b/libgfortran/io/async.c
@@ -80,7 +80,6 @@ update_pdt (st_parameter_dt **old, st_parameter_dt *new) {
 static void
 destroy_adv_cond (struct adv_cond *ac)
 {
-  T_ERROR (__gthread_mutex_destroy, &ac->lock);
   T_ERROR (__gthread_cond_destroy, &ac->signal);
 }
 
@@ -156,6 +155,7 @@ async_io (void *arg)
 
 		case AIO_CLOSE:
 		  NOTE ("Received AIO_CLOSE");
+		  LOCK (&au->lock);
 		  goto finish_thread;
 
 		default:
@@ -175,7 +175,6 @@ async_io (void *arg)
 	  else if (ctq->type == AIO_CLOSE)
 		{
 		  NOTE ("Received AIO_CLOSE during error condition");
-		  UNLOCK (&au->lock);
 		  goto finish_thread;
 		}
 	}
@@ -189,9 +188,7 @@ async_io (void *arg)
   au->tail = NULL;
   au->head = NULL;
   au->empty = 1;
-  UNLOCK (&au->lock);
   SIGNAL (&au->emptysignal);
-  LOCK (&au->lock);
 }
  finish_thread:
   au->tail = NULL;
@@ -199,6 +196,7 @@ async_io (void *arg)
   au->empty = 1;
   SIGNAL (&au->emptysignal);
   free (ctq);
+  UNLOCK (&au->lock);
   return NULL;
 }
 
@@ -223,7 +221,6 @@ static void
 init_adv_cond (struct adv_cond *ac)
 {
   ac->pending = 0;
-  __GTHREAD_MUTEX_INIT_FUNCTION (&ac->lock);
   __GTHREAD_COND_INIT_FUNCTION (&ac->signal);
 }
 
@@ -279,8 +276,8 @@ enqueue_transfer (async_unit *au, transfer_args *arg, enum aio_do type)
   au->tail = tq;
   REVOKE_SIGNAL (&(au->emptysignal));
   au->empty = false;
-  UNLOCK (&au->lock);
   SIGNAL (&au->work);
+  UNLOCK (&au->lock);
 }
 
 /* Enqueue an st_write_done or st_read_done which contains an ID.  */
@@ -303,8 +300,8 @@ enqueue_done_id (async_unit *au, enum aio_do type)
   au->empty = false;
   ret = au->id.high++;
   NOTE ("Enqueue id: %d", ret);
-  UNLOCK (&au->lock);
   SIGNAL (&au->work);
+  UNLOCK (&au->lock);
   return ret;
 }
 
@@ -324,8 +321,8 @@ enqueue_done (async_unit *au, enum aio_do type)
   au->tail = tq;
   REVOKE_SIGNAL (&(au->emptysignal));
   au->empty = false;
-  UNLOCK (&au->lock);
   SIGNAL (&au->work);
+  UNLOCK (&au->lock);
 }
 
 /* Enqueue a CLOSE statement.  */
@@ -344,8 +341,8 @@ enqueue_close (async_unit *au)
   au->tail = tq;
   REVOKE_SIGNAL (&(au->emptysignal));
   au->empty = false;
-  UNLOCK (&au->lock);
   SIGNAL (&au->work);
+  UNLOCK (&au->lock);
 }
 
 /* The asynchronous unit keeps the currently active PDT around.
@@ -374,9 +371,9 @@ enqueue_data_transfer_init (async_unit *au, st_parameter_dt *dt, int read_flag)
 au->tail->next = tq;
   au->tail = tq;
   REVOKE_SIGNAL (&(au->emptysignal));
-  au->empty = 0;
-  UNLOCK (&au->lock);
+  au->empty = false;
   SIGNAL (&au->work);
+  UNLOCK (&au->lock);
 }
 
 /* Collect the errors that may have happened asynchronously.  Return true if
@@ -430,9 +427,7 @@ async_wait_id (st_parameter_common *cmp, async_unit *au, int i)
   NOTE ("Waiting for id %d", i);
   if (au->id.waiting < i)
 au->id.waiting = i;
-  UNLOCK (&au->lock);
   SIGNAL (&(au->work));
-  LOCK (&au->lock);
   WAIT_SIGNAL_MUTEX (&(au->id.done),
 		 (au->id.low >= au->id.waiting || au->empty), &au->lock);
   LOCK (&a

Re: [Regression, patch][Fortran] ICE in gfc_typenode_for_spec PR93603

[Thomas Koenig]

Hi Mark and Steve,


OK to commit?


OK (bordering on obvious).

Thanks to both of you!

Regards

Thomas

Re: [Regression, patch][Fortran] ICE: Invalid expression in gfc_element_size PR93601

[Thomas Koenig]

Hi Mark and Steve,


OK to commit?


Yes. Again, thanks a lot!

Regards

Thomas

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

[Stephan Bergmann]

On 04/02/2020 03:07, Patrick Palka wrote:

This patch implements [range.adaptors].  It also includes the changes from P3280
and P3278 and P3323, without which many standard examples won't work.


I see that with this 
 
"libstdc++: Implement C++20 range adaptors", compiling  with 
recent Clang trunk (which appears to mostly implement C++20 concepts 
now) in -std=c++2a mode fails as below (besides also failing due to some 
"missing" typenames, where Clang apparently doesn't yet implement 
P0634R3).  And I'm not sure which of Clang vs. GCC is right here.


The failure is


gcc/trunk/inst/include/c++/10.0.1/ranges:1512:47: error: ambiguous deduction 
for template arguments of '_RangeAdaptor'
inline constexpr __adaptor::_RangeAdaptor filter
  ^
gcc/trunk/inst/include/c++/10.0.1/ranges:1073:2: note: candidate function [with 
_Callable = std::ranges::views::(lambda at 
gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
_RangeAdaptor(const _Callable& = {})
^
gcc/trunk/inst/include/c++/10.0.1/ranges:1078:2: note: candidate function [with 
_Callable = std::ranges::views::(lambda at 
gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
_RangeAdaptor(_Callable __callable)
^


and a stripped-down reproducer is


template struct S {
  S(T const &) requires true;
  S(T) requires false;
};
S s = 0;


(Clang accepts this when the last line is replaced with


S s = 0;


and thus no class template argument deduction needs to be done.)

I think what is relevant here is [over.match.class.deduct]/1 in the 
current spec, which specifies a helper set of hypothetical function 
templates based on a class' constructors for class template argument 
deduction.  It details the function templates' template parameters, 
function parameters, and return types, but does not mention 
requires-clauses.  From my superficial understanding of concepts and 
class template argument deduction it would thus look like the 
constructors' requires-clauses should indeed not be taken into account here?

Re: [8/9/10 Regression, patch][PR93714] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[Thomas Koenig]

Hi Mark,


OK to commit?


Yes, OK.

Thanks a lot for the patch!

Regards

Thomas

Re: [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]

[Thomas Koenig]

Hi Mark,


OK for master and gcc 9 branch?


Looks good.

Thanks!

Regards

Thomas

Re: [PATCH] libgfortran: Fix and simplify IO locking [PR92836]

[Thomas Koenig]

Hi Janne,


Simplify IO locking in libgfortran.  The new IO implementation avoids
accessing units without locks, as seen in PR 92836.  It also avoids
lock inversion (except for a corner case wrt namelist query when
reading from stdin and outputting to stdout), making it easier to
verify correctness with tools like valgrind or threadsanitizer.  It is
also simplified as the waiting and closed variables are not needed
anymore, making it easier to understand and analyze.

Regtested on x86_64-pc-linux-gnu, Ok for master?


Sorry it took me so long to actually look at this. The patch for
PR 93599 took a bit longer than anticipated...

With your patch on top of the one I just submitted, I get
valgrind errors for the asynchronous I/O tests:

$ gfortran -g async_io_1.f90 -pthread
$ valgrind --tool=drd ./a.out
==22685== drd, a thread error detector
==22685== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
==22685== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==22685== Command: ./a.out
==22685==
==22685== Destroying locked mutex: mutex 0x60708f0, recursion count 1, 
owner 1.
==22685==at 0x4C37B65: pthread_mutex_destroy_intercept 
(drd_pthread_intercepts.c:865)
==22685==by 0x4C37B65: pthread_mutex_destroy 
(drd_pthread_intercepts.c:875)

==22685==by 0x50A6CAE: __gthread_mutex_destroy (gthr-default.h:740)
==22685==by 0x50A6CAE: destroy_unit_mutex (unit.c:253)
==22685==by 0x50A6CAE: close_unit_1 (unit.c:732)
==22685==by 0x5091E67: _gfortran_st_close (close.c:108)
==22685==by 0x4011D3: MAIN__ (async_io_1.f90:25)
==22685==by 0x401AA9: main (async_io_1.f90:48)
==22685== mutex 0x60708f0 was first observed at:
==22685==at 0x4C37FD5: pthread_mutex_lock_intercept 
(drd_pthread_intercepts.c:885)

==22685==by 0x4C37FD5: pthread_mutex_lock (drd_pthread_intercepts.c:898)
==22685==by 0x50A6039: __gthread_mutex_lock (gthr-default.h:749)
==22685==by 0x50A6039: insert_unit (unit.c:241)
==22685==by 0x50A615F: get_gfc_unit (unit.c:353)
==22685==by 0x509DC93: _gfortran_st_open (open.c:889)
==22685==by 0x400E4A: MAIN__ (async_io_1.f90:16)
==22685==by 0x401AA9: main (async_io_1.f90:48)

(plus a few more).  I am currently bootstrapping without the patch
above so I can be sure that this is not an artifact.

However, it looks as if the "locked" argument to close_unit_1 gets
passed the wrong value somehow.  Could you maybe look at that?

Regards

Thomas

[PATCH] reject invalid flexarrays even in anonymous structs (PR 93753)

[Martin Sebor]

The improved checking of flexible array members committed in r231665
(and later) deliberately excluded anonymous structs and unions
(unnamed members of types with no tags) to allow a harmless extension
that was accepted by G++ prior to the change.  However, being overly
broad, the exemption prevents flexible array members that are invalid
for other reasons from being diagnosed in these contexts.  That in
turn leads to a subset of such cases causing ICEs downstream.

The attached trivial patch tightens up the conditions under which
this extension is accepted: it only considers such structs when they
are members, thus eliminating the ICE.

Tested on x86_64-linux.

Martin
PR c++/93753 - ICE on a flexible array followed by a member in an anonymous struct with an initializer

gcc/cp/ChangeLog:

	PR gcov-profile/93753
	* class.c (check_flexarrays): Tighten up a test for potential members
	of anonymous structs or unions.

gcc/testsuite/ChangeLog:

	PR gcov-profile/93753
	* g++.dg/ext/flexary36.C: New test.
	* g++.dg/lto/pr93166_0.C: Make struct with flexarray valid.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index a1fd1aa91cc..772134df5fc 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -7142,6 +7142,8 @@ check_flexarrays (tree t, flexmems_t *fmem /* = NULL */,
   /* Is the type unnamed (and therefore a member of it potentially
  an anonymous struct or union)?  */
   bool maybe_anon_p = TYPE_UNNAMED_P (t);
+  if (tree ctx = maybe_anon_p ? TYPE_CONTEXT (t) : NULL_TREE)
+maybe_anon_p = RECORD_OR_UNION_TYPE_P (ctx);
 
   /* Search the members of the current (possibly derived) class, skipping
  unnamed structs and unions since those could be anonymous.  */
diff --git a/gcc/testsuite/g++.dg/ext/flexary36.C b/gcc/testsuite/g++.dg/ext/flexary36.C
new file mode 100644
index 000..220ccc0ccf8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/flexary36.C
@@ -0,0 +1,123 @@
+/* PR c++/93753 - ICE on a flexible array followed by a member in
+   an anonymous struct with an initializer
+   { dg-do compile }
+   { dg-options "-Wall -Wno-unused-variable" } */
+
+struct {
+  int a[];  // { dg-error "flexible array member '::a' not at end of 'struct'" }
+  int b;
+} ax;
+
+struct {
+  int a[];  // { dg-error "flexible array member '::a' not at end of 'struct'" }
+  int b;
+} bx = { };
+
+struct {
+  int a[];  // { dg-error "flexible array member '::a' not at end of 'struct'" }
+  int b;
+} cx = { 0 };
+
+struct {
+  int a[];  // { dg-error "flexible array member '::a' not at end of 'struct'" }
+  int b;
+} dx = { 1 };
+
+
+union {
+  int a[];  // { dg-error "flexible array member in union" }
+  int b;
+} du = { 1 };
+
+
+struct A {
+  int a[];  // { dg-error "flexible array member 'A::a' not at end of 'struct A'" }
+  int b;
+} a;
+
+struct B {
+  int a[];  // { dg-error "flexible array member 'B::a' not at end of 'struct B'" }
+  int b;
+} b = { };
+
+struct C {
+  int a[];  // { dg-error "flexible array member 'C::a' not at end of 'struct C'" }
+  int b;
+} c = { 0 };
+
+struct D {
+  int a[];  // { dg-error "flexible array member 'D::a' not at end of 'struct D'" }
+  int b;
+} d = { 1 };
+
+
+struct E {
+  struct {
+int a[];// { dg-error " not at end " }
+int b;
+  } e = { 1 };  // { dg-error "non-static initialization of a flexible array member" }
+};
+
+struct G {
+  struct {
+int a[];// { dg-error " not at end " }
+int b;
+  };
+} g = { 1 };// { dg-error "initialization of flexible array member in a nested context" }
+
+struct H {
+  int i;
+  struct {
+int a[];// { dg-error " not at end " }
+int b;
+  };
+} h = { 1 };
+
+namespace {
+
+struct {
+  int a[];  // { dg-error " not at end of " }
+  int b;
+} ax;
+
+struct {
+  int a[];  // { dg-error " not at end " }
+  int b;
+} bx = { };
+
+struct {
+  int a[];  // { dg-error " not at end " }
+  int b;
+} cx = { 0 };
+
+struct {
+  int a[];  // { dg-error " not at end " }
+  int b;
+} dx = { 1 };
+
+
+struct A {
+  int a[];  // { dg-error " not at end of 'struct {anonymous}::A'" }
+  int b;
+} a;
+
+struct B {
+  int a[];  // { dg-error " not at end of 'struct {anonymous}::B'" }
+  int b;
+} b = { };
+
+struct C {
+  int a[];  // { dg-error " not at end of 'struct {anonymous}::C'" }
+  int b;
+} c = { 0 };
+
+struct D {
+  int a[];  // { dg-error " not at end of 'struct {anonymous}::D'" }
+  int b;
+} d = { 1 };
+
+}
+
+// { dg-prune-output "unnamed type with no linkage used to declare variable" }
+// { dg-prune-output "non-static data member initializers" }
+// { dg-prune-output "extended initializer lists" }
diff --git a/gcc/testsuite/g++.dg/lto/pr93166_0.C b/gcc/testsuite/g++.dg/lto/pr93166_0.C
index 52f7ddf4016..a83ba6e0400 100644
--- a/gcc/testsuite/g++.dg/lto/pr93166_0.C
+++ b/gcc/testsuite/g++.dg/lto/pr93166_0.C
@@ -109,7 +109,7 @@ public:
   QSignalMapper *

[PATCH] tree-ssa: Fix ICE in build_vector_type [PR93780]

[Jakub Jelinek]

Hi!

The following testcase ICEs, because execute_update_addresses_taken attempts
to create a VECTOR_TYPE with non-power of 2 number of elts.
Fixed by guarding it with the corresponding predicate.

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

2020-02-17  Jakub Jelinek  

PR tree-optimization/93780
* tree-ssa.c (non_rewritable_lvalue_p): Check valid_vector_subparts_p
before calling build_vector_type.
(execute_update_addresses_taken): Likewise.

* gcc.dg/pr93780.c: New test.

--- gcc/tree-ssa.c.jj   2020-01-12 11:54:38.515381696 +0100
+++ gcc/tree-ssa.c  2020-02-17 10:54:32.481615050 +0100
@@ -1550,7 +1550,8 @@ non_rewritable_lvalue_p (tree lhs)
  && multiple_p (lhs_bits,
 tree_to_uhwi
   (TYPE_SIZE (TREE_TYPE (TREE_TYPE (decl,
-&nelts))
+&nelts)
+ && valid_vector_subparts_p (nelts))
{
  if (known_eq (nelts, 1u))
return false;
@@ -1925,7 +1926,8 @@ execute_update_addresses_taken (void)
 (TYPE_SIZE (TREE_TYPE
   (TREE_TYPE (sym,
   &nelts)
-   && maybe_ne (nelts, 1u))
+   && maybe_ne (nelts, 1u)
+   && valid_vector_subparts_p (nelts))
  temtype = build_vector_type (temtype, nelts);
tree tem = make_ssa_name (temtype);
gimple *pun
--- gcc/testsuite/gcc.dg/pr93780.c.jj   2020-02-17 10:44:31.839583128 +0100
+++ gcc/testsuite/gcc.dg/pr93780.c  2020-02-17 10:44:16.453812697 +0100
@@ -0,0 +1,15 @@
+/* PR tree-optimization/93780 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-additional-options "-mavx" { target avx } } */
+
+typedef float V __attribute__((vector_size (32)));
+
+float
+foo (void)
+{
+  const float init[6] = {};
+  V v = {};
+  __builtin_memcpy (&v, init, sizeof (init));
+  return v[0];
+}

Jakub

[PATCH] i18n: Fix translation of --help [PR93759]

[Jakub Jelinek]

Hi!

The first two hunks make sure we actually translate what has been marked
for translation, i.e. the cl_options[...].help strings, rather than those
strings ammended in various ways, like:
_("%s  Same as %s."), help, ...
or
"%s  %s", help, _(use_diagnosed_msg)

The exgettext changes attempt to make sure that the cl_options[...].help
strings are marked as no-c-format, because otherwise if they happen
to contain a % character, such as the 90% substring, they will be marked
as c-format, which they aren't.

Bootstrapped/regtested on x86_64-linux and i686-linux plus tested with make
gcc.pot, ok for trunk?

2020-02-17  Jakub Jelinek  

PR translation/93759
* opts.c (print_filtered_help): Translate help before appending
messages to it rather than after that.

* exgettext: For *.opt help texts, use __opt_help_text("...")
rather than _("...") in the $emsg file and pass options that
say that this implies no-c-format.

--- gcc/opts.c.jj   2020-01-27 13:20:40.491649814 +0100
+++ gcc/opts.c  2020-02-17 14:52:56.164212999 +0100
@@ -1309,10 +1309,13 @@ print_filtered_help (unsigned int includ
  help = undocumented_msg;
}
 
+  /* Get the translation.  */
+  help = _(help);
+
   if (option->alias_target < N_OPTS
  && cl_options [option->alias_target].help)
{
- if (help == undocumented_msg)
+ if (option->help == NULL)
{
  /* For undocumented options that are aliases for other options
 that are documented, point the reader to the other option in
@@ -1347,9 +1350,6 @@ print_filtered_help (unsigned int includ
  help = new_help;
}
 
-  /* Get the translation.  */
-  help = _(help);
-
   /* Find the gap between the name of the
 option and its descriptive text.  */
   tab = strchr (help, '\t');
--- gcc/po/exgettext.jj 2020-01-12 11:54:36.784407811 +0100
+++ gcc/po/exgettext2020-02-17 15:34:40.308915980 +0100
@@ -227,6 +227,7 @@ END {
}
 }
 print emsg > posr
+print "--keyword=__opt_help_text\n--flag=__opt_help_text:1:no-c-format" >> 
kopt
 }'
 ) || exit
 
@@ -240,7 +241,7 @@ echo "scanning option files..." >&2
 while (getline < file) {
if (/^[ \t]*(;|$)/ || !/^[^ \t]/) {
if (field > 2)
-   printf("_(\"%s\")\n", line)
+   printf("__opt_help_text(\"%s\")\n", line)
field = 0
} else {
if ((field == 1) && /MissingArgError/) {
@@ -287,7 +288,7 @@ echo "scanning option files..." >&2
lineno++;
 }
 if (field > 2)
-   printf("_(\"%s\")\n", line)
+   printf("__opt_help_text(\"%s\")\n", line)
   }') >> $emsg
 
 # Run the xgettext commands, with temporary added as a file to scan.

Jakub

[PATCH] c++: use "C++20" in std header hints

[David Malcolm]

On Sat, 2020-02-15 at 22:21 +0100, Jason Merrill wrote:
> It's probably past time for this, but definitely now that we're done
> with
> the final committee meeting of C++20.  This patch only adds the
> option and
> adjusts the testsuite to recognize it; more extensive changes can
> wait for
> the published standard.

I don't know if this is premature, or too piecemeal, but this patch
improves hints such as:
  note: 'std::source_location' is only available from C++2a onwards
to
  note: 'std::source_location' is only available from C++20 onwards

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for master?

gcc/cp/ChangeLog:
* name-lookup.c (get_cxx_dialect_name): Return "C++20" for cxx2a.

gcc/testsuite/ChangeLog:
* g++.dg/lookup/missing-std-include-8.C: Add test coverage for
C++20 hints.
---
 gcc/cp/name-lookup.c| 2 +-
 gcc/testsuite/g++.dg/lookup/missing-std-include-8.C | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index e5638d2df91..7a87c3d2eb5 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -5856,7 +5856,7 @@ get_cxx_dialect_name (enum cxx_dialect dialect)
 case cxx17:
   return "C++17";
 case cxx2a:
-  return "C++2a";
+  return "C++20";
 }
 }
 
diff --git a/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C 
b/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C
index 73532c82968..716479761b4 100644
--- a/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C
+++ b/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C
@@ -43,6 +43,10 @@ std::shared_timed_mutex m; // { dg-error 
"'shared_timed_mutex' in namespace 'std
 std::string_view sv; // { dg-error "'string_view' in namespace 'std' does not 
name a type" }
 // { dg-message "'std::string_view' is only available from C\\+\\+17 onwards" 
"" { target *-*-* } .-1 }
 
+/* Since C++20: */
+std::source_location loc; // { dg-error "'source_location' in namespace 'std' 
does not name a type" }
+// { dg-message "'std::source_location' is only available from C\\+\\+20 
onwards" "" { target *-*-* } .-1 }
+
 /* Verify interaction with "using namespace std;".  */
 using namespace std;
 void test_via_using_directive ()
-- 
2.21.0

[committed] analyzer: fix ICE on function pointer casts [PR 93775]

[David Malcolm]

PR analyzer/93775 reports an ICE in cgraph_node::get when -fanalyzer is
used on code that calls a function pointer that was generated via a cast
from a non-function.

This patch fixes it by bulletproofing region_model::get_fndecl_for_call
for the case where the code_region's get_tree_for_child_region returns
NULL.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6686-gd8cde6f9c223f1b6d4f4e4e07088f08a629b7c2a.

gcc/analyzer/ChangeLog:
PR analyzer/93775
* region-model.cc (region_model::get_fndecl_for_call): Handle the
case where the code_region's get_tree_for_child_region returns
NULL.

gcc/testsuite/ChangeLog:
PR analyzer/93775
* gcc.dg/analyzer/20020129-1.c: New test.
---
 gcc/analyzer/region-model.cc   | 2 ++
 gcc/testsuite/gcc.dg/analyzer/20020129-1.c | 2 ++
 2 files changed, 4 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/20020129-1.c

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index b67660cf864..deb201546f3 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -6693,6 +6693,8 @@ region_model::get_fndecl_for_call (const gcall *call,
   if (code)
{
  tree fn_decl = code->get_tree_for_child_region (fn_rid);
+ if (!fn_decl)
+   return NULL_TREE;
  const cgraph_node *ultimate_node
= cgraph_node::get (fn_decl)->ultimate_alias_target ();
  if (ultimate_node)
diff --git a/gcc/testsuite/gcc.dg/analyzer/20020129-1.c 
b/gcc/testsuite/gcc.dg/analyzer/20020129-1.c
new file mode 100644
index 000..7d49519bc40
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/20020129-1.c
@@ -0,0 +1,2 @@
+/* { dg-require-effective-target indirect_calls } */
+#include "../../gcc.c-torture/compile/20020129-1.c"
-- 
2.21.0

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

[Patrick Palka]

Hi Stephan,

On Mon, 17 Feb 2020, Stephan Bergmann wrote:

> On 04/02/2020 03:07, Patrick Palka wrote:
> > This patch implements [range.adaptors].  It also includes the changes from
> > P3280
> > and P3278 and P3323, without which many standard examples won't work.
> 
> I see that with this
> 
> "libstdc++: Implement C++20 range adaptors", compiling  with recent
> Clang trunk (which appears to mostly implement C++20 concepts now) in
> -std=c++2a mode fails as below (besides also failing due to some "missing"
> typenames, where Clang apparently doesn't yet implement P0634R3).  And I'm not
> sure which of Clang vs. GCC is right here.
> 
> The failure is
> 
> > gcc/trunk/inst/include/c++/10.0.1/ranges:1512:47: error: ambiguous deduction
> > for template arguments of '_RangeAdaptor'
> > inline constexpr __adaptor::_RangeAdaptor filter
> >   ^
> > gcc/trunk/inst/include/c++/10.0.1/ranges:1073:2: note: candidate function
> > [with _Callable = std::ranges::views::(lambda at
> > gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
> > _RangeAdaptor(const _Callable& = {})
> > ^
> > gcc/trunk/inst/include/c++/10.0.1/ranges:1078:2: note: candidate function
> > [with _Callable = std::ranges::views::(lambda at
> > gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
> > _RangeAdaptor(_Callable __callable)
> > ^
> 
> and a stripped-down reproducer is
> 
> > template struct S {
> >   S(T const &) requires true;
> >   S(T) requires false;
> > };
> > S s = 0;
> 
> (Clang accepts this when the last line is replaced with
> 
> > S s = 0;
> 
> and thus no class template argument deduction needs to be done.)
> 
> I think what is relevant here is [over.match.class.deduct]/1 in the current
> spec, which specifies a helper set of hypothetical function templates based on
> a class' constructors for class template argument deduction.  It details the
> function templates' template parameters, function parameters, and return
> types, but does not mention requires-clauses.  From my superficial
> understanding of concepts and class template argument deduction it would thus
> look like the constructors' requires-clauses should indeed not be taken into
> account here?

Thanks for letting me know about this issue.  That would be my
interpretation of the spec, too.  Maybe someone else could shed light on
this question?

The following patch simplifies _RangeAdaptor's constructors to no longer
need to be constrained and should resolve the deduction ambiguity error
reported by Clang?  Unfortunately the patch triggers an ICE in GCC,
which I'll look into tomorrow.

-- >8 --

Subject: [PATCH] Simplify constructors of _RangeAdaptor

---
 libstdc++-v3/include/std/ranges | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 6759f9b4b46..a04387a75c4 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1064,19 +1064,13 @@ namespace views
   struct _RangeAdaptor
   {
   protected:
-   [[no_unique_address]]
- conditional_t,
-   _Callable, __detail::_Empty> _M_callable;
+   [[no_unique_address]] _Callable _M_callable;
 
   public:
-   constexpr
-   _RangeAdaptor(const _Callable& = {})
- requires is_default_constructible_v<_Callable>
-   { }
+   _RangeAdaptor() = default;
 
constexpr
_RangeAdaptor(_Callable __callable)
- requires (!is_default_constructible_v<_Callable>)
  : _M_callable(std::move(__callable))
{ }
 
-- 
2.25.1.291.ge68e29171c

[PATCH] analyzer: add test coverage for gfortran ICE fix [PR 93779]

[David Malcolm]

PR analyzer/93779 reports an ICE in gfortran with -fanalyzer
that was fixed for GCC 10 by a workaround in
f76a88ebf089871dcce215aa0cb1956ccc060895; the tree code in
question is a FUNCTION_DECL.

Given that I want to rework the above patch at some point, it seems
prudent to add test coverage to ensure the ICE doesn't come back,
which this patch does.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for master?

gcc/testsuite/ChangeLog:
PR analyzer/93779
* gfortran.dg/analyzer/pr88304-2.f90: New test.
---
 gcc/testsuite/gfortran.dg/analyzer/pr88304-2.f90 | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 gcc/testsuite/gfortran.dg/analyzer/pr88304-2.f90

diff --git a/gcc/testsuite/gfortran.dg/analyzer/pr88304-2.f90 
b/gcc/testsuite/gfortran.dg/analyzer/pr88304-2.f90
new file mode 100644
index 000..0aa02440152
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/analyzer/pr88304-2.f90
@@ -0,0 +1 @@
+include "../../gfortran.fortran-torture/compile/pr88304-2.f90"
-- 
2.21.0

[PATCH] analyzer: fix ICE on pointer arithmetic with incomplete types [PR 93774]

[David Malcolm]

PR analyzer/93774 reports an ICE in gfortran with -fanalyzer within
region_model::convert_byte_offset_to_array_index on a pointer of
incomplete type ("character(kind=1)[0:][1:0] * restrict").

This patch bulletproofs the routine against incomplete types, fixing
the ICE.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

I think I have permission to self-approve the analyzer part.

Is the Fortran testcase OK for master?

gcc/analyzer/ChangeLog:
PR analyzer/93774
* region-model.cc
(region_model::convert_byte_offset_to_array_index): Use
int_size_in_bytes before calling size_in_bytes, to gracefully fail
on incomplete types.

gcc/testsuite/ChangeLog:
PR analyzer/93774
* gfortran.dg/analyzer/deferred_character_25.f90: New test.
---
 gcc/analyzer/region-model.cc  | 33 ++-
 .../analyzer/deferred_character_25.f90|  3 ++
 2 files changed, 21 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/analyzer/deferred_character_25.f90

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index deb201546f3..659255a8db4 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -6514,24 +6514,27 @@ region_model::convert_byte_offset_to_array_index (tree 
ptr_type,
 
   /* Arithmetic on void-pointers is a GNU C extension, treating the size
 of a void as 1.
-https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
-
-Returning early for this case avoids a diagnostic from within the
-call to size_in_bytes.  */
+https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html  */
   if (TREE_CODE (elem_type) == VOID_TYPE)
return offset_sid;
 
-  /* This might not be a constant.  */
-  tree byte_size = size_in_bytes (elem_type);
-
-  /* Try to get a constant by dividing, ensuring that we're in a
-signed representation first.  */
-  tree index
-   = fold_binary (TRUNC_DIV_EXPR, ssizetype,
-  fold_convert (ssizetype, offset_cst),
-  fold_convert (ssizetype, byte_size));
-  if (index && TREE_CODE (index) == INTEGER_CST)
-   return get_or_create_constant_svalue (index);
+  /* First, use int_size_in_bytes, to reject the case where we have an
+incomplete type, or a non-constant value.  */
+  HOST_WIDE_INT hwi_byte_size = int_size_in_bytes (elem_type);
+  if (hwi_byte_size > 0)
+   {
+ /* Now call size_in_bytes to get the answer in tree form.  */
+ tree byte_size = size_in_bytes (elem_type);
+ gcc_assert (byte_size);
+ /* Try to get a constant by dividing, ensuring that we're in a
+signed representation first.  */
+ tree index
+   = fold_binary (TRUNC_DIV_EXPR, ssizetype,
+  fold_convert (ssizetype, offset_cst),
+  fold_convert (ssizetype, byte_size));
+ if (index && TREE_CODE (index) == INTEGER_CST)
+   return get_or_create_constant_svalue (index);
+   }
 }
 
   /* Otherwise, we don't know the array index; generate a new unknown value.
diff --git a/gcc/testsuite/gfortran.dg/analyzer/deferred_character_25.f90 
b/gcc/testsuite/gfortran.dg/analyzer/deferred_character_25.f90
new file mode 100644
index 000..09303630d98
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/analyzer/deferred_character_25.f90
@@ -0,0 +1,3 @@
+! { dg-do compile }
+! { dg-additional-options "-Wno-analyzer-too-complex" }
+include "../deferred_character_25.f90"
-- 
2.21.0

[PATCH] analyzer: fix ICE on COMPONENT_REF of ARRAY_TYPE [PR 93778]

[David Malcolm]

PR analyzer/93778 reports an ICE with -fanalyzer on a gfortran test case
at this gimple stmt:

  _gfortran_st_set_nml_var (&dt_parm.0, &ro.xi.jq, &"ro%xi%jq"[1]{lb: 1 sz: 1}, 
4, 0, D.3913);

where ro.xi.jq is a COMPONENT_REF, but ro.xi is of type "struct bl[3]".

The analyzer's handling of COMPONENT_REF assumes that the type of the
1st argument is a RECORD_TYPE or UNION_TYPE, whereas in this case it's
an ARRAY_TYPE, leading to a failed as_a inside
region_model::get_field_region.

This patch fixes the ICE by generalizing the "give up on this tree code"
logic from r10-6667-gf76a88ebf089871dcce215aa0cb1956ccc060895 for
PR analyzer/93388, so that the analyzer gives up when it needs to get an
lvalue for a COMPONENT_REF on something other than a RECORD_TYPE or
UNION_TYPE.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

I think I have permission to self-approve the analyzer part.

Is the Fortran testcase OK for master?

gcc/analyzer/ChangeLog:
PR analyzer/93778
* engine.cc (impl_region_model_context::on_unknown_tree_code):
Rename to...
(impl_region_model_context::on_unexpected_tree_code): ...this and
convert first argument from path_var to tree.
(exploded_node::on_stmt): Pass ctxt to purge_for_unknown_fncall.
* exploded-graph.h (region_model_context::on_unknown_tree_code):
Rename to...
(region_model_context::on_unexpected_tree_code): ...this and
convert first argument from path_var to tree.
* program-state.cc (sm_state_map::purge_for_unknown_fncall): Add
ctxt param and pass on to calls to get_rvalue.
* program-state.h (sm_state_map::purge_for_unknown_fncall): Add
ctxt param.
* region-model.cc (region_model::handle_unrecognized_call): Pass
ctxt on to call to get_rvalue.
(region_model::get_lvalue_1): Move body of default case to
region_model::make_region_for_unexpected_tree_code and call it.
Within COMPONENT_REF case, reject attempts to handle types other
than RECORD_TYPE and UNION_TYPE.
(region_model::make_region_for_unexpected_tree_code): New
function, based on default case of region_model::get_lvalue_1.
* region-model.h
(region_model::make_region_for_unexpected_tree_code): New decl.
(region_model::on_unknown_tree_code): Rename to...
(region_model::on_unexpected_tree_code): ...this and convert first
argument from path_var to tree.
(class test_region_model_context): Update vfunc implementation for
above change.

gcc/testsuite/ChangeLog:
PR analyzer/93778
* gfortran.dg/analyzer/pr93778.f90: New test.
---
 gcc/analyzer/engine.cc| 11 ++---
 gcc/analyzer/exploded-graph.h |  4 +-
 gcc/analyzer/program-state.cc |  9 +++--
 gcc/analyzer/program-state.h  |  3 +-
 gcc/analyzer/region-model.cc  | 40 ---
 gcc/analyzer/region-model.h   | 14 ---
 .../gfortran.dg/analyzer/pr93778.f90  | 11 +
 7 files changed, 61 insertions(+), 31 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/analyzer/pr93778.f90

diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index cd4ffe55dc5..de6bf1d394f 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -684,18 +684,18 @@ impl_region_model_context::on_phi (const gphi *phi, tree 
rhs)
 }
 }
 
-/* Implementation of region_model_context::on_unknown_tree_code vfunc.
+/* Implementation of region_model_context::on_unexpected_tree_code vfunc.
Mark the new state as being invalid for further exploration.
TODO(stage1): introduce a warning for when this occurs.  */
 
 void
-impl_region_model_context::on_unknown_tree_code (path_var pv,
-const dump_location_t &loc)
+impl_region_model_context::on_unexpected_tree_code (tree t,
+   const dump_location_t &loc)
 {
   logger * const logger = get_logger ();
   if (logger)
 logger->log ("unhandled tree code: %qs in %qs at %s:%i",
-get_tree_code_name (TREE_CODE (pv.m_tree)),
+get_tree_code_name (TREE_CODE (t)),
 loc.get_impl_location ().m_function,
 loc.get_impl_location ().m_file,
 loc.get_impl_location ().m_line);
@@ -1093,7 +1093,8 @@ exploded_node::on_stmt (exploded_graph &eg,
 
  if (!fndecl_has_gimple_body_p (callee_fndecl))
new_smap->purge_for_unknown_fncall (eg, sm, call, callee_fndecl,
-   state->m_region_model);
+   state->m_region_model,
+   &ctxt);
}
}
   if (*old_smap != *new_smap)
diff --git a/gcc/analyzer/exploded-graph.h b/gcc/analyzer/exploded-g

[committed] diagnostics: don't generate URLs that won't be used

[David Malcolm]

The two places in diagnostics.c where URLs are printed both do
non-trivial work to generate the URL strings (including malloc/free), so
don't do this work if URL-printing is disabled.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as abb4852434b3dee26301cc406472ac9450c621aa.

gcc/ChangeLog:
* diagnostic.c (print_any_cwe): Don't call get_cwe_url if URLs
won't be printed.
(print_option_information): Don't call get_option_url if URLs
won't be printed.
---
 gcc/diagnostic.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index e4a08f76def..ed52bc03d17 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -983,12 +983,16 @@ print_any_cwe (diagnostic_context *context,
   pp_string (pp, " [");
   pp_string (pp, colorize_start (pp_show_color (pp),
 diagnostic_kind_color[diagnostic->kind]));
-  char *cwe_url = get_cwe_url (cwe);
-  pp_begin_url (pp, cwe_url);
-  free (cwe_url);
+  if (pp->url_format != URL_FORMAT_NONE)
+   {
+ char *cwe_url = get_cwe_url (cwe);
+ pp_begin_url (pp, cwe_url);
+ free (cwe_url);
+   }
   pp_printf (pp, "CWE-%i", cwe);
   pp_set_prefix (context->printer, saved_prefix);
-  pp_end_url (pp);
+  if (pp->url_format != URL_FORMAT_NONE)
+   pp_end_url (pp);
   pp_string (pp, colorize_stop (pp_show_color (pp)));
   pp_character (pp, ']');
 }
@@ -1011,7 +1015,8 @@ print_option_information (diagnostic_context *context,
   if (option_text)
 {
   char *option_url = NULL;
-  if (context->get_option_url)
+  if (context->get_option_url
+ && context->printer->url_format != URL_FORMAT_NONE)
option_url = context->get_option_url (context,
  diagnostic->option_index);
   pretty_printer *pp = context->printer;
-- 
2.21.0

[PATCH] analyzer: fix ICE on failed casts [PR 93777]

[David Malcolm]

PR analyzer/93777 reports ICEs in Fortran and C++ cases involving
a cast of a NULL pointer to a REFERENCE_TYPE.

In both cases the call to build_cast fails and returns a NULL type, but
region_model::maybe_cast_1 asserts that a non-NULL type was returned.

This patch fixes the ICEs by converting the assertion to a conditional.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

I think I have permission to self-approve the analyzer part and the C++
testcase.

Is the Fortran testcase OK for master?

gcc/analyzer/ChangeLog:
PR analyzer/93777
* region-model.cc (region_model::maybe_cast_1): Replace assertion
that build_cast returns non-NULL with a conditional, falling
through to the logic which returns a new unknown value of the
desired type if it fails.

gcc/testsuite/ChangeLog:
PR analyzer/93777
* g++.dg/analyzer/pr93777.C: New test.
* gfortran.dg/analyzer/pr93777.f90: New test.
---
 gcc/analyzer/region-model.cc  |  7 +++---
 gcc/testsuite/g++.dg/analyzer/pr93777.C   |  1 +
 .../gfortran.dg/analyzer/pr93777.f90  | 22 +++
 3 files changed, 26 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/analyzer/pr93777.C
 create mode 100644 gcc/testsuite/gfortran.dg/analyzer/pr93777.f90

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index c8ee031dc8f..d061552da37 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -5089,10 +5089,9 @@ region_model::maybe_cast_1 (tree dst_type, svalue_id sid)
   /* Attempt to cast constants.  */
   if (tree src_cst = sval->maybe_get_constant ())
 {
-  tree dst = build_cast (dst_type, src_cst);
-  gcc_assert (dst != NULL_TREE);
-  if (CONSTANT_CLASS_P (dst))
-   return get_or_create_constant_svalue (dst);
+  if (tree dst = build_cast (dst_type, src_cst))
+   if (CONSTANT_CLASS_P (dst))
+ return get_or_create_constant_svalue (dst);
 }
 
   /* Otherwise, return a new unknown value.  */
diff --git a/gcc/testsuite/g++.dg/analyzer/pr93777.C 
b/gcc/testsuite/g++.dg/analyzer/pr93777.C
new file mode 100644
index 000..e94e75f5e83
--- /dev/null
+++ b/gcc/testsuite/g++.dg/analyzer/pr93777.C
@@ -0,0 +1 @@
+#include "../../g++.old-deja/g++.pt/spec36.C"
diff --git a/gcc/testsuite/gfortran.dg/analyzer/pr93777.f90 
b/gcc/testsuite/gfortran.dg/analyzer/pr93777.f90
new file mode 100644
index 000..1c198358829
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/analyzer/pr93777.f90
@@ -0,0 +1,22 @@
+! { dg-additional-options "-O0 -Wno-analyzer-possible-null-dereference 
-Wno-analyzer-null-dereference -Wno-analyzer-malloc-leak" }
+
+program cb
+  implicit none
+  type :: jn
+ real, allocatable :: ie
+ character(len = :), allocatable :: e5
+  end type jn
+  real, parameter :: gm = 5.0
+
+  block
+type(jn) :: r2
+
+r2 = jn (gm, "")
+call vz (r2%ie, gm)
+  end block
+contains
+  subroutine vz (arg1, arg2)
+real :: arg1, arg2
+if (arg1 .ne. arg2) STOP 1
+  end subroutine vz
+end program cb
-- 
2.21.0

Re: [PATCH] Fix PR66552, Missed optimization when shift amount is result of signed modulus

[Li Jia He]

Hi,

On 2020/2/17 4:30 PM, Richard Biener wrote:

On Mon, 17 Feb 2020, Jakub Jelinek wrote:


On Mon, Feb 17, 2020 at 09:01:13AM +0100, Richard Biener wrote:

On Mon, 17 Feb 2020, Li Jia He wrote:

This patch wants to fix PR66552 on gimple and optimizes (x shift (n mod C))
to (x shift (n bit_and (C - 1))) when C is a constant and power of two as
discussed in PR66552.

The regression testing for the patch was done on GCC mainline on

 powerpc64le-unknown-linux-gnu (Power 9 LE)

with no regressions.  Is it OK for GCC11 ?


I fail to see the connection with a shift operation, can you explain?


As mentioned in the PR, the reason why we can only optimize unsigned
mod C into bit_and C-1 (where C is pow2p) is that signed modulo can be negative 
for
negative values (is non-positive).  For shifts negative values would be UB
and so we can assume it will not be negative (i.e. x will be either positive
or a negative multiple of C) and can use bit_and then.


That's clearly information that should be in the comment before the
pattern.  We could also generally do the transform if we know
the other operand of the modulo is nonnegative.

Also the pattern doing the standalone transform does

/* Optimize TRUNC_MOD_EXPR by a power of two into a BIT_AND_EXPR,
i.e. "X % C" into "X & (C - 1)", if X and C are positive.
Also optimize A % (C << N)  where C is a power of 2,
to A & ((C << N) - 1).  */
(match (power_of_two_cand @1)
  INTEGER_CST@1)
(match (power_of_two_cand @1)
  (lshift INTEGER_CST@1 @2))
(for mod (trunc_mod floor_mod)
  (simplify
   (mod @0 (convert?@3 (power_of_two_cand@1 @2)))
   (if ((TYPE_UNSIGNED (type)
 || tree_expr_nonnegative_p (@0))
 && tree_nop_conversion_p (type, TREE_TYPE (@3))
 && integer_pow2p (@2) && tree_int_cst_sgn (@2) > 0)
(bit_and @0 (convert (minus @1 { build_int_cst (TREE_TYPE (@1), 1);
}))

so it also checks whether @2 is not negative, the new pattern lacks
this and could make use of power_of_two_cand as well (in fact I'd
place it next to the pattern above.



Thank you for your suggestions.  I have modified the code according to your
suggestions. But power_of_two_cand is not used, it will cause pr70354-2.c
failed ((0x1234ULL << (i % 54)) will transfer to (0x1234ULL << (i & 54))).

The regression testing for the patch was done on GCC mainline on powerpc64le
with no regressions.  Would you like to help to see if there are other 
problems?

Thanks in advance.  The code is in the attachment.


Also the above applies for trunc_mod and floor_mod but the proposed
patch applies the transform for ceil_mod and round_mod as well.

Richard.



--
BR,
Lijia He
diff --git a/gcc/match.pd b/gcc/match.pd
index 73834c25593..a8fc7918621 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -598,12 +598,19 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 /* Optimize TRUNC_MOD_EXPR by a power of two into a BIT_AND_EXPR,
i.e. "X % C" into "X & (C - 1)", if X and C are positive.
Also optimize A % (C << N)  where C is a power of 2,
-   to A & ((C << N) - 1).  */
+   to A & ((C << N) - 1).  And optimize "A shift (N % C)" where C
+   is a power of 2 and shift operation included "<<" and ">>",
+   to  "A shift (N & (C - 1))".  */
 (match (power_of_two_cand @1)
  INTEGER_CST@1)
 (match (power_of_two_cand @1)
  (lshift INTEGER_CST@1 @2))
 (for mod (trunc_mod floor_mod)
+ (for shift (lshift rshift)
+  (simplify
+   (shift @0 (mod @1 integer_pow2p@2))
+   (if (tree_expr_nonnegative_p (@2))
+   (shift @0 (bit_and @1 (minus @2 { build_int_cst (TREE_TYPE (@2), 1); }))
  (simplify
   (mod @0 (convert?@3 (power_of_two_cand@1 @2)))
   (if ((TYPE_UNSIGNED (type)
diff --git a/gcc/testsuite/gcc.dg/pr66552.c b/gcc/testsuite/gcc.dg/pr66552.c
new file mode 100644
index 000..7583c9ad25a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr66552.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-lower" } */
+
+unsigned a(unsigned x, int n)
+{
+  return x >> (n % 32);
+}
+
+unsigned b(unsigned x, int n)
+{
+  return x << (n % 32);
+}
+
+/* { dg-final { scan-tree-dump-not " % " "lower" } } */

[PATCH] RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x

[Kito Cheng]

 - fmv.x.s/fmv.s.x renamed to fmv.x.w/fmv.w.x in the latest RISC-V ISA
   manual.

 - Tested rv32gc/rv64gc on bare-metal with qemu.

ChangeLog

gcc/

Kito Cheng  

* config/riscv/riscv.c (riscv_output_move) Using fmv.x.w/fmv.w.x
rather than fmv.x.s/fmv.s.x.
---
 gcc/config/riscv/riscv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index ee51ad7ce1e..5ef74acb56d 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -1917,7 +1917,7 @@ riscv_output_move (rtx dest, rtx src)
   if (dest_code == REG && GP_REG_P (REGNO (dest)))
 {
   if (src_code == REG && FP_REG_P (REGNO (src)))
-   return dbl_p ? "fmv.x.d\t%0,%1" : "fmv.x.s\t%0,%1";
+   return dbl_p ? "fmv.x.d\t%0,%1" : "fmv.x.w\t%0,%1";
 
   if (src_code == MEM)
switch (GET_MODE_SIZE (mode))
@@ -1954,7 +1954,7 @@ riscv_output_move (rtx dest, rtx src)
  if (FP_REG_P (REGNO (dest)))
{
  if (!dbl_p)
-   return "fmv.s.x\t%0,%z1";
+   return "fmv.w.x\t%0,%z1";
  if (TARGET_64BIT)
return "fmv.d.x\t%0,%z1";
  /* in RV32, we can emulate fmv.d.x %0, x0 using fcvt.d.w */
-- 
2.25.0

[PATCH] Add c++2a binary_semaphore

[Thomas Rodgers]

This patch adds the c++2a semaphore header and binary_semaphore type. The 
implementation is not complete, this patch is just to solicit initial feedback.

* include/std/semaphore: New file.
* include/std/version (__cpp_lib_semaphore): Add feature test macro.
* include/Makefile.am (std_headers): add semaphore.
* include/Makefile.in: Regenerate.
* testsuite/30_threads/semaphore/1.cc: New test.
* testsuite/30_threads/semaphore/2.cc: New test.
* testsuite/30_threads/semaphore/binary_semaphore.cc: New test.
* testsuite/30_threads/semaphore/try_acquire.cc: New test.
* testsuite/30_threads/semaphore/try_acquire_for.cc: New test.
* testsuite/30_threads/semaphore/try_acquire_until.cc: New test.

From 8ce4252605361ed33b389a91fb7e3aeec529d9ac Mon Sep 17 00:00:00 2001
From: Thomas Rodgers 
Date: Mon, 17 Feb 2020 19:58:57 -0800
Subject: [PATCH] Add c++2a binary_semaphore

* include/std/semaphore: New file.
* include/std/version (__cpp_lib_semaphore): Add feature test macro.
* include/Makefile.am (std_headers): add semaphore.
* include/Makefile.in: Regenerate.
* testsuite/30_threads/semaphore/1.cc: New test.
* testsuite/30_threads/semaphore/2.cc: New test.
* testsuite/30_threads/semaphore/binary_semaphore.cc: New test.
* testsuite/30_threads/semaphore/try_acquire.cc: New test.
* testsuite/30_threads/semaphore/try_acquire_for.cc: New test.
* testsuite/30_threads/semaphore/try_acquire_until.cc: New test.
---
 libstdc++-v3/include/Makefile.am  |   1 +
 libstdc++-v3/include/Makefile.in  |   1 +
 libstdc++-v3/include/std/semaphore| 131 ++
 libstdc++-v3/include/std/version  |   1 +
 .../testsuite/30_threads/semaphore/1.cc   |  27 
 .../testsuite/30_threads/semaphore/2.cc   |  27 
 .../30_threads/semaphore/binary_semaphore.cc  |  47 +++
 .../30_threads/semaphore/try_acquire.cc   |  36 +
 .../30_threads/semaphore/try_acquire_for.cc   |  72 ++
 .../30_threads/semaphore/try_acquire_until.cc |  74 ++
 10 files changed, 417 insertions(+)
 create mode 100644 libstdc++-v3/include/std/semaphore
 create mode 100644 libstdc++-v3/testsuite/30_threads/semaphore/1.cc
 create mode 100644 libstdc++-v3/testsuite/30_threads/semaphore/2.cc
 create mode 100644 libstdc++-v3/testsuite/30_threads/semaphore/binary_semaphore.cc
 create mode 100644 libstdc++-v3/testsuite/30_threads/semaphore/try_acquire.cc
 create mode 100644 libstdc++-v3/testsuite/30_threads/semaphore/try_acquire_for.cc
 create mode 100644 libstdc++-v3/testsuite/30_threads/semaphore/try_acquire_until.cc

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 89835759069..2dbb7d3a6b1 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -69,6 +69,7 @@ std_headers = \
 	${std_srcdir}/ratio \
 	${std_srcdir}/regex \
 	${std_srcdir}/scoped_allocator \
+  ${std_srcdir}/semaphore \
 	${std_srcdir}/set \
 	${std_srcdir}/shared_mutex \
 	${std_srcdir}/span \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 123d24bb1c6..8f2780c86ce 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -414,6 +414,7 @@ std_headers = \
 	${std_srcdir}/ratio \
 	${std_srcdir}/regex \
 	${std_srcdir}/scoped_allocator \
+  ${std_srcdir}/semaphore \
 	${std_srcdir}/set \
 	${std_srcdir}/shared_mutex \
 	${std_srcdir}/span \
diff --git a/libstdc++-v3/include/std/semaphore b/libstdc++-v3/include/std/semaphore
new file mode 100644
index 000..e3e88a50eec
--- /dev/null
+++ b/libstdc++-v3/include/std/semaphore
@@ -0,0 +1,131 @@
+//  -*- C++ -*-
+
+// Copyright (C) 2019-2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file include/stop_token
+ *  This is a Standard C++ Library header.
+ */
+
+#ifndef _GLIBCXX_SEMAPHORE
+#define _GLIBCXX_SEMAPHORE
+
+#if __cplusplus > 201703L
+#

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

[Stephan Bergmann]

On 18/02/2020 02:20, Patrick Palka wrote:

On Mon, 17 Feb 2020, Stephan Bergmann wrote:

On 04/02/2020 03:07, Patrick Palka wrote:

This patch implements [range.adaptors].  It also includes the changes from
P3280
and P3278 and P3323, without which many standard examples won't work.


I see that with this

"libstdc++: Implement C++20 range adaptors", compiling  with recent
Clang trunk (which appears to mostly implement C++20 concepts now) in
-std=c++2a mode fails as below (besides also failing due to some "missing"
typenames, where Clang apparently doesn't yet implement P0634R3).  And I'm not
sure which of Clang vs. GCC is right here.

The failure is


gcc/trunk/inst/include/c++/10.0.1/ranges:1512:47: error: ambiguous deduction
for template arguments of '_RangeAdaptor'
 inline constexpr __adaptor::_RangeAdaptor filter
   ^
gcc/trunk/inst/include/c++/10.0.1/ranges:1073:2: note: candidate function
[with _Callable = std::ranges::views::(lambda at
gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
 _RangeAdaptor(const _Callable& = {})
 ^
gcc/trunk/inst/include/c++/10.0.1/ranges:1078:2: note: candidate function
[with _Callable = std::ranges::views::(lambda at
gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
 _RangeAdaptor(_Callable __callable)
 ^


and a stripped-down reproducer is


template struct S {
   S(T const &) requires true;
   S(T) requires false;
};
S s = 0;


(Clang accepts this when the last line is replaced with


S s = 0;


and thus no class template argument deduction needs to be done.)

I think what is relevant here is [over.match.class.deduct]/1 in the current
spec, which specifies a helper set of hypothetical function templates based on
a class' constructors for class template argument deduction.  It details the
function templates' template parameters, function parameters, and return
types, but does not mention requires-clauses.  From my superficial
understanding of concepts and class template argument deduction it would thus
look like the constructors' requires-clauses should indeed not be taken into
account here?


Thanks for letting me know about this issue.  That would be my
interpretation of the spec, too.  Maybe someone else could shed light on
this question?

The following patch simplifies _RangeAdaptor's constructors to no longer
need to be constrained and should resolve the deduction ambiguity error
reported by Clang?  Unfortunately the patch triggers an ICE in GCC,
which I'll look into tomorrow.


Thanks, I can confirm that patch works fine with Clang.

Btw, the "missing" typenames for Clang I mentioned above would be fixed 
with the following patch.  I don't know whether you would want to do 
that, as technically the current C++20-only code is fine, but here it is 
anyway:



diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 970e904bddd..c487dd612c2 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1326,7 +1326,7 @@ namespace views
static constexpr auto
_S_iter_cat()
{
- using _Cat = iterator_traits>::iterator_category;
+ using _Cat = typename 
iterator_traits>::iterator_category;
  if constexpr (derived_from<_Cat, bidirectional_iterator_tag>)
return bidirectional_iterator_tag{};
  else if constexpr (derived_from<_Cat, forward_iterator_tag>)
@@ -1549,7 +1549,7 @@ namespace views
  static constexpr auto
  _S_iter_cat()
  {
-   using _Cat = iterator_traits>::iterator_category;
+   using _Cat = typename 
iterator_traits>::iterator_category;
if constexpr (derived_from<_Cat, contiguous_iterator_tag>)
  return random_access_iterator_tag{};
else
@@ -2294,9 +2294,9 @@ namespace views
  _S_iter_cat()
  {
using _OuterCat
- = iterator_traits>::iterator_category;
+ = typename iterator_traits>::iterator_category;
using _InnerCat
- = iterator_traits>>
+ = typename iterator_traits>>
 ::iterator_category;
if constexpr (_S_ref_is_glvalue
  && derived_from<_OuterCat, bidirectional_iterator_tag>
@@ -2765,7 +2765,7 @@ namespace views
  static constexpr auto
  _S_iter_cat()
  {
-   using _Cat = iterator_traits>::iterator_category;
+   using _Cat = typename 
iterator_traits>::iterator_category;
if constexpr (derived_from<_Cat, forward_iterator_tag>)
  return forward_iterator_tag{};
else

[committed] Typo fixes - functoin -> function [PR93796]

[Jakub Jelinek]

Hi!

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

2020-02-18  Jakub Jelinek  

PR driver/93796
* params.opt (-param=ipa-max-switch-predicate-bounds=): Fix help
typo, functoin -> function.
* tree.c (free_lang_data_in_decl): Fix comment typo,
functoin -> function.
* ipa-visibility.c (cgraph_externally_visible_p): Likewise.

--- gcc/params.opt.jj   2020-01-17 23:34:48.325980708 +0100
+++ gcc/params.opt  2020-02-18 00:47:41.041749841 +0100
@@ -236,7 +236,7 @@ Maximum number of operations in a parame
 
 -param=ipa-max-switch-predicate-bounds=
 Common Joined UInteger Var(param_ipa_max_switch_predicate_bounds) Init(5) 
Param Optimization
-Maximal number of boundary endpoints of case ranges of switch statement used 
during IPA functoin summary generation.
+Maximal number of boundary endpoints of case ranges of switch statement used 
during IPA function summary generation.
 
 -param=ipa-sra-max-replacements=
 Common Joined UInteger Var(param_ipa_sra_max_replacements) Optimization 
Init(8) IntegerRange(0, 16) Param
--- gcc/tree.c.jj   2020-01-27 22:40:57.044420315 +0100
+++ gcc/tree.c  2020-02-18 00:47:56.004531197 +0100
@@ -5803,7 +5803,7 @@ free_lang_data_in_decl (tree decl, class
 }
   else if (VAR_P (decl))
 {
-  /* See comment above why we set the flag for functoins.  */
+  /* See comment above why we set the flag for functions.  */
   if (TREE_PUBLIC (decl))
TREE_ADDRESSABLE (decl) = true;
   if ((DECL_EXTERNAL (decl)
--- gcc/ipa-visibility.c.jj 2020-01-14 20:02:46.203618522 +0100
+++ gcc/ipa-visibility.c2020-02-18 00:47:23.504006116 +0100
@@ -230,7 +230,7 @@ cgraph_externally_visible_p (struct cgra
 
   if (node->resolution == LDPR_PREVAILING_DEF_IRONLY)
 return false;
-  /* When doing LTO or whole program, we can bring COMDAT functoins static.
+  /* When doing LTO or whole program, we can bring COMDAT functions static.
  This improves code quality and we know we will duplicate them at most 
twice
  (in the case that we are not using plugin and link with object file
   implementing same COMDAT)  */

Jakub

Re: [PATCH] analyzer: fix ICE on pointer arithmetic with incomplete types [PR 93774]

[Thomas König]

Hi David

in principle, any valid test case (especially for an ICE) should count as 
obvious and simple, so no approval should be needed.

Having said that, I think I would prefer a copy of the original test case 
rather than an include statement. Although we usually do not change or remove 
test cases, sometimes it is done for one reason or anotjer, and in this case I 
would prefer that the derived test case does not change automatically.

So, all four of your test cases are OK if you change those which use include to 
a plain test case, maybe with a comment pointing to the original one. In the 
future, you can just commit this kind of test case as simple and obvious; we 
would appreciate a note to fortran@ if you do so.

Regards

Thomas

[PATCH] ipa: Various diagnostic fixes [PR93797]

[Jakub Jelinek]

Hi!

As the patch shows, various messages didn't match the field names they are
talking about.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2020-02-18  Jakub Jelinek  

PR ipa/93797
* cgraph.c (verify_speculative_call): Use speculative_id instead of
speculative_uid in messages.  Remove trailing whitespace from error
message.  Use num_speculative_call_targets instead of
num_speculative_targets in a message.
(cgraph_node::verify_node): Use call_stmt instead of cal_stmt in
edge messages and stmt instead of cal_stmt in reference message.

--- gcc/cgraph.c.jj 2020-01-29 22:59:09.171316837 +0100
+++ gcc/cgraph.c2020-02-18 00:55:16.163028107 +0100
@@ -3230,14 +3230,14 @@ verify_speculative_call (struct cgraph_n
if (direct->speculative_id >= num)
  {
error ("direct call to %s in speculative call sequence has "
-  "speculative_uid %i out of range",
+  "speculative_id %i out of range",
   direct->callee->dump_name (), direct->speculative_id);
return true;
  }
if (direct_calls[direct->speculative_id])
  {
error ("duplicate direct call to %s in speculative call sequence "
-  "with speculative_uid %i",
+  "with speculative_id %i",
   direct->callee->dump_name (), direct->speculative_id);
return true;
  }
@@ -3248,7 +3248,7 @@ verify_speculative_call (struct cgraph_n
   && first_call != node->get_edge (first_call->call_stmt))
 {
   error ("call stmt hash does not point to first direct edge of "
-"speculative call sequence ");
+"speculative call sequence");
   return true;
 }
 
@@ -3260,14 +3260,14 @@ verify_speculative_call (struct cgraph_n
if (ref->speculative_id >= num)
  {
error ("direct call to %s in speculative call sequence has "
-  "speculative_uid %i out of range",
+  "speculative_id %i out of range",
   ref->referred->dump_name (), ref->speculative_id);
return true;
  }
if (refs[ref->speculative_id])
  {
error ("duplicate reference %s in speculative call sequence "
-  "with speculative_uid %i",
+  "with speculative_id %i",
   ref->referred->dump_name (), ref->speculative_id);
return true;
  }
@@ -3294,7 +3294,7 @@ verify_speculative_call (struct cgraph_n
   if (num_targets != indirect->num_speculative_call_targets_p ())
 {
   error ("number of speculative targets %i mismatched with "
-"num_speculative_targets %i",
+"num_speculative_call_targets %i",
 num_targets,
 indirect->num_speculative_call_targets_p ());
   return true;
@@ -3400,7 +3400,7 @@ cgraph_node::verify_node (void)
}
   if (e->call_stmt && e->lto_stmt_uid)
{
- error ("edge has both cal_stmt and lto_stmt_uid set");
+ error ("edge has both call_stmt and lto_stmt_uid set");
  error_found = true;
}
 }
@@ -3471,7 +3471,7 @@ cgraph_node::verify_node (void)
}
   if (e->call_stmt && e->lto_stmt_uid)
{
- error ("edge has both cal_stmt and lto_stmt_uid set");
+ error ("edge has both call_stmt and lto_stmt_uid set");
  error_found = true;
}
   if (e->speculative
@@ -3509,7 +3509,7 @@ cgraph_node::verify_node (void)
 {
   if (ref->stmt && ref->lto_stmt_uid)
{
- error ("reference has both cal_stmt and lto_stmt_uid set");
+ error ("reference has both stmt and lto_stmt_uid set");
  error_found = true;
}
   if (ref->speculative

Jakub