Re: Backports to 9.3

[H.J. Lu]

On Thu, Feb 13, 2020 at 2:46 PM Jakub Jelinek  wrote:
>
> Hi!
>
> I've backported following 15 commits from trunk to 9.3 branch,
> bootstrapped/regtested on x86_64-linux and i686-linux, committed.
>

Hi Jakub,

Are you preparing for GCC 9.3? I'd like to include this in GCC 9.3:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1d69147af203d4dcd2270429f90c93f1a37ddfff

It is very safe.  Uros asked me to wait for a week before backporting to
GCC 9 branch.  I am planning to do it next Thursday.

Thanks.

-- 
H.J.

Re: [PATCH]Several intrinsic macros lack a closing parenthesis[PR93274]

[Hongtao Liu]

Done.

On Fri, Feb 14, 2020 at 7:16 PM Uros Bizjak  wrote:
>
> On Fri, Feb 14, 2020 at 8:06 AM Uros Bizjak  wrote:
> >
> > On Fri, Feb 14, 2020 at 7:03 AM Hongtao Liu  wrote:
> > >
> > > On Thu, Feb 13, 2020 at 5:31 PM Hongtao Liu  wrote:
> > > >
> > > > On Thu, Feb 13, 2020 at 5:12 PM Uros Bizjak  wrote:
> > > > >
> > > > > On Thu, Feb 13, 2020 at 9:53 AM Jakub Jelinek  
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Feb 13, 2020 at 09:39:05AM +0100, Uros Bizjak wrote:
> > > > > > > > Changelog
> > > > > > > > gcc/
> > > > > > > >* config/i386/avx512vbmi2intrin.h
> > > > > > > >(_mm512_[,mask_,maskz_]shrdi_epi16,
> > > > > > > >_mm512_[,mask_,maskz_]shrdi_epi32,
> > > > > > > >_m512_[,mask_,maskz_]shrdi_epi64,
> > > > > > > >_mm512_[,mask_,maskz_]shldi_epi16,
> > > > > > > >_mm512_[,mask_,maskz_]shldi_epi32,
> > > > > > > >_m512_[,mask_,maskz_]shldi_epi64): Fix typo of lacking a
> > > > > > > >closing parenthesis.
> > > > > > > >* config/i386/avx512vbmi2vlintrin.h
> > > > > > > >(_mm256_[,mask_,maskz_]shrdi_epi16,
> > > > > > > >_mm256_[,mask_,maskz_]shrdi_epi32,
> > > > > > > >_m256_[,mask_,maskz_]shrdi_epi64,
> > > > > > > >_mm_[,mask_,maskz_]shrdi_epi16,
> > > > > > > >_mm_[,mask_,maskz_]shrdi_epi32,
> > > > > > > >_mm_[,mask_,maskz_]shrdi_epi64,
> > > > > > > >_mm256_[,mask_,maskz_]shldi_epi16,
> > > > > > > >_mm256_[,mask_,maskz_]shldi_epi32,
> > > > > > > >_m256_[,mask_,maskz_]shldi_epi64,
> > > > > > > >_mm_[,mask_,maskz_]shldi_epi16,
> > > > > > > >_mm_[,mask_,maskz_]shldi_epi32,
> > > > > > > >_mm_[,mask_,maskz_]shldi_epi64): Ditto.
> > > > > > > >
> > > > > > > > gcc/testsuite/
> > > > > > > >* gcc.target/i386/avx512vbmi2-vpshld-1.c: New test.
> > > > > > > >* gcc.target/i386/avx512vbmi2-vpshld-O0-1.c: Ditto.
> > > > > > > >* gcc.target/i386/avx512vbmi2-vpshrd-1.c: Ditto.
> > > > > > > >* gcc.target/i386/avx512vbmi2-vpshrd-O0-1.c: Ditto.
> > > > > > > >* gcc.target/i386/avx512vl-vpshld-O0-1.c: Ditto.
> > > > > > > >* gcc.target/i386/avx512vl-vpshrd-O0-1.c: Ditto.
> > > > > > >
> > > > > > > This is obvious patch, so OK for mainline and backports.
> > > > > >
> > > > > > The header changes sure, but for the testsuite, the standard way
> > > > > > would be to have it covered in the standard tests we have for this.
> > > > > > I think that is gcc.target/i386/sse-{13,14,22a,23}.c, so it would 
> > > > > > be worth
> > > > > > trying to figure out why it hasn't caught that.
> > > > >
> > > > > Indeed. It looks that these macros are not listed in sse-14.c, which
> > > > > would catch the problem. So, there is no need for new -O0 tests,
> > > > > please add missing functions to sse-14.c and sse-22.c testcases. I was
> > > > > also surprised that no testsuite coverage for vbmi2 functions was
> > > > > added at submission.
> > > > >
> > > > Yes, i saw that, thanks.
> > > > > Uros.
> > > > >
> > > > > > And, I don't think we allow any wildcards etc. (and 
> > > > > > [,whatever,whateverelse]
> > > > > > isn't even one, neither regexp nor shell wildcard) in the names of 
> > > > > > functions
> > > > > > changed, they can appear in the description text, but for the names 
> > > > > > of
> > > > > > macros one needs to list them all expanded, people do grep for 
> > > > > > those.
> > > > > >
> > > > > > Jakub
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > BR,
> > > > Hongtao
> > >
> > > Update patch:
> > > Update Changelog, delete O0 testcase, and add testcase in sse-14.c, 
> > > sse-22.c
> >
> > OK.
>
> Please also commit ChangeLog entries to relevant ChangeLog files.
>
> Uros.



-- 
BR,
Hongtao

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

[Richard Biener]

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

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?

Thanks,
Richard.

2020-02-14  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..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);
 }
 }
 
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: Backports to 9.3

[Jakub Jelinek]

On Fri, Feb 14, 2020 at 07:45:43AM -0800, H.J. Lu wrote:
> Are you preparing for GCC 9.3? I'd like to include this in GCC 9.3:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1d69147af203d4dcd2270429f90c93f1a37ddfff
> 
> It is very safe.  Uros asked me to wait for a week before backporting to
> GCC 9 branch.  I am planning to do it next Thursday.

Richi wants to do 8.4 first, am backporting a lot of patches to that now.
I'd say we should aim for 8.4 rc next week or say on Monday 24th
and release a week after that and 9.3 maybe one week later than that.

Jakub

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

[Richard Earnshaw (lists)]

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.


R.


Thanks,
Andrew Pinski




R.

OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

ChangeLog:
* config/aarch64/aarch64.c (aarch64_override_options): Don't
warn when the selected cpu was generic.
---
   gcc/config/aarch64/aarch64.c | 6 --
   1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4a34dce..9173afe 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -14075,10 +14075,12 @@ aarch64_override_options (void)
   explicit_tune_core = selected_tune->ident;
   }
 /* If both -mcpu and -march are specified check that they are 
architecturally
- compatible, warn if they're not and prefer the -march ISA flags.  */
+ compatible, warn if they're not and prefer the -march ISA flags.
+ Only warn if not using the generic cpu.  */
 else if (selected_arch)
   {
-  if (selected_arch->arch != selected_cpu->arch)
+  if (selected_cpu->ident != generic
+   && selected_arch->arch != selected_cpu->arch)
   {
 warning (0, "switch %<-mcpu=%s%> conflicts with %<-march=%s%> switch",
  all_architectures[selected_cpu->arch].name,

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

[Mark Eggleston]

Please find attached a patch fixing the ICE in PR93714.

Tested on:

master at https://gcc.gnu.org/g:e235031d490e8ed2aa0bc229694975493fd58977
gcc 9 branch at 
https://gcc.gnu.org/g:d7ab361df604fb66e1ba1e3fb45b4453cba803c4
gcc 8 branch at 
https://gcc.gnu.org/g:1b169f1ea0c9fab7712ede65edb0ffb6e021ad7c


All test OK, however, gcc 9 and gcc 8 report:

XPASS: gfortran.dg/typebound_call_22.f03   -O scan-tree-dump-times 
optimized "base \\(\\);" 1


with and without the patch.

Note: there is a change in error message handled by 
char_pointer_assign_6.f90


    9 |   p1 => c(1:) ! { dg-error "Pointer assignment target" }
  |  1
Error: Unequal character lengths (20/4) in pointer assignment at (1)
char_pointer_assign_6.f90:10:2:

   10 |   p1 => c(:4) ! { dg-error "Pointer assignment target" }
  |  1
Error: Unequal character lengths (20/4) in pointer assignment at (1)

the following is reported:

    9 |   p1 => c(1:) ! { dg-error "Pointer assignment target" }
  |    1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
char_pointer_assign_6.f90:10:8:

   10 |   p1 => c(:4) ! { dg-error "Pointer assignment target" }
  |    1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)

this is because c does not have TARGET or POINTER attributes specified.

Change logs:

gcc/fortran/ChangeLog

    Mark Eggleston  

    PR fortran/93714
    * expr.c (gfc_check_pointer_assign): Move check for
    matching character length to after checking the lvalue
    attributes for target or pointer.

gcc/testsuite/ChangeLog

    Mark Eggleston  

    PR fortran/93714
    * gfortran.dg/char_pointer_assign_6.f90: Look for no target
    message instead of length mismatch.
    * gfortran.dg/pr93714_1.f90
    * gfortran.dg/pr93714_2.f90

OK to commit?

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

>From 9c83f31b3ed530c605356cd7459e150e2284c5e0 Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Thu, 13 Feb 2020 15:58:20 +
Subject: [PATCH] fortran: ICE assign character pointer to non target PR93714

An ICE occurred if an attempt was made to assign a pointer to a
character variable that has an length incorrectly specified using
a real constant and does not have the target attribute.

gcc/fortran/ChangeLog

	PR fortran/93714
	* expr.c (gfc_check_pointer_assign): Move check for
	matching character length to after checking the lvalue
	attributes for target or pointer.

gcc/testsuite/ChangeLog

	PR fortran/93714
	* gfortran.dg/char_pointer_assign_6.f90: Look for no target
	message instead of length mismatch.
	* gfortran.dg/pr93714_1.f90
	* gfortran.dg/pr93714_2.f90
---
 gcc/fortran/expr.c  | 14 +++---
 gcc/testsuite/gfortran.dg/char_pointer_assign_6.f90 |  4 ++--
 gcc/testsuite/gfortran.dg/pr93714_1.f90 | 11 +++
 gcc/testsuite/gfortran.dg/pr93714_2.f90 | 11 +++
 4 files changed, 31 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr93714_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/pr93714_2.f90

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index a9698c3e3d2..79e00b4112a 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4222,13 +4222,6 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue,
   if (rvalue->expr_type == EXPR_NULL)
 return true;
 
-  if (lvalue->ts.type == BT_CHARACTER)
-{
-  bool t = gfc_check_same_strlen (lvalue, rvalue, "pointer assignment");
-  if (!t)
-	return false;
-}
-
   if (rvalue->expr_type == EXPR_VARIABLE && is_subref_array (rvalue))
 lvalue->symtree->n.sym->attr.subref_array_pointer = 1;
 
@@ -4284,6 +4277,13 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue,
 	}
 }
 
+  if (lvalue->ts.type == BT_CHARACTER)
+{
+  bool t = gfc_check_same_strlen (lvalue, rvalue, "pointer assignment");
+  if (!t)
+	return false;
+}
+
   if (is_pure && gfc_impure_variable (rvalue->symtree->n.sym))
 {
   gfc_error ("Bad target in pointer assignment in PURE "
diff --git a/gcc/testsuite/gfortran.dg/char_pointer_assign_6.f90 b/gcc/testsuite/gfortran.dg/char_pointer_assign_6.f90
index cd90bfc06e3..e0e116074ae 100644
--- a/gcc/testsuite/gfortran.dg/char_pointer_assign_6.f90
+++ b/gcc/testsuite/gfortran.dg/char_pointer_assign_6.f90
@@ -6,6 +6,6 @@ program main
   character (len=4) :: c
   s1 = 'abcd'
   p1 => s1(2:3) ! { dg-error "Unequal character lengths \\(20/2\\)" }
-  p1 => c(1:) ! { dg-error "Unequal character lengths \\(20/4\\)" }
-  p1 => c(:4) ! { dg-error "Unequal character lengths \\(20/4\\)" }
+  p1 => c(1:) ! { dg-error "Pointer assignment target" }
+  p1 => c(:4) ! { dg-error "Pointer assignment target" }
 end
diff --git a/gcc/testsuite/gfortran.dg/pr93714_1.f90 b/gcc/testsuite/gfortran.dg/pr93714_1.f90
new file mode 100644
index 000..40f4a4bf89f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93714_1.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR 93714
+! 

[PATCH 2/3] libstdc++: Convert the ranges algorithm entities into function objects

[Patrick Palka]

This is the standard way to inhibit ADL for these entities, which is required as
per [algorithms.requirements] p2 and [specialized.algorithms] p4.  The
conversion was done mostly mechanically with a custom Vim macro.

[  To make it easier to review, the diffstat below was generated with the -w
   flag, which ignores all changes to whitespace.  Formatting will be fixed in a
   subsequent patch.  ]

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h: (adjacent_find, all_of, any_of,
binary_search, copy_if, count, count_if, equal_range, find, find_end,
find_first_of, find_if, find_if_not, for_each, generate, generate_n,
includes, inplace_merge, is_heap, is_heap_until, is_partitioned,
is_permutation, is_sorted, is_sorted_until, lexicographical_compare,
lower_bound, make_heap, max, max_element, merge, min, min_element,
minmax, minmax_element, mismatch, next_permutation, none_of,
nth_element, partial_sort, partial_sort_copy, partition, partition_copy,
partition_point, pop_heap, prev_permutation, push_heap, remove,
remove_copy, remove_copy_if, remove_if, replace, replace_copy,
replace_copy_if, replace_if, reverse, reverse_copy, rotate, rotate_copy,
search, search_n, set_difference, set_intersection,
set_symmetric_difference, set_union, shuffle, sort, sort_heap,
stable_partition, stable_sort, swap_ranges, transform, unique,
unique_copy, upper_bound): Convert into function objects.
* include/bits/ranges_algobase.h: (equal, copy, move, copy_n, fill_n,
fill, move_backward, copy_backward): Likewise.
* include/bits/ranges_uninitialized.h (uninitialized_default_construct,
uninitialized_default_construct_n, uninitialized_value_construct,
uninitialized_value_construct_n, uninitialized_copy,
uninitialized_copy_n, uninitialized_move, uninitialized_move_n,
uninitialized_fill, uninitialized_fill_n, construct_at, destroy_at,
destroy, destroy_n): Likewise.
---
 libstdc++-v3/include/bits/ranges_algo.h   | 1019 +++--
 libstdc++-v3/include/bits/ranges_algobase.h   |   86 +-
 .../include/bits/ranges_uninitialized.h   |  145 ++-
 3 files changed, 868 insertions(+), 382 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index 6b6f4defdf5..af6d1722998 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -67,11 +67,13 @@ namespace ranges
   }
   } // namespace __detail
 
+  struct __all_of_fn
+  {
 template _Sent,
 typename _Proj = identity,
 indirect_unary_predicate> _Pred>
   constexpr bool
-all_of(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
+  operator()(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {}) 
const
   {
for (; __first != __last; ++__first)
  if (!(bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
@@ -82,17 +84,22 @@ namespace ranges
 template, _Proj>> 
_Pred>
   constexpr bool
-all_of(_Range&& __r, _Pred __pred, _Proj __proj = {})
+  operator()(_Range&& __r, _Pred __pred, _Proj __proj = {}) const
   {
-  return ranges::all_of(ranges::begin(__r), ranges::end(__r),
+   return (*this)(ranges::begin(__r), ranges::end(__r),
   std::move(__pred), std::move(__proj));
   }
+  };
+
+  inline constexpr __all_of_fn all_of{};
 
+  struct __any_of_fn
+  {
 template _Sent,
 typename _Proj = identity,
 indirect_unary_predicate> _Pred>
   constexpr bool
-any_of(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
+  operator()(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {}) 
const
   {
for (; __first != __last; ++__first)
  if (std::__invoke(__pred, std::__invoke(__proj, *__first)))
@@ -103,17 +110,22 @@ namespace ranges
 template, _Proj>> 
_Pred>
   constexpr bool
-any_of(_Range&& __r, _Pred __pred, _Proj __proj = {})
+  operator()(_Range&& __r, _Pred __pred, _Proj __proj = {}) const
   {
-  return ranges::any_of(ranges::begin(__r), ranges::end(__r),
+   return (*this)(ranges::begin(__r), ranges::end(__r),
  std::move(__pred), std::move(__proj));
   }
+  };
 
+  inline constexpr __any_of_fn any_of{};
+
+  struct __none_of_fn
+  {
 template _Sent,
 typename _Proj = identity,
 indirect_unary_predicate> _Pred>
   constexpr bool
-none_of(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
+  operator()(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {}) 
const
   {
for (; __first != __last; ++__first)
  if (std::__invoke(__pred, std::__invoke(__proj, *__first)))
@@ -124,11 +136,14 @@ namespace ranges
 template, _Proj>> 
_Pred>
   constexpr bool
-

[PATCH 1/3] libstdc++: Fold some ranges algo subroutines into their only caller

[Patrick Palka]

These subroutines have only a single call site, so it might be best and simplest
to eliminate them before we convert the algos into function objects.

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (ranges::__find_end): Fold into ...
(ranges::find_end): ... here.
(ranges::__lexicographical_compare): Fold into ...
(ranges::lexicographical_compare): ... here.
* include/bits/ranges_algobase.h (ranges::__equal): Fold into ...
(ranges::equal): ... here.
---
 libstdc++-v3/include/bits/ranges_algo.h | 104 
 libstdc++-v3/include/bits/ranges_algobase.h |  33 +++
 2 files changed, 55 insertions(+), 82 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index 84a02cabb80..6b6f4defdf5 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -513,40 +513,7 @@ namespace ranges
  std::move(__pred), std::move(__proj));
 }
 
-  template _Sent1,
-  forward_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
-  typename _Pred = ranges::equal_to,
-  typename _Proj1 = identity, typename _Proj2 = identity>
-requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
-constexpr subrange<_Iter1>
-__find_end(_Iter1 __first1, _Sent1 __last1,
-  _Iter2 __first2, _Sent2 __last2,
-  _Pred __pred, _Proj1 __proj1, _Proj2 __proj2)
-{
-  auto __i = ranges::next(__first1, __last1);
-  if (__first2 == __last2)
-   return {__i, __i};
 
-  auto __result_begin = __i;
-  auto __result_end = __i;
-  for (;;)
-   {
- auto __new_range = ranges::search(__first1, __last1,
-   __first2, __last2,
-   __pred, __proj1, __proj2);
- auto __new_result_begin = ranges::begin(__new_range);
- auto __new_result_end = ranges::end(__new_range);
- if (__new_result_begin == __last1)
-   return {__result_begin, __result_end};
- else
-   {
- __result_begin = __new_result_begin;
- __result_end = __new_result_end;
- __first1 = __result_begin;
- ++__first1;
-   }
-   }
-}
 
   template _Sent1,
   forward_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
@@ -578,9 +545,31 @@ namespace ranges
return {__result_first, __result_last};
}
   else
-   return ranges::__find_end(__first1, __last1, __first2, __last2,
- std::move(__pred),
- std::move(__proj1), std::move(__proj2));
+   {
+ auto __i = ranges::next(__first1, __last1);
+ if (__first2 == __last2)
+   return {__i, __i};
+
+ auto __result_begin = __i;
+ auto __result_end = __i;
+ for (;;)
+   {
+ auto __new_range = ranges::search(__first1, __last1,
+   __first2, __last2,
+   __pred, __proj1, __proj2);
+ auto __new_result_begin = ranges::begin(__new_range);
+ auto __new_result_end = ranges::end(__new_range);
+ if (__new_result_begin == __last1)
+   return {__result_begin, __result_end};
+ else
+   {
+ __result_begin = __new_result_begin;
+ __result_end = __new_result_end;
+ __first1 = __result_begin;
+ ++__first1;
+   }
+   }
+   }
 }
 
   template _Sent1,
   input_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
-  typename _Proj1, typename _Proj2,
+  typename _Proj1 = identity, typename _Proj2 = identity,
   indirect_strict_weak_order,
- projected<_Iter2, _Proj2>> _Comp>
+ projected<_Iter2, _Proj2>>
+_Comp = ranges::less>
 constexpr bool
-__lexicographical_compare(_Iter1 __first1, _Sent1 __last1,
- _Iter2 __first2, _Sent2 __last2,
- _Comp __comp, _Proj1 __proj1, _Proj2 __proj2)
+lexicographical_compare(_Iter1 __first1, _Sent1 __last1,
+   _Iter2 __first2, _Sent2 __last2,
+   _Comp __comp = {},
+   _Proj1 __proj1 = {}, _Proj2 __proj2 = {})
 {
+  if constexpr (__detail::__is_normal_iterator<_Iter1>
+   || __detail::__is_normal_iterator<_Iter2>)
+   return ranges::lexicographical_compare
+(std::__niter_base(std::move(__first1)),
+ std::__niter_base(std::move(__last1)),
+ std::__niter_base(std::move(__first2)),
+ std::__niter_base(std::move(__last2)),
+ 

[PATCH 3/3] libstdc++: Post-conversion whitespace and formatting adjustments

[Patrick Palka]

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h: Adjust whitespace and formatting.
* include/bits/ranges_algobase.h: Likewise.
* include/bits/ranges_uninitialized.h: Likewise.
---
 libstdc++-v3/include/bits/ranges_algo.h   | 631 ++
 libstdc++-v3/include/bits/ranges_algobase.h   |  39 +-
 .../include/bits/ranges_uninitialized.h   |  38 +-
 3 files changed, 376 insertions(+), 332 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index af6d1722998..7f8f0fb964b 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -73,7 +73,8 @@ namespace ranges
 typename _Proj = identity,
 indirect_unary_predicate> _Pred>
   constexpr bool
-  operator()(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {}) 
const
+  operator()(_Iter __first, _Sent __last,
+_Pred __pred, _Proj __proj = {}) const
   {
for (; __first != __last; ++__first)
  if (!(bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
@@ -82,7 +83,8 @@ namespace ranges
   }
 
 template, _Proj>> 
_Pred>
+indirect_unary_predicate, _Proj>>
+  _Pred>
   constexpr bool
   operator()(_Range&& __r, _Pred __pred, _Proj __proj = {}) const
   {
@@ -99,7 +101,8 @@ namespace ranges
 typename _Proj = identity,
 indirect_unary_predicate> _Pred>
   constexpr bool
-  operator()(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {}) 
const
+  operator()(_Iter __first, _Sent __last,
+_Pred __pred, _Proj __proj = {}) const
   {
for (; __first != __last; ++__first)
  if (std::__invoke(__pred, std::__invoke(__proj, *__first)))
@@ -108,12 +111,13 @@ namespace ranges
   }
 
 template, _Proj>> 
_Pred>
+indirect_unary_predicate, _Proj>>
+  _Pred>
   constexpr bool
   operator()(_Range&& __r, _Pred __pred, _Proj __proj = {}) const
   {
return (*this)(ranges::begin(__r), ranges::end(__r),
- std::move(__pred), std::move(__proj));
+  std::move(__pred), std::move(__proj));
   }
   };
 
@@ -125,7 +129,8 @@ namespace ranges
 typename _Proj = identity,
 indirect_unary_predicate> _Pred>
   constexpr bool
-  operator()(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {}) 
const
+  operator()(_Iter __first, _Sent __last,
+_Pred __pred, _Proj __proj = {}) const
   {
for (; __first != __last; ++__first)
  if (std::__invoke(__pred, std::__invoke(__proj, *__first)))
@@ -134,7 +139,8 @@ namespace ranges
   }
 
 template, _Proj>> 
_Pred>
+indirect_unary_predicate, _Proj>>
+  _Pred>
   constexpr bool
   operator()(_Range&& __r, _Pred __pred, _Proj __proj = {}) const
   {
@@ -183,7 +189,7 @@ namespace ranges
   operator()(_Range&& __r, _Fun __f, _Proj __proj = {}) const
   {
return (*this)(ranges::begin(__r), ranges::end(__r),
-   std::move(__f), std::move(__proj));
+  std::move(__f), std::move(__proj));
   }
   };
 
@@ -196,7 +202,8 @@ namespace ranges
   requires indirect_binary_predicate, const _Tp*>
   constexpr _Iter
-  operator()(_Iter __first, _Sent __last, const _Tp& __value, _Proj __proj 
= {}) const
+  operator()(_Iter __first, _Sent __last,
+const _Tp& __value, _Proj __proj = {}) const
   {
while (__first != __last
&& !(std::__invoke(__proj, *__first) == __value))
@@ -211,8 +218,8 @@ namespace ranges
   constexpr safe_iterator_t<_Range>
   operator()(_Range&& __r, const _Tp& __value, _Proj __proj = {}) const
   {
-   return (*this)(ranges::begin(__r), ranges::end(__r), __value,
-   std::move(__proj));
+   return (*this)(ranges::begin(__r), ranges::end(__r),
+  __value, std::move(__proj));
   }
   };
 
@@ -224,7 +231,8 @@ namespace ranges
 typename _Proj = identity,
 indirect_unary_predicate> _Pred>
   constexpr _Iter
-  operator()(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {}) 
const
+  operator()(_Iter __first, _Sent __last,
+_Pred __pred, _Proj __proj = {}) const
   {
while (__first != __last
&& !(bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
@@ -239,7 +247,7 @@ namespace ranges
   operator()(_Range&& __r, _Pred __pred, _Proj __proj = {}) const
   {
return (*this)(ranges::begin(__r), ranges::end(__r),
-  std::move(__pred), std::move(__proj));
+  std::move(__pred), std::move(__proj));
   }
   };
 
@@ -251,7 +259,8 @@ namespace ranges
 

[SPARC] Fix PR target/93704

[Eric Botcazou]

This is an old thinko pertaining to the interaction between TLS sequences and 
delay slot filling: the compiler knows that it cannot put instructions with 
TLS relocations into delay slots with the original Sun TLS model, but it tests 
TARGET_SUN_TLS in this context, which depends only on the assembler.  So if 
the compiler is configured with the GNU assembler and the Solaris linker, then 
TARGET_GNU_TLS is set instead and the limitation is not enforced.

Tested on SPARC/Solaris and SPARC64/Linux, applied on all active branches.


2020-02-14  Eric Botcazou  

PR target/93704
* config/sparc/sparc.c (eligible_for_call_delay): Test HAVE_GNU_LD in
conjunction with TARGET_GNU_TLS in early return.

-- 
Eric Botcazoudiff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 7e05e1a6f82..aefced85fe1 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -3959,11 +3959,8 @@ eligible_for_call_delay (rtx_insn *trial)
   if (get_attr_in_branch_delay (trial) == IN_BRANCH_DELAY_FALSE)
 return 0;
 
-  /* Binutils allows
-   call __tls_get_addr, %tgd_call (foo)
-add %l7, %o0, %o0, %tgd_add (foo)
- while Sun as/ld does not.  */
-  if (TARGET_GNU_TLS || !TARGET_TLS)
+  /* The only problematic cases are TLS sequences with Sun as/ld.  */
+  if ((TARGET_GNU_TLS && HAVE_GNU_LD) || !TARGET_TLS)
 return 1;
 
   pat = PATTERN (trial);

Re: Backports to 9.3

[H.J. Lu]

On Fri, Feb 14, 2020 at 7:51 AM Jakub Jelinek  wrote:
>
> On Fri, Feb 14, 2020 at 07:45:43AM -0800, H.J. Lu wrote:
> > Are you preparing for GCC 9.3? I'd like to include this in GCC 9.3:
> >
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1d69147af203d4dcd2270429f90c93f1a37ddfff
> >
> > It is very safe.  Uros asked me to wait for a week before backporting to
> > GCC 9 branch.  I am planning to do it next Thursday.
>
> Richi wants to do 8.4 first, am backporting a lot of patches to that now.
> I'd say we should aim for 8.4 rc next week or say on Monday 24th

I am planning to back it to both GCC 8 and 9 branches next Thursday.
I think I will be fine.

> and release a week after that and 9.3 maybe one week later than that.
>
> Jakub
>

Thanks.


-- 
H.J.

Re: [PATCH 00/14] rs6000: Begin replacing built-in support

[Mike Stump]

On Feb 4, 2020, at 9:40 AM, Segher Boessenkool  
wrote:
>> My intent is to make adding new built-in functions as simple as adding
>> a few lines to a couple of files, and automatically generating as much
>> of the initialization, overload resolution, and expansion logic as
>> possible.  This patch series establishes the format of the input files
>> and creates a new program (rs6000-genbif) to:
> 
> Let's call it rs6000-gen-builtins or similar.  Not as cryptic.

Or, config/gen-builtins.  :-)  We have one around here, and there are things 
that a generator can have that are really, generally useful.  It's better to 
share support for common thing and for very target specific things, of course, 
they can go down in the rs6000 area.  Our generators are written in python, and 
for this type of code, python is nice.  My workflow with my generators let's me 
validate changes to the generator easily, as I can compare a before and after 
of the generated content.

Once you push the common parts down and invite others to join the party, the 
next port can reuse the bits you have, and add the 1 or 5 things they need, and 
presto, you now have more beef, should you need it in the future.  Around here, 
we have more beef than anyone, as we always hit things no one else has.  In/out 
rtl parameters, out parameters, overloading, test case generation, early, late 
expansion, type fun, vector fun, architecture fun, optional parameters, gosh, 
the list just goes on and on...  Anyway, as a new port comes on line, it's 
easier for them to retrofit the 3 new things they need into a nice 
infrastructure that sings and dances.

Indeed, some of the older gcc port interfaces, for example, registers 
(FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS, REG_ALLOC_ORDER, 
HARD_REGNO_CALLER_SAVE_MODE, REG_CLASS_NAMES, REG_CLASS_CONTENTS, 
REGISTER_NAMES), I think would be a nice area for a generator as well.  Every 
port has registers, and yet, those interfaces are too clunky.  But, now I guess 
I digress.

Just wanted to say, I like your plan.

Re: [PATCH] document that alias and target must have the same type

[Martin Sebor]

On 2/13/20 3:55 PM, Sandra Loosemore wrote:

On 2/5/20 1:13 PM, Martin Sebor wrote:


diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ec99c38a607..3634ce1c423 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2557,8 +2557,11 @@ __attribute__ ((access (write_only, 1, 2), 
access (read_write, 3))) int fgets (c


 @item alias ("@var{target}")
 @cindex @code{alias} function attribute
-The @code{alias} attribute causes the declaration to be emitted as an
-alias for another symbol, which must be specified.  For instance,
+The @code{alias} attribute causes the declaration to be emitted as an 
alias
+for another symbol, which must have been previously declared with the 
same
+type, and for variables same size and alignment.  Declaring an alias 
with

+a different type than the target is undefined and may be diagnosed.  For
+instance, an alias for another symbol, which must be specified.  For 
instance,


 @smallexample
 void __f () @{ /* @r{Do something.} */; @}


This is kind of garbled.  Do you have an extraneous sentence beginning 
"For instance" in there?  It doesn't flow from the text you added before 
that.


That does look garbled.  I've fixed that in the revised patch.




@@ -3919,31 +3922,41 @@ results in warning on line 5.

 @item weak
 @cindex @code{weak} function attribute
-The @code{weak} attribute causes the declaration to be emitted as a weak
-symbol rather than a global.  This is primarily useful in defining
-library functions that can be overridden in user code, though it can
-also be used with non-function declarations.  Weak symbols are supported
-for ELF targets, and also for a.out targets when using the GNU assembler
-and linker.
+The @code{weak} attribute causes a declaration of an external symbol
+to be emitted as a weak symbol rather than a global.  This is primarily
+useful in defining library functions that can be overridden in user 
code,
+though it can also be used with non-function declarations.  The 
overriding

+symbol must have the same type, and for variables size, and alignment as
+the weak symbol.  Weak symbols are supported for ELF targets, and 
also for

+a.out targets when using the GNU assembler and linker.


The "for variables" clause is awkward and has a comma in the wrong 
place.  I'd split this into a separate sentence, like


The overriding symbol must have the same type as the weak symbol.  If it 
is a variable it must also have the same size and alignment.


Agreed, that looks better.




 @item weakref
 @itemx weakref ("@var{target}")
 @cindex @code{weakref} function attribute
 The @code{weakref} attribute marks a declaration as a weak reference.
 Without arguments, it should be accompanied by an @code{alias} attribute
-naming the target symbol.  Optionally, the @var{target} may be given as
-an argument to @code{weakref} itself.  In either case, @code{weakref}
-implicitly marks the declaration as @code{weak}.  Without a
-@var{target}, given as an argument to @code{weakref} or to @code{alias},
-@code{weakref} is equivalent to @code{weak}.
+naming the target symbol.  Alernatively, @var{target} may be given as


s/Alernatively/Alternatively/


+an argument to @code{weakref} itself, naming the target definition of
+the alias.  The the @var{target} must have the same type, and for


s/The the/The/

+variables also the same size and alignment as the declaration.  In 
either


Same comments above re splitting this into two sentences to avoid 
awkward wording.


I've spit it up into multiple sentences as you suggested.  Attached
is the updated revision that I plan to commit unless you (or anyone
else) have further suggestions.

Thanks for the review!

Martin



The rest of this patch looks OK.

-Sandra


gcc/ChangeLog:

	* doc/extend.texi (attribute alias): Mention type requirement
	(attribute weak): Same.
	(attribute weakref): Correct invalid example.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 5739063b330..b7f462a76b0 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2557,8 +2557,11 @@ __attribute__ ((access (write_only, 1, 2), access (read_write, 3))) int fgets (c
 
 @item alias ("@var{target}")
 @cindex @code{alias} function attribute
-The @code{alias} attribute causes the declaration to be emitted as an
-alias for another symbol, which must be specified.  For instance,
+The @code{alias} attribute causes the declaration to be emitted as an alias
+for another symbol, which must have been previously declared with the same
+type, and for variables, also the same size and alignment.  Declaring an alias
+with a different type than the target is undefined and may be diagnosed.  As
+an example, the following declarations:
 
 @smallexample
 void __f () @{ /* @r{Do something.} */; @}
@@ -2566,9 +2569,9 @@ void f () __attribute__ ((weak, alias ("__f")));
 @end smallexample
 
 @noindent
-defines @samp{f} to be a weak alias for @samp{__f}.  In C++, the
-mangled name for the target must be used.  It is an error if @samp{__f}

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

[Mike Stump]

On Feb 13, 2020, at 3:36 PM, Maciej W. Rozycki  wrote:
> 
> This is v2 of patch series, originally posted here:
> 
> 
> 
> 
> 
> 
> meant to address a problem with the testsuite compiler being set up across 
> libatomic, libffi, libgo, libgomp with no correlation whatsoever to the 
> target compiler being used in GCC compilation.

> In the end I have decided to use the documented `--tool_exec' option to 
> `runtest' to contain the change within the testsuite's Makefile and its 
> `check' goal, which is inherent to the build tree and as such not supposed 
> to be used in standalone testing, like with `contrib/test_installed'.


> I'm assuming Ian will take care of the 3/4 libgo change; OK to apply the 
> remaining ones to the GCC repo?

So, I really, really would like to avoid additional arguments like this.  I'd 
prefer that instead you push content into the built site.exp from the Makefile, 
or something else like this, and then use that content as you need to.  This 
preserves the ability to go where you need to in the tree, and do a runtest 
without specifying the option.

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

[Srinath Parvathaneni]

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?

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 check.
(thumb2_movdfcc_vfp): Modify pattern to enable double float conditional
code move patterns of VFP also in MVE by adding TARGET_VFP_BASE check.
(push_multi_vfp): Add support to use 

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

[Srinath Parvathaneni]

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?

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 b < c;
+}
+
+/* { dg-final { scan-assembler "bl\\t__aeabi_fcmplt" }  } */
+
+int
+foo5 (float b, float 

Re: [PATCH, rs6000]: mark clobber for registers changed by untpyed_call

[Segher Boessenkool]

On Fri, Feb 14, 2020 at 02:58:49PM +0800, Jiufu Guo wrote:
> Segher Boessenkool  writes:
> 
> > On Sat, Feb 08, 2020 at 10:17:42AM -0600, Segher Boessenkool wrote:
> >> And we do not know which of the register will be used for the return, in
> >> untyped_call (only untyped-return knows).  But we can add clobbers of all
> >> registers that *might* be used for the return, we do know that here, see
> >> operands[2] of untyped_call.
> >
> > Clobbers in parallel to the call, I mean, not as separate insns later.
> >
> Thanks Segher, as discussed, we may refine the patch by adding a
> 'barrier' to avoid instructions mis-scheduled.  This improvement patch
> maybe fine for practice.
> 
> Below is the updated patch: bootstrap and regtest pass on powerpc64le.
> Is this ok to submit to trunk?

This is okay for trunk, and for backports after a week or so.  Thanks!

(It doesn't fully solve the problem, as we discussed; because the return
registers are not seen (by df, etc.) as live immediately after the call,
new instructions using those registers can be created between the call
and the later clobber.  The barrier does nothing to prevent that.)

Don't forget to do a changelog entry, mentioning the PR as well :-)


Segher

Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.

[Mike Stump]

On Jan 24, 2020, at 9:45 AM, David Edelsohn  wrote:
> 
> On Fri, Jan 24, 2020 at 12:00 PM Jason Merrill  wrote:
>> 
>> On 1/24/20 8:45 AM, David Edelsohn wrote:
>>> There is no ChangeLog entry for the testsuite changes.
>> 
>> I don't believe in ChangeLog entries for testcases, but I'll add one for
>> the target-supports.exp change, thanks.
> 
> Is this a general policy change that we want to make?  Current we
> still have gcc/testsuite/ChangeLog and developers are updating that
> file.

I kinda like the current policy.  Use it if you want to, but, you can't count 
on others to use it.  I'd say this is a slight preference of mine.

Personally, I find git log , to be easier, faster, more accurate, 
can't go wrong.  With that, I'd usually only go to ChangeLog for commentary, 
though, since the changelog entry should be into the git log entry, git log is 
still sufficient to get at the commentary.  The only reason why git log works 
in this case, is because a single test case is in a single file with usually no 
or very little intermixing.  This isn't true of expression.c for example.  In 
the git log for expr.c, you'd have to wade through a ton of chaff, which makes 
it much harder to use in some situations.

For the testsuite/lib/* files, I actually prefer ChangeLog entries (to match 
the policy of gcc/*.c).  This isn't policy, but, I'd encourage others in this 
direction.  I suppose I like ChangeLogs for all the *.exp files as well, as 
usually these are for a large multitude of test cases.

That's just my $0.02.  If others want to chime in, on what the like and why...

[committed] c++: Fix thinko in enum_min_precision [PR61414]

[Jakub Jelinek]

Hi!

When backporting the PR61414 fix to 8.4, I've noticed that the caching
of prec is actually broken, as it would fail to actually store the computed
precision into the hash_map's value and so next time we'd think the enum needs
0 bits.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and
committed to trunk, 9.3 and 8.4.

2020-02-14  Jakub Jelinek  

PR c++/61414
* class.c (enum_min_precision): Change prec type from int to int &.

* g++.dg/cpp0x/enum39.C: New test.

--- gcc/cp/class.c.jj   2020-02-12 11:44:18.423371637 +0100
+++ gcc/cp/class.c  2020-02-14 14:33:41.842057349 +0100
@@ -3289,7 +3289,7 @@ enum_min_precision (tree type)
 enum_to_min_precision = hash_map::create_ggc (37);
 
   bool existed;
-  int prec = enum_to_min_precision->get_or_insert (type, );
+  int  = enum_to_min_precision->get_or_insert (type, );
   if (existed)
 return prec;
 
--- gcc/testsuite/g++.dg/cpp0x/enum39.C.jj  2020-02-14 14:30:26.489972394 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/enum39.C 2020-02-14 14:30:22.530031482 +0100
@@ -0,0 +1,15 @@
+// PR c++/61414
+// { dg-do compile { target c++11 } }
+
+enum class E { E0 = -4, E1 = 3 };
+enum F : unsigned { F0 = 0, F1 = 15 };
+
+struct S
+{
+  E a : 2; // { dg-warning "'S::a' is too small to hold all values of 
'enum class E'" }
+  E b : 2; // { dg-warning "'S::b' is too small to hold all values of 
'enum class E'" }
+  E c : 3; // { dg-bogus "'S::c' is too small to hold all values of 'enum 
class E'" }
+  F d : 3; // { dg-warning "'S::d' is too small to hold all values of 
'enum F'" }
+  F e : 3; // { dg-warning "'S::e' is too small to hold all values of 
'enum F'" }
+  F f : 4; // { dg-bogus "'S::f' is too small to hold all values of 'enum 
F'" }
+};

Jakub

Re: [PATCH] testsuite/strlenopt-81.c: Add target limitation.

[Martin Sebor]

On 2/13/20 8:34 PM, Kito Cheng wrote:

  - strlenopt-81.c has same limitation as strlenopt-80.c, this
optimization only work when memcpy expand into load/store.


Unlike strlenopt-80.c which is a compile-time test that verifies
that the optimization successfully folds the strlen expressions,
strlenopt-81.c is a runtime test that verifies the optimization
isn't done when it might not be safe.   It shouldn't fail anywhere,
whether or not the optimization is actually done.  Are you seeing
it fail on some targets?  (That would suggest a bug.)

The test does look like it has a minor issue though: it uses
-fdump-tree-optimized but it doesn't actually scan the output for
anything.  I think it was copied from another test and not removed
by accident.  It should be removed.  (The comment at the top is
also missing the bug number that it was committed for; it should
be added.)  I can take care of this if you can confirm the above
(i.e., that there's no runtime failure on any of the targets
excluded in your patch).

Martin



ChangeLog

gcc/testsuite

Kito Cheng  

* gcc.dg/strlenopt-81.c: Add target limitation.
---
  gcc/testsuite/gcc.dg/strlenopt-81.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/strlenopt-81.c 
b/gcc/testsuite/gcc.dg/strlenopt-81.c
index 95ac29aa71f..4a0dfc4f17d 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-81.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-81.c
@@ -1,5 +1,9 @@
  /* PR tree-optimization/ - fold strlen relational expressions
-   { dg-do run }
+   { dg-do run { target aarch64*-*-* i?86-*-* powerpc*-*-* x86_64-*-* } }
+   The optimization is only implemented for MEM_REF stores and other
+   targets than those below may not transform the memcpy call into
+   such a store.
+
 { dg-options "-O2 -Wall -Wno-unused-local-typedefs -fdump-tree-optimized" 
} */
  
  typedef __SIZE_TYPE__ size_t;

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

[Srinath Parvathaneni]

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.

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

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): Calculate space for saved VFP registers for
MVE.
(arm_save_coproc_regs): Save coproc registers for MVE.
(arm_print_operand): Add case 'E' to print memory operands for MVE.
(arm_print_operand_address): Check to print register number for MVE.
(arm_hard_regno_mode_ok): Check for arm hard regno mode ok for MVE.
(arm_modes_tieable_p): Check to allow structure mode for MVE.

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

[Maciej W. Rozycki]

Mike, Chung-Lin --

> > In the end I have decided to use the documented `--tool_exec' option to 
> > `runtest' to contain the change within the testsuite's Makefile and its 
> > `check' goal, which is inherent to the build tree and as such not supposed 
> > to be used in standalone testing, like with `contrib/test_installed'.
> 
> 
> > I'm assuming Ian will take care of the 3/4 libgo change; OK to apply the 
> > remaining ones to the GCC repo?
> 
> So, I really, really would like to avoid additional arguments like this.  
> I'd prefer that instead you push content into the built site.exp from 
> the Makefile, or something else like this, and then use that content as 
> you need to.  This preserves the ability to go where you need to in the 
> tree, and do a runtest without specifying the option.

 Thank you, Mike, for your input.  That is what v1 did, but it seems to 
clash with some people's expectations, as discussed here:



So it looks like we have conflicting expectations for the desired 
arrangement, and of course the current situation isn't right either.

 Or, Chung-Lin, will you be happy if we just stay away from 
libgomp/testsuite/libgomp-test-support.exp and use say 
libgomp/testsuite/libgomp-test-support-extra.exp to supply the compiler 
setting (EXTRA_DEJAGNU_SITE_CONFIG supports an arbitrary number of 
site.exp fragments)?

 Any other proposals?

  Maciej

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

[Martin Sebor]

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:

  struct A
  {
A () = delete;
A (int) = delete;
  };

  A a1[1] = { 0 };  // { dg-error "use of deleted function 
'A::A\\\(int\\\)'" }


because GCC ends up printing:

  error: use of deleted function 'A::A()'

This is because A is considered trivial and TYPE_NEEDS_CONSTRUCTING
is false.  IIUC what Marek pointed to (CWG1496), A should not be
considered trivial but GCC doesn't implement that change in
the standard, hence the failure.


  else if (TREE_CODE (init) != CONSTRUCTOR)
    return false;

and then remove the


  if (TYPE_NON_AGGREGATE_CLASS (type))
    return false;


later in the function.

More generally, this function could recognize when the initializer is 
equivalent to {}-initialization and return true in that case, but that 
sounds probably too tricky for stage 4.


My preference is to leave the fix as it is (i.e., leave the test
for RECORD_OR_UNION_TYPE_P in place), just with
the TYPE_NEEDS_CONSTRUCTING test removed, and defer improvements
until PR 85723 is fixed.  Let me know how you want me to proceed.

Martin

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[Jakub Jelinek]

On Fri, Feb 14, 2020 at 10:02:39PM +, GT wrote:
> > > Function rs6000_simd_clone_adjust, even though it's body is empty,
> > > cannot simply be removed. I tried it. It resulted in ICE. In my
> > > view, leaving it empty is preferable to modifying other files
> > > unrelated to rs6000.c in order to avoid having a function whose
> > > body is empty.
> >
> > So shouldn't the callback set target attribute (on definitions) to "vsx"?
> >
> 
> I did consider doing something similar to aarch64_simd_clone_adjust. But the 
> reason
> Aarch64 has a new attribute aarch64_vector_pcs is that they implemented a 
> modified
> function calling sequence for vector functions. PPC64 vector functions use 
> the existing
> function calling sequence spelled out in the 64-bit ELFv2 ABI. So with no new 
> attribute
> here, the function body ends up empty.
> 
> Have I missed something crucial?

I haven't seen anything in the patch that would only enable it for ELFv2,
and while powerpc64le-linux probably assumes TARGET_VSX unconditionally
(haven't verified), powerpc64-linux or powerpc-linux certainly doesn't.
And it is just fine to have the ABI for those pass/return vectors in VSX
registers too, after all, it won't be used if the vectorized caller isn't
TARGET_VSX, the definitions of the declare simd functions could be compiled
with different ISA options.  And, if the ABI sais that the 'b' stuff assumes
certain ISA extensions, if the declare simd function definition is compiled
with e.g. -mno-vsx -mno-altivec, it would either not be able to get the
arguments/return values at all, or wouldn't benefit from the ISA guarantees
the ABI gives to it.

BTW, in the ABI document there isn't just 'b', but also 'c' ABI, it is
unclear if one needs to always emit both (e.g. like on x86 we emit 'b', 'c',
'd' and 'e') and then let the vectorized callers choose based on what ISA
options it is compiled with.

Jakub

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

[Mike Stump]

On Feb 14, 2020, at 11:57 AM, Maciej W. Rozycki  wrote:
> 
> Mike, Chung-Lin --
> 
>>> In the end I have decided to use the documented `--tool_exec' option to 
>>> `runtest' to contain the change within the testsuite's Makefile and its 
>>> `check' goal, which is inherent to the build tree and as such not supposed 
>>> to be used in standalone testing, like with `contrib/test_installed'.
>> 
>> 
>>> I'm assuming Ian will take care of the 3/4 libgo change; OK to apply the 
>>> remaining ones to the GCC repo?
>> 
>> So, I really, really would like to avoid additional arguments like this.  
>> I'd prefer that instead you push content into the built site.exp from 
>> the Makefile, or something else like this, and then use that content as 
>> you need to.  This preserves the ability to go where you need to in the 
>> tree, and do a runtest without specifying the option.
> 
> 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.

So, let step back.  You want to change the options to the compiler, right?

So, imagine for a second that site.exp has those options, then you can reliably 
grab them from that file and use them, no?  If so, then all you have to do is 
put the content you need into site.exp, and then once it is there, you can then 
merely add a little code to grab them and add them, right?

So, pick testsuite that fails, and that you broke.  Back out the last patch, 
and instead, in the Makefile (or whatever generate the Makefile, look for the 
site.exp rule, and instead pilfer the data you want create it up into an 
existing variable, if relevant to it, and if not, create a new one.

For some of these files we see they come from automake, so we google, then we 
find:

http://gnu-automake.7480.n7.nabble.com/Automake-and-dejagnu-s-site-exp-file-td4414.html

and presto, a 5 line solution to an existing problem.

Is that kinda sort similar to what you want to do?  Now that's a 12 year old 
answer the the problem, I didn't check to see if there is a newer answer.  It 
looks reasonable enough.

[PATCH] drop weakref attribute on function definitions (PR 92799)

[Martin Sebor]

Because attribute weakref introduces a kind of a definition, it can
only be applied to declarations of symbols that are not defined.  GCC
normally issues a warning when the attribute is applied to a defined
symbol, but PR 92799 shows that it misses some cases on which it then
leads to an ICE.

The ICE was introduced in GCC 4.5.  Prior to then, GCC accepted such
invalid definitions and silently dropped the weakref attribute.

The attached patch avoids the ICE while again dropping the invalid
attribute from the definition, except with the (now) usual warning.

Tested on x86_64-linux.

I also looked for code bases that make use of attribute weakref to
rebuild them as another test but couldn't find any.  (There are
a couple of instances in the Linux kernel but they look #ifdef'd
out).  Does anyone know of any that do use it that I could try to
build on Linux?

Martin
PR ipa/92799 - ICE on a weakref function definition followed by a declaration

gcc/testsuite/ChangeLog:

	PR ipa/92799
	* gcc.dg/attr-weakref-5.c: New test.

gcc/ChangeLog:

	PR ipa/92799
	* cgraphunit.c (process_function_and_variable_attributes): Also
	complain about weakref function definitions and drop all effects
	of the attribute.

diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index a9dd288be57..fd586366bb9 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -861,14 +861,23 @@ process_function_and_variable_attributes (cgraph_node *first,
 			" attribute have effect only on public objects");
 	}
   if (lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))
-	  && (node->definition && !node->alias))
+	  && node->definition
+	  && (!node->alias || DECL_INITIAL (decl) != error_mark_node))
 	{
-	  warning_at (DECL_SOURCE_LOCATION (node->decl), OPT_Wattributes,
+	  /* NODE->DEFINITION && NODE->ALIAS is nonzero for valid weakref
+	 function declarations; DECL_INITIAL is non-null for invalid
+	 weakref functions that are also defined.  */
+	  warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wattributes,
 		  "% attribute ignored"
 		  " because function is defined");
 	  DECL_WEAK (decl) = 0;
 	  DECL_ATTRIBUTES (decl) = remove_attribute ("weakref",
 		 DECL_ATTRIBUTES (decl));
+	  DECL_ATTRIBUTES (decl) = remove_attribute ("alias",
+		 DECL_ATTRIBUTES (decl));
+	  node->alias = false;
+	  node->weakref = false;
+	  node->transparent_alias = false;
 	}
   else if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl))
 	  && node->definition
diff --git a/gcc/testsuite/gcc.dg/attr-weakref-5.c b/gcc/testsuite/gcc.dg/attr-weakref-5.c
new file mode 100644
index 000..e2f04068230
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/attr-weakref-5.c
@@ -0,0 +1,31 @@
+/* PR middle-end/92799 - ICE on a weakref function definition followed
+   by a declaration
+   { dg-do compile }
+   { dg-options "-Wall" } */
+
+static __attribute__ ((weakref ("bar"))) void f0 (void) { }   // { dg-warning "'weakref' attribute ignored because function is defined" }
+
+extern void f0 (void);
+
+void* use_f0 (void) { return f0; }
+
+
+static __attribute__ ((weakref ("bar"))) void f1 (void) { }   // { dg-warning "'weakref' attribute ignored because function is defined" }
+
+static void f1 (void);
+
+void* use_f1 (void) { return f1; }
+
+
+static __attribute__ ((weakref ("bar"))) void f2 (void);
+
+static void f2 (void) { } // { dg-error "redefinition" }
+
+void* use_f2 (void) { return f2; }
+
+
+static __attribute__ ((weakref ("bar"))) void f3 (void);
+
+void f3 (void) { }// { dg-error "redefinition" }
+
+void* use_f3 (void) { return f3; }

[RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[GT]

Function rs6000_simd_clone_adjust, even though it's body is empty,
cannot simply be removed. I tried it. It resulted in ICE. In my
view, leaving it empty is preferable to modifying other files
unrelated to rs6000.c in order to avoid having a function whose
body is empty.

Bert.


0001-PPC64-Implement-POWER-Architecure-Vector-Function-AB.patch
Description: Binary data

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

[Joseph Myers]

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".

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[Jakub Jelinek]

On Fri, Feb 14, 2020 at 08:24:30PM +, GT wrote:
> Function rs6000_simd_clone_adjust, even though it's body is empty,
> cannot simply be removed. I tried it. It resulted in ICE. In my
> view, leaving it empty is preferable to modifying other files
> unrelated to rs6000.c in order to avoid having a function whose
> body is empty.

So shouldn't the callback set target attribute (on definitions) to "vsx"?

Jakub

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

[David Malcolm]

On Mon, 2020-02-03 at 22:29 +, Bernd Edlinger wrote:
> On 2/3/20 10:05 PM, Segher Boessenkool wrote:
> > On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote:
> > > So gnome terminal is a problem, since it depend heavily on the
> > > software
> > > version, VTE library, and gnome-terminal.
> > > Sometimes URLs are functional, sometimes competely buggy.
> > > 
> > > But, wait a moment, here is the deal:
> > > 
> > > I can detect old gnome terminals,
> > > they have COLORTERM=gnome-terminal (and produce garbage)
> > > 
> > > but new gnome terminal with true URL-support have
> > > 
> > > COLORTERM=truecolor
> > > 
> > > So how about adding that to the detection logic ?
> > 
> > It works on at least one of my older setups, too (will have to
> > check
> > the rest when I have time, unfortunately the weekend is just past).
> > 
> 
> Cool.
> 
> so here is the next version, which removes tmux, and adds
> detection of old gnome-terminal, and linux console sessions,
> while also attempting to work with ssh sessions, where we
> do we have a bit less reliable information, but I would
> think that is still an improvement.  I'd let TERM_URLS and
> GCC_URLS override the last two exceptions, as TERM=xterm
> can also mean, really xterm, but while that one does not
> print garbage, it does not handle the URLs either.
> 
> 
> How do you like it this way?
> 
> Is it OK for trunk?

Thanks for the updated patch.  I have various nitpicks inline below,
but I think that this has had enough iterations and ought to go into
master if you address the nitpicks (consider the fixes preapproved).

I manually tested the patch on my gnome-terminal and it continued to
give me working hyperlinks, and successfully disabled them within
screen.


> 2020-01-30  David Malcolm  
>   Bernd Edlinger  
> 
>   PR 87488
>   PR other/93168
>   * config.in (DIAGNOSTICS_URLS_DEFAULT): New define.
>   * configure.ac (--with-diagnostics-urls): New configuration
>   option, based on --with-diagnostics-color.
>   (DIAGNOSTICS_URLS_DEFAULT): New define.
>   * config.h: Regenerate.
>   * configure: Regenerate.
>   * diagnostic.c (diagnostic_urls_init): Handle -1 for
>   DIAGNOSTICS_URLS_DEFAULT from configure-time
>   --with-diagnostics-urls=auto-if-env by querying for a GCC_URLS
>   and TERM_URLS environment variable.
>   * diagnostic-url.h (diagnostic_url_format): New enum type.
>   (diagnostic_urls_enabled_p): rename to...
>   (parse_env_vars_for_urls): ... this, and change return type.
>   * diagnostic-color.c (parse_gcc_urls): New helper function.
>   (auto_enable_urls): Disable URLs on xfce4-terminal, gnome-terminal,
>   the linux console, and mingw.
>   (parse_env_vars_for_urls): Adjust.
>   * pretty-print.h (pretty_printer::show_urls): rename to...
>   (pretty_printer::url_format): ... this, and change to enum.
>   * pretty-print.c (pretty_printer::pretty_printer,
>   pp_begin_url, pp_end_url, test_urls): Adjust.
>   * doc/install.texi (--with-diagnostics-urls): Document the new
>   configuration option.

The install.texi part of the patch also touches --with-diagnostics-
color, documenting the existing interaction with GCC_COLORS.

>   * doc/invoke.texi (-fdiagnostics-urls): Add GCC_URLS and TERM_URLS
>   vindex reference.  Update description of defaults based on the above.

Likewise the invoke.texi part of the patch also updates the description
of how -fdiagnostics-color interacts with GCC_COLORS.


> ---
>  gcc/config.in  |   6 +++
>  gcc/configure  |  41 +++-
>  gcc/configure.ac   |  28 ++
>  gcc/diagnostic-color.c | 102 
> ++---
>  gcc/diagnostic-url.h   |  18 -
>  gcc/diagnostic.c   |  21 --
>  gcc/doc/install.texi   |  15 ++--
>  gcc/doc/invoke.texi|  39 +--
>  gcc/pretty-print.c |  44 ++---
>  gcc/pretty-print.h |   5 ++-
>  10 files changed, 293 insertions(+), 26 deletions(-)

[...]

> @@ -239,20 +240,109 @@ colorize_init (diagnostic_color_rule_t rule)
>  }
>  }
>  
> -/* Determine if URLs should be enabled, based on RULE.
> +/* Return URL_FORMAT_XXX which tells how we should emit urls
> +   when in always mode.
> +   We use GCC_URLS and if that is not defined TERM_URLS.
> +   If neither is defined the feature is enabled by default.  */
> +
> +static diagnostic_url_format
> +parse_env_vars_for_urls ()
> +{
> +  const char *p;
> +
> +  p = getenv ("GCC_URLS"); /* Plural! */
> +  if (p == NULL)
> +p = getenv ("TERM_URLS");
> +
> +  if (p == NULL)
> +return URL_FORMAT_DEFAULT;
> +
> +  if (*p == '\0')
> +return URL_FORMAT_NONE;
> +
> +  if (!strcmp (p, "no"))
> +return URL_FORMAT_NONE;
> +
> +  if (!strcmp (p, "st"))
> +return URL_FORMAT_ST;
> +
> +  if (!strcmp (p, "bel"))
> +return URL_FORMAT_BEL;
> +
> +  return URL_FORMAT_DEFAULT;

Re: [PATCH 00/14] rs6000: Begin replacing built-in support

[Segher Boessenkool]

Hi!

On Fri, Feb 14, 2020 at 10:34:40AM -0800, Mike Stump wrote:
> On Feb 4, 2020, at 9:40 AM, Segher Boessenkool  
> wrote:
> >> My intent is to make adding new built-in functions as simple as adding
> >> a few lines to a couple of files, and automatically generating as much
> >> of the initialization, overload resolution, and expansion logic as
> >> possible.  This patch series establishes the format of the input files
> >> and creates a new program (rs6000-genbif) to:
> > 
> > Let's call it rs6000-gen-builtins or similar.  Not as cryptic.
> 
> Or, config/gen-builtins.  :-)

As explained before, to get somewhere in a reasonable time, we first need
to do it for rs6000 only.  This patchset is solving an acute problem for
us, too, that is the *purpose* of it.

It remains to be seen how much of it can be used by other targets.
Pretending something is generic while it in fact is just a mass of
special cases isn't useful, it's just costly.

> Indeed, some of the older gcc port interfaces, for example, registers 
> (FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS, REG_ALLOC_ORDER, 
> HARD_REGNO_CALLER_SAVE_MODE, REG_CLASS_NAMES, REG_CLASS_CONTENTS, 
> REGISTER_NAMES), I think would be a nice area for a generator as well.  Every 
> port has registers, and yet, those interfaces are too clunky.

Yes...  Like, last year I renumbered the rs6000 registers.  Things have
to be changed in a bunch of tables, but also in a few other places that
you cannot generate the code for.  So on one hand a generator for this
certainly would have helped, but on the other hand, it isn't the holy
grail you might be after either.

> Just wanted to say, I like your plan.

:-)  It'll be a lot of work still, let's hope we can make it for GCC 11.


Segher

[c-family] Fix duplicates for anonymous structures with -fdump-ada-spec

[Eric Botcazou]

This fixes a weakness in the way -fdump-ada-spec builds names for anonymous 
structures in C/C++ code, resulting in duplicate identifiers under specific 
circumstances.  Probably worth fixing in GCC 10 instead of waiting longer.

Bootstrapped/regtested on x86_64-suse-linux, applied on the mainline.


2020-02-14  Eric Botcazou  

* c-ada-spec.c: Include bitmap.h.
(dump_ada_double_name): Rename into...
(dump_anonymous_type_name): ...this.  Always use the TYPE_UID.
(dump_ada_array_type): Adjust to above renaming.  Robustify.
(dump_nested_types_1): New function copied from...  Add dumped_types
parameter and pass it down to dump_nested_type.
(dump_nested_types): ...this.  Remove parent parameter.  Just call
dump_nested_types_1 on an automatic bitmap.
(dump_nested_type): Add dumped_types parameter.
: Do not dump it if already present in dumped_types.
Adjust recursive calls and adjust to above renaming.
(dump_ada_declaration): Adjust call to dump_nested_types.
Tidy up and adjust to above renaming.
(dump_ada_specs): Initialize and release bitmap obstack.

-- 
Eric Botcazoudiff --git a/gcc/c-family/c-ada-spec.c b/gcc/c-family/c-ada-spec.c
index e0c18c883da..6d9192f2a26 100644
--- a/gcc/c-family/c-ada-spec.c
+++ b/gcc/c-family/c-ada-spec.c
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "diagnostic.h"
 #include "stringpool.h"
 #include "attribs.h"
+#include "bitmap.h"
 
 /* Local functions, macros and variables.  */
 static int  dump_ada_node (pretty_printer *, tree, tree, int, bool, bool);
@@ -1475,30 +1476,21 @@ dump_ada_decl_name (pretty_printer *buffer, tree decl, bool limited_access)
 }
 }
 
-/* Dump in BUFFER a name based on both T1 and T2 followed by a suffix.  */
+/* Dump in BUFFER a name for the type T, which is a _TYPE without TYPE_NAME.
+   PARENT is the parent node of T.  */
 
 static void
-dump_ada_double_name (pretty_printer *buffer, tree t1, tree t2)
+dump_anonymous_type_name (pretty_printer *buffer, tree t, tree parent)
 {
-  if (DECL_NAME (t1))
-pp_ada_tree_identifier (buffer, DECL_NAME (t1), t1, false);
+  if (DECL_NAME (parent))
+pp_ada_tree_identifier (buffer, DECL_NAME (parent), parent, false);
   else
 {
   pp_string (buffer, "anon");
-  pp_scalar (buffer, "%d", TYPE_UID (TREE_TYPE (t1)));
+  pp_scalar (buffer, "%d", TYPE_UID (TREE_TYPE (parent)));
 }
 
-  pp_underscore (buffer);
-
-  if (DECL_NAME (t2))
-pp_ada_tree_identifier (buffer, DECL_NAME (t2), t2, false);
-  else
-{
-  pp_string (buffer, "anon");
-  pp_scalar (buffer, "%d", TYPE_UID (TREE_TYPE (t2)));
-}
-
-  switch (TREE_CODE (TREE_TYPE (t2)))
+  switch (TREE_CODE (t))
 {
 case ARRAY_TYPE:
   pp_string (buffer, "_array");
@@ -1516,6 +1508,8 @@ dump_ada_double_name (pretty_printer *buffer, tree t1, tree t2)
   pp_string (buffer, "_unknown");
   break;
 }
+
+  pp_scalar (buffer, "%d", TYPE_UID (t));
 }
 
 /* Dump in BUFFER aspect Import on a given node T.  SPC is the current
@@ -1816,10 +1810,9 @@ dump_ada_array_type (pretty_printer *buffer, tree node, tree type, int spc)
   /* Print the dimensions.  */
   dump_ada_array_domains (buffer, node, spc);
 
-  /* Print array's type.  */
+  /* Print the component type.  */
   if (!char_array)
 {
-  /* Retrieve the element type.  */
   tree tmp = node;
   while (TREE_CODE (tmp) == ARRAY_TYPE)
 	tmp = TREE_TYPE (tmp);
@@ -1829,10 +1822,12 @@ dump_ada_array_type (pretty_printer *buffer, tree node, tree type, int spc)
   if (TREE_CODE (tmp) != POINTER_TYPE)
 	pp_string (buffer, "aliased ");
 
-  if (TYPE_NAME (tmp) || !RECORD_OR_UNION_TYPE_P (tmp))
+  if (TYPE_NAME (tmp)
+	  || (!RECORD_OR_UNION_TYPE_P (tmp)
+	  && TREE_CODE (tmp) != ENUMERAL_TYPE))
 	dump_ada_node (buffer, tmp, node, spc, false, true);
-  else
-	dump_ada_double_name (buffer, type, get_underlying_decl (tmp));
+  else if (type)
+	dump_anonymous_type_name (buffer, tmp, type);
 }
 }
 
@@ -2469,10 +2464,11 @@ dump_forward_type (pretty_printer *buffer, tree type, tree t, int spc)
   TREE_VISITED (decl) = 1;
 }
 
-static void dump_nested_type (pretty_printer *, tree, tree, tree, int);
+static void dump_nested_type (pretty_printer *, tree, tree, tree, bitmap, int);
 
-/* Dump in BUFFER anonymous types nested inside T's definition.
-   PARENT is the parent node of T.  SPC is the indentation level.
+/* Dump in BUFFER anonymous types nested inside T's definition.  PARENT is the
+   parent node of T.  DUMPED_TYPES is the bitmap of already dumped types.  SPC
+   is the indentation level.
 
In C anonymous nested tagged types have no name whereas in C++ they have
one.  In C their TYPE_DECL is at top level whereas in C++ it is nested.
@@ -2484,13 +2480,14 @@ static void dump_nested_type (pretty_printer *, tree, tree, tree, int);
pass on the nested TYPE_DECLs and a second 

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[GT]

‐‐‐ Original Message ‐‐‐
On Friday, February 14, 2020 3:38 PM, Jakub Jelinek  wrote:

> On Fri, Feb 14, 2020 at 08:24:30PM +, GT wrote:
>
> > Function rs6000_simd_clone_adjust, even though it's body is empty,
> > cannot simply be removed. I tried it. It resulted in ICE. In my
> > view, leaving it empty is preferable to modifying other files
> > unrelated to rs6000.c in order to avoid having a function whose
> > body is empty.
>
> So shouldn't the callback set target attribute (on definitions) to "vsx"?
>

I did consider doing something similar to aarch64_simd_clone_adjust. But the 
reason
Aarch64 has a new attribute aarch64_vector_pcs is that they implemented a 
modified
function calling sequence for vector functions. PPC64 vector functions use the 
existing
function calling sequence spelled out in the 64-bit ELFv2 ABI. So with no new 
attribute
here, the function body ends up empty.

Have I missed something crucial?

Bert.

Re: [PATCH 1/3] libstdc++: Fold some ranges algo subroutines into their only caller

[Jonathan Wakely]

On 14/02/20 10:35 -0500, Patrick Palka wrote:

These subroutines have only a single call site, so it might be best and simplest
to eliminate them before we convert the algos into function objects.

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (ranges::__find_end): Fold into ...
(ranges::find_end): ... here.
(ranges::__lexicographical_compare): Fold into ...
(ranges::lexicographical_compare): ... here.
* include/bits/ranges_algobase.h (ranges::__equal): Fold into ...
(ranges::equal): ... here.


OK for master, but please note the two comments below.



libstdc++-v3/include/bits/ranges_algo.h | 104 
libstdc++-v3/include/bits/ranges_algobase.h |  33 +++
2 files changed, 55 insertions(+), 82 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index 84a02cabb80..6b6f4defdf5 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -513,40 +513,7 @@ namespace ranges
  std::move(__pred), std::move(__proj));
}

-  template _Sent1,
-  forward_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
-  typename _Pred = ranges::equal_to,
-  typename _Proj1 = identity, typename _Proj2 = identity>
-requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
-constexpr subrange<_Iter1>
-__find_end(_Iter1 __first1, _Sent1 __last1,
-  _Iter2 __first2, _Sent2 __last2,
-  _Pred __pred, _Proj1 __proj1, _Proj2 __proj2)
-{
-  auto __i = ranges::next(__first1, __last1);
-  if (__first2 == __last2)
-   return {__i, __i};

-  auto __result_begin = __i;
-  auto __result_end = __i;
-  for (;;)
-   {
- auto __new_range = ranges::search(__first1, __last1,
-   __first2, __last2,
-   __pred, __proj1, __proj2);
- auto __new_result_begin = ranges::begin(__new_range);
- auto __new_result_end = ranges::end(__new_range);
- if (__new_result_begin == __last1)
-   return {__result_begin, __result_end};
- else
-   {
- __result_begin = __new_result_begin;
- __result_end = __new_result_end;
- __first1 = __result_begin;
- ++__first1;
-   }
-   }
-}

  template _Sent1,
   forward_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
@@ -578,9 +545,31 @@ namespace ranges
return {__result_first, __result_last};
}
  else
-   return ranges::__find_end(__first1, __last1, __first2, __last2,
- std::move(__pred),
- std::move(__proj1), std::move(__proj2));
+   {
+ auto __i = ranges::next(__first1, __last1);
+ if (__first2 == __last2)
+   return {__i, __i};
+
+ auto __result_begin = __i;
+ auto __result_end = __i;
+ for (;;)
+   {
+ auto __new_range = ranges::search(__first1, __last1,
+   __first2, __last2,
+   __pred, __proj1, __proj2);
+ auto __new_result_begin = ranges::begin(__new_range);
+ auto __new_result_end = ranges::end(__new_range);
+ if (__new_result_begin == __last1)
+   return {__result_begin, __result_end};
+ else
+   {
+ __result_begin = __new_result_begin;
+ __result_end = __new_result_end;
+ __first1 = __result_begin;
+ ++__first1;
+   }
+   }
+   }
}

  template _Sent1,
   input_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
-  typename _Proj1, typename _Proj2,
+  typename _Proj1 = identity, typename _Proj2 = identity,
   indirect_strict_weak_order,
- projected<_Iter2, _Proj2>> _Comp>
+ projected<_Iter2, _Proj2>>
+_Comp = ranges::less>
constexpr bool
-__lexicographical_compare(_Iter1 __first1, _Sent1 __last1,
- _Iter2 __first2, _Sent2 __last2,
- _Comp __comp, _Proj1 __proj1, _Proj2 __proj2)
+lexicographical_compare(_Iter1 __first1, _Sent1 __last1,
+   _Iter2 __first2, _Sent2 __last2,
+   _Comp __comp = {},
+   _Proj1 __proj1 = {}, _Proj2 __proj2 = {})
{
+  if constexpr (__detail::__is_normal_iterator<_Iter1>
+   || __detail::__is_normal_iterator<_Iter2>)
+   return ranges::lexicographical_compare
+(std::__niter_base(std::move(__first1)),
+ std::__niter_base(std::move(__last1)),
+ 

Re: [PATCH] document that alias and target must have the same type

[Sandra Loosemore]

On 2/14/20 11:30 AM, Martin Sebor wrote:


[snip]
Attached
is the updated revision that I plan to commit unless you (or anyone
else) have further suggestions.


This version is OK to commit.

-Sandra

Re: [PATCH 00/14] rs6000: Begin replacing built-in support

[Mike Stump]

On Feb 14, 2020, at 1:26 PM, Segher Boessenkool  
wrote:
> It remains to be seen how much of it can be used by other targets.
> Pretending something is generic while it in fact is just a mass of
> special cases isn't useful, it's just costly.

Oh, yeah, of course.  Ours was designed in two pieces, the target bits, which 
were 100% target specific, and then the infrastructure to make those target 
bits go.  5,661 lines in the generator, and around 11 lines per builtin on the 
target side.  The generator was 100% free of target things.


(define_code_attr cond_name
[(unordered "Unordered")
 (ordered "Ordered")
 (unlt "Less Than or Unordered")
 (unge "Greater Than or Equal or Unordered")
 (uneq "Equal or Unordered")
 (ltgt "Not Equal or Unordered")
 (unle "Less Than or Equal or Unorderd")
 (ungt "Greater Than or Unordered")
 (eq "Equal")
 (ne "Not Equal")
 (gt "Greater Than")
 (ge "Greater Equal")
 (lt "Less Than")
 (le "Less Equal")
 (gtu "Greater Than Unsigned")
 (geu "Greater Than Unsigned")
 (ltu "Less Than Unsigned")
 (leu "Less Than Unsigned")])



(define_builtin "arch_cmp" "arch_cmp_"
  [
(define_desc"Compare ")
(define_outputs [(var_operand: 0)])
(define_inputs  [(var_operand:T_ALL_INT 1)
 (var_operand:T_ALL_INT 2)])
(code_iterator icond)
(define_rtl_pattern "arch_cmp_" [0 1 2])
(attributes [pure])
(use_note "")
  ]
)

was the typical sort of thing for the target side.  We've since moved on and 
now generate even more from way less.  3 lines of input for an instruction, and 
even the 3 lines are auto extracted from the documentation for the instruction. 
 So, roughly zero lines of input per builtin.  About 5600 lines in the 
generator code, but that generator, oh my, it does a ton more.  The new one 
doesn't have the nice clean split between target and non-target code, however.  
The later does significantly more work however, so, I don't feel bad.

The one thing missing I think more from modern compiler port development is the 
sharing of the commonalities between ports that would make the port writing 
even easier.

[PATCH] debug/93751 Generate DIEs for external variables with -g1

[Alexey Neyman]

Hi all,

As reported here, https://gcc.gnu.org/ml/gcc-help/2020-02/msg00062.html, 
GCC does not behave according to manual when `-gdwarf -g1` options are 
used; it does not generate the debugging information for external 
variables even though it is supposed to (and it does so for other 
debugging formats):


aneyman@supox:/tmp$ cat foo.c
int foo __attribute__((externally_visible));
aneyman@supox:/tmp$ gcc -c -O2 -gdwarf -g1 foo.c
aneyman@supox:/tmp$ readelf -wi foo.o
aneyman@supox:/tmp$ gcc -c -O2 -gdwarf -g2 foo.c
aneyman@supox:/tmp$ readelf -wi foo.o
...
<1><1d>: Abbrev Number: 2 (DW_TAG_variable)
    <1e>   DW_AT_name    : foo


The attached patch fixes this issue.

Regards,
Alexey.

>From a4cdccf633c83746481daac5da088b07843c6c38 Mon Sep 17 00:00:00 2001
From: Alexey Neyman 
Date: Thu, 13 Feb 2020 22:01:10 -0800
Subject: [PATCH] debug/93751 Create DIEs for external vars with -g1

-g1 is described in the manual to generate debug info for functions and
external variables. It does that for older debugging formats but not for
DWARF. This change aligns the behavior of `-gdwarf -g1` with the
description in the manual.

2020-02-14  Alexey Neyman  

PR debug/93751
* dwarf2out.c (gen_decl_die): Proceed to generating the DIE if
the debug level is terse and the declaration is public.
(dwarf2out_decl): Same.

Signed-off-by: Alexey Neyman 
---
 gcc/dwarf2out.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index fe46c7e1eee..5f9e82a8da2 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -26354,8 +26354,10 @@ gen_decl_die (tree decl, tree origin, struct vlr_context *ctx,
 case VAR_DECL:
 case RESULT_DECL:
   /* If we are in terse mode, don't generate any DIEs to represent any
-	 variable declarations or definitions.  */
-  if (debug_info_level <= DINFO_LEVEL_TERSE)
+	 variable declarations or definitions except for public ones.  */
+  if (debug_info_level < DINFO_LEVEL_TERSE
+	  || (debug_info_level == DINFO_LEVEL_TERSE
+	  && !TREE_PUBLIC(decl_or_origin)))
 	break;
 
   /* Avoid generating stray type DIEs during late dwarf dumping.
@@ -26831,8 +26833,10 @@ dwarf2out_decl (tree decl)
 	context_die = lookup_decl_die (DECL_CONTEXT (decl));
 
   /* If we are in terse mode, don't generate any DIEs to represent any
-	 variable declarations or definitions.  */
-  if (debug_info_level <= DINFO_LEVEL_TERSE)
+	 variable declarations or definitions except public ones.  */
+  if (debug_info_level < DINFO_LEVEL_TERSE
+	  || (debug_info_level == DINFO_LEVEL_TERSE
+	  && !TREE_PUBLIC(decl)))
 	return;
   break;
 
-- 
2.20.1

Re: [PATCH 3/3] libstdc++: Post-conversion whitespace and formatting adjustments

[Jonathan Wakely]

On 14/02/20 10:35 -0500, Patrick Palka wrote:

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h: Adjust whitespace and formatting.
* include/bits/ranges_algobase.h: Likewise.
* include/bits/ranges_uninitialized.h: Likewise.


OK for master, thanks!

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

[Maciej W. Rozycki]

On Fri, 14 Feb 2020, Mike Stump 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.
> 
> So, let step back.  You want to change the options to the compiler, 
> right?
> 
> So, imagine for a second that site.exp has those options, then you can 
> reliably grab them from that file and use them, no?  If so, then all you 
> have to do is put the content you need into site.exp, and then once it 
> is there, you can then merely add a little code to grab them and add 
> them, right?
> 
> So, pick testsuite that fails, and that you broke.  Back out the last 
> patch, and instead, in the Makefile (or whatever generate the Makefile, 
> look for the site.exp rule, and instead pilfer the data you want create 
> it up into an existing variable, if relevant to it, and if not, create a 
> new one.
> 
> For some of these files we see they come from automake, so we google, 
> then we find:
> 
> http://gnu-automake.7480.n7.nabble.com/Automake-and-dejagnu-s-site-exp-file-td4414.html
> 
> and presto, a 5 line solution to an existing problem.
> 
> Is that kinda sort similar to what you want to do?  Now that's a 12 year 
> old answer the the problem, I didn't check to see if there is a newer 
> answer.  It looks reasonable enough.

 Huh?  That's exactly what v1 did, it added:

set GCC_UNDER_TEST {@CC@}

(with @CC@ substituted by `configure' of course) to `site.exp' produced by 
`make check' (as constructed by `automake'[1]).  That caused Julian and 
Chung-Lin trouble.

 So I don't really know what you are talking about or trying to suggest 
me; AFAICT your idea was already tried and failed (though Chung-Lin may 
provide further input I asked for that may help).

References:

[1] 

  Maciej

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[Segher Boessenkool]

On Fri, Feb 14, 2020 at 08:24:30PM +, GT wrote:
> Function rs6000_simd_clone_adjust, even though it's body is empty,
> cannot simply be removed. I tried it. It resulted in ICE. In my
> view, leaving it empty is preferable to modifying other files
> unrelated to rs6000.c in order to avoid having a function whose
> body is empty.

Please Cc: the rs6000 maintainers on rs6000 patches, you will get a
reply faster, and more reliably.

Please don't use binary attachments, it takes effort to reply to those.


Segher

Re: [PATCH 2/3] libstdc++: Convert the ranges algorithm entities into function objects

[Jonathan Wakely]

On 14/02/20 10:35 -0500, Patrick Palka wrote:

This is the standard way to inhibit ADL for these entities, which is required as
per [algorithms.requirements] p2 and [specialized.algorithms] p4.  The
conversion was done mostly mechanically with a custom Vim macro.

[  To make it easier to review, the diffstat below was generated with the -w
  flag, which ignores all changes to whitespace.  Formatting will be fixed in a
  subsequent patch.  ]

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h: (adjacent_find, all_of, any_of,
binary_search, copy_if, count, count_if, equal_range, find, find_end,
find_first_of, find_if, find_if_not, for_each, generate, generate_n,
includes, inplace_merge, is_heap, is_heap_until, is_partitioned,
is_permutation, is_sorted, is_sorted_until, lexicographical_compare,
lower_bound, make_heap, max, max_element, merge, min, min_element,
minmax, minmax_element, mismatch, next_permutation, none_of,
nth_element, partial_sort, partial_sort_copy, partition, partition_copy,
partition_point, pop_heap, prev_permutation, push_heap, remove,
remove_copy, remove_copy_if, remove_if, replace, replace_copy,
replace_copy_if, replace_if, reverse, reverse_copy, rotate, rotate_copy,
search, search_n, set_difference, set_intersection,
set_symmetric_difference, set_union, shuffle, sort, sort_heap,
stable_partition, stable_sort, swap_ranges, transform, unique,
unique_copy, upper_bound): Convert into function objects.
* include/bits/ranges_algobase.h: (equal, copy, move, copy_n, fill_n,
fill, move_backward, copy_backward): Likewise.
* include/bits/ranges_uninitialized.h (uninitialized_default_construct,
uninitialized_default_construct_n, uninitialized_value_construct,
uninitialized_value_construct_n, uninitialized_copy,
uninitialized_copy_n, uninitialized_move, uninitialized_move_n,
uninitialized_fill, uninitialized_fill_n, construct_at, destroy_at,
destroy, destroy_n): Likewise.


OK for master, thanks.

Re: [PATCH] debug/93751 Generate DIEs for external variables with -g1

[Alexey Neyman]

On 2/14/20 4:36 PM, Alexey Neyman wrote:

Hi all,

As reported here, 
https://gcc.gnu.org/ml/gcc-help/2020-02/msg00062.html, GCC does not 
behave according to manual when `-gdwarf -g1` options are used; it 
does not generate the debugging information for external variables 
even though it is supposed to (and it does so for other debugging 
formats):


aneyman@supox:/tmp$ cat foo.c
int foo __attribute__((externally_visible));


Just as a clarification, the __attribute__((externally_visible)) is not 
needed; this is copied from the original bug report to gcc-help mailing 
list where it indicated that neither external linkage nor this attribute 
made GCC behave as described in the manual.



Regards,
Alexey.



aneyman@supox:/tmp$ gcc -c -O2 -gdwarf -g1 foo.c
aneyman@supox:/tmp$ readelf -wi foo.o
aneyman@supox:/tmp$ gcc -c -O2 -gdwarf -g2 foo.c
aneyman@supox:/tmp$ readelf -wi foo.o
...
<1><1d>: Abbrev Number: 2 (DW_TAG_variable)
    <1e>   DW_AT_name    : foo


The attached patch fixes this issue.

Regards,
Alexey.

[PATCH] match.pd: Disallow side-effects in GENERIC for non-COND_EXPR to COND_EXPR simplifications [PR93744]

[Jakub Jelinek]

Hi!

As the following testcases show (the first one reported, last two
found by code inspection), we need to disallow side-effects
in simplifications that turn some unconditional expression into conditional
one.  From my little understanding of genmatch.c, it is able to
automatically disallow side effects if the same operand is used multiple
times in the match pattern, maybe if it is used multiple times in the
replacement pattern, and if it is used in conditional contexts in the match
pattern, could it be taught to handle this case too?  If yes, perhaps
just the first hunk could be usable for 8/9 backports (+ the testcases).

Bootstrapped/regtested on x86_64-linux and i686-linux.

2020-02-15  Jakub Jelinek  

PR tree-optimization/93744
* match.pd (((m1 >/=/<= m2) * d -> (m1 >/=/<= m2) ? d : 0,
A - ((A - B) & -(C cmp D)) -> (C cmp D) ? B : A,
A + ((B - A) & -(C cmp D)) -> (C cmp D) ? B : A): For GENERIC, make
sure @2 in the first and @1 in the other patterns has no side-effects.

* gcc.c-torture/execute/pr93744-1.c: New test.
* gcc.c-torture/execute/pr93744-2.c: New test.
* gcc.c-torture/execute/pr93744-3.c: New test.

--- gcc/match.pd.jj 2020-02-05 11:12:33.679383217 +0100
+++ gcc/match.pd2020-02-14 22:49:22.858771394 +0100
@@ -1472,7 +1472,8 @@ (define_operator_list COND_TERNARY
 (for cmp (gt lt ge le)
 (simplify
  (mult (convert (cmp @0 @1)) @2)
-  (cond (cmp @0 @1) @2 { build_zero_cst (type); })))
+  (if (GIMPLE || !TREE_SIDE_EFFECTS (@2))
+   (cond (cmp @0 @1) @2 { build_zero_cst (type); }
 
 /* For integral types with undefined overflow and C != 0 fold
x * C EQ/NE y * C into x EQ/NE y.  */
@@ -2709,7 +2710,8 @@ (define_operator_list COND_TERNARY
&& TREE_CODE (TREE_TYPE (@4)) != BOOLEAN_TYPE
&& INTEGRAL_TYPE_P (TREE_TYPE (@5))
&& (TYPE_PRECISION (TREE_TYPE (@4)) >= TYPE_PRECISION (type)
-  || !TYPE_UNSIGNED (TREE_TYPE (@4
+  || !TYPE_UNSIGNED (TREE_TYPE (@4)))
+   && (GIMPLE || !TREE_SIDE_EFFECTS (@1)))
(cond (cmp @2 @3) @1 @0)))
  (simplify
   (plus:c @0 (bit_and:c (minus @1 @0)
@@ -2719,7 +2721,8 @@ (define_operator_list COND_TERNARY
&& TREE_CODE (TREE_TYPE (@4)) != BOOLEAN_TYPE
&& INTEGRAL_TYPE_P (TREE_TYPE (@5))
&& (TYPE_PRECISION (TREE_TYPE (@4)) >= TYPE_PRECISION (type)
-  || !TYPE_UNSIGNED (TREE_TYPE (@4
+  || !TYPE_UNSIGNED (TREE_TYPE (@4)))
+   && (GIMPLE || !TREE_SIDE_EFFECTS (@1)))
(cond (cmp @2 @3) @1 @0
 
 /* Simplifications of shift and rotates.  */
--- gcc/testsuite/gcc.c-torture/execute/pr93744-1.c.jj  2020-02-14 
22:50:58.993346192 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr93744-1.c 2020-02-14 
22:49:57.934251395 +0100
@@ -0,0 +1,14 @@
+/* PR tree-optimization/93744 */
+
+typedef int I;
+
+int
+main ()
+{
+  int a = 0;
+  I b = 0;
+  (a > 0) * (b |= 2);
+  if (b != 2)
+__builtin_abort ();
+  return 0;
+}
--- gcc/testsuite/gcc.c-torture/execute/pr93744-2.c.jj  2020-02-14 
22:51:01.100314955 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr93744-2.c 2020-02-14 
22:50:18.299949478 +0100
@@ -0,0 +1,21 @@
+/* PR tree-optimization/93744 */
+
+int w;
+
+int
+foo (int x, int y, int z)
+{
+  int r = z - ((z - w++) & -(x < y));
+  return r;
+}
+
+int
+main ()
+{
+  w = 4;
+  if (foo (5, 7, 12) != 4 || w != 5)
+__builtin_abort ();
+  if (foo (7, 5, 12) != 12 || w != 6)
+__builtin_abort ();
+  return 0;
+}
--- gcc/testsuite/gcc.c-torture/execute/pr93744-3.c.jj  2020-02-14 
22:51:03.415280636 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr93744-3.c 2020-02-14 
22:50:25.820837971 +0100
@@ -0,0 +1,21 @@
+/* PR tree-optimization/93744 */
+
+int w;
+
+int
+foo (int x, int y, int z)
+{
+  int r = z + ((w++ - z) & -(x < y));
+  return r;
+}
+
+int
+main ()
+{
+  w = 4;
+  if (foo (5, 7, 12) != 4 || w != 5)
+__builtin_abort ();
+  if (foo (7, 5, 12) != 12 || w != 6)
+__builtin_abort ();
+  return 0;
+}

Jakub

[PATCH] wwwdocs: P1042R1: mention only partial support [PR92319]

[Jakub Jelinek]

On Fri, Feb 14, 2020 at 08:41:45AM +0100, Jason Merrill wrote:
> > I'm afraid I'm completely lost about the padding preservation/removal
> > changes that are also in the paper, so haven't touched that part.

For this, shall we mention the support is only partial like this?
The standard has some example testcases that aren't handled properly by
libcpp.

diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index f698393d..3f69d443 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -86,7 +86,9 @@
   http://wg21.link/p0306r4;>P0306R4
   http://wg21.link/p1042r1;>P1042R1
8
-(partial, no #__VA_OPT__ support) 
+(partial, no #__VA_OPT__ support) 
+  10
+(partial, no placemarker token handling changes)

 
 


Jakub

Re: [PATCH] c++: Fix ICE with ill-formed array list-initialization [PR93712]

[Jason Merrill]

On 2/13/20 8:56 PM, Marek Polacek wrote:

My P0388R4 patch changed build_array_conv to create an identity
conversion at the start of the conversion chain.


Hmm, an identity conversion of {} suggests that it has a type, which it 
doesn't in the language.  I'm not strongly against it, but what was the 
reason for this change?



That was a sound change but now we crash in convert_like_real

  7457 case ck_identity:
  7458   if (BRACE_ENCLOSED_INITIALIZER_P (expr))
  7459 {
  7460   int nelts = CONSTRUCTOR_NELTS (expr);
  7461   if (nelts == 0)
  7462 expr = build_value_init (totype, complain);
  7463   else if (nelts == 1)
  7464 expr = CONSTRUCTOR_ELT (expr, 0)->value;
  7465   else
  7466 gcc_unreachable ();  // HERE
  7467 }


Right, this is assuming that any other {} will either be ill-formed or 
handled by ck_aggr or ck_list.  How are we getting here without going 
through one of those?



in a test like this

   int f (int const (&)[2])
   {
 return f({1, " "});
   }

I considered fixing this when performing overload resolution (clang says
"no matching function for call to 'f'"), but then it occured to me that
we crash in different contexts too, so I'm just turning the assert into
an early return.

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

2020-02-13  Marek Polacek  

PR c++/93712 - ICE with ill-formed array list-initialization.
* call.c (convert_like_real): Turn an assert into a return.

* g++.dg/cpp0x/initlist-array11.C: New test.
---
  gcc/cp/call.c |  2 +-
  gcc/testsuite/g++.dg/cpp0x/initlist-array11.C | 10 ++
  2 files changed, 11 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array11.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 51621b7dd87..eba0ed8041d 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7463,7 +7463,7 @@ convert_like_real (conversion *convs, tree expr, tree fn, 
int argnum,
  else if (nelts == 1)
expr = CONSTRUCTOR_ELT (expr, 0)->value;
  else
-   gcc_unreachable ();
+   return error_mark_node;
}
expr = mark_use (expr, /*rvalue_p=*/!convs->rvaluedness_matches_p,
   /*read_p=*/true, UNKNOWN_LOCATION,
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-array11.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-array11.C
new file mode 100644
index 000..7e76b588471
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-array11.C
@@ -0,0 +1,10 @@
+// PR c++/93712 - ICE with ill-formed array list-initialization.
+// { dg-do compile { target c++11 } }
+
+int f (const int (&)[2]);
+
+int g ()
+{
+  const int ()[2] = {1, "foo"}; // { dg-error "invalid conversion" }
+  return f({1, "foo"}); // { dg-error "invalid conversion" }
+}

base-commit: 1d69147af203d4dcd2270429f90c93f1a37ddfff

Re: [PATCH]Several intrinsic macros lack a closing parenthesis[PR93274]

[Uros Bizjak]

On Fri, Feb 14, 2020 at 8:06 AM Uros Bizjak  wrote:
>
> On Fri, Feb 14, 2020 at 7:03 AM Hongtao Liu  wrote:
> >
> > On Thu, Feb 13, 2020 at 5:31 PM Hongtao Liu  wrote:
> > >
> > > On Thu, Feb 13, 2020 at 5:12 PM Uros Bizjak  wrote:
> > > >
> > > > On Thu, Feb 13, 2020 at 9:53 AM Jakub Jelinek  wrote:
> > > > >
> > > > > On Thu, Feb 13, 2020 at 09:39:05AM +0100, Uros Bizjak wrote:
> > > > > > > Changelog
> > > > > > > gcc/
> > > > > > >* config/i386/avx512vbmi2intrin.h
> > > > > > >(_mm512_[,mask_,maskz_]shrdi_epi16,
> > > > > > >_mm512_[,mask_,maskz_]shrdi_epi32,
> > > > > > >_m512_[,mask_,maskz_]shrdi_epi64,
> > > > > > >_mm512_[,mask_,maskz_]shldi_epi16,
> > > > > > >_mm512_[,mask_,maskz_]shldi_epi32,
> > > > > > >_m512_[,mask_,maskz_]shldi_epi64): Fix typo of lacking a
> > > > > > >closing parenthesis.
> > > > > > >* config/i386/avx512vbmi2vlintrin.h
> > > > > > >(_mm256_[,mask_,maskz_]shrdi_epi16,
> > > > > > >_mm256_[,mask_,maskz_]shrdi_epi32,
> > > > > > >_m256_[,mask_,maskz_]shrdi_epi64,
> > > > > > >_mm_[,mask_,maskz_]shrdi_epi16,
> > > > > > >_mm_[,mask_,maskz_]shrdi_epi32,
> > > > > > >_mm_[,mask_,maskz_]shrdi_epi64,
> > > > > > >_mm256_[,mask_,maskz_]shldi_epi16,
> > > > > > >_mm256_[,mask_,maskz_]shldi_epi32,
> > > > > > >_m256_[,mask_,maskz_]shldi_epi64,
> > > > > > >_mm_[,mask_,maskz_]shldi_epi16,
> > > > > > >_mm_[,mask_,maskz_]shldi_epi32,
> > > > > > >_mm_[,mask_,maskz_]shldi_epi64): Ditto.
> > > > > > >
> > > > > > > gcc/testsuite/
> > > > > > >* gcc.target/i386/avx512vbmi2-vpshld-1.c: New test.
> > > > > > >* gcc.target/i386/avx512vbmi2-vpshld-O0-1.c: Ditto.
> > > > > > >* gcc.target/i386/avx512vbmi2-vpshrd-1.c: Ditto.
> > > > > > >* gcc.target/i386/avx512vbmi2-vpshrd-O0-1.c: Ditto.
> > > > > > >* gcc.target/i386/avx512vl-vpshld-O0-1.c: Ditto.
> > > > > > >* gcc.target/i386/avx512vl-vpshrd-O0-1.c: Ditto.
> > > > > >
> > > > > > This is obvious patch, so OK for mainline and backports.
> > > > >
> > > > > The header changes sure, but for the testsuite, the standard way
> > > > > would be to have it covered in the standard tests we have for this.
> > > > > I think that is gcc.target/i386/sse-{13,14,22a,23}.c, so it would be 
> > > > > worth
> > > > > trying to figure out why it hasn't caught that.
> > > >
> > > > Indeed. It looks that these macros are not listed in sse-14.c, which
> > > > would catch the problem. So, there is no need for new -O0 tests,
> > > > please add missing functions to sse-14.c and sse-22.c testcases. I was
> > > > also surprised that no testsuite coverage for vbmi2 functions was
> > > > added at submission.
> > > >
> > > Yes, i saw that, thanks.
> > > > Uros.
> > > >
> > > > > And, I don't think we allow any wildcards etc. (and 
> > > > > [,whatever,whateverelse]
> > > > > isn't even one, neither regexp nor shell wildcard) in the names of 
> > > > > functions
> > > > > changed, they can appear in the description text, but for the names of
> > > > > macros one needs to list them all expanded, people do grep for those.
> > > > >
> > > > > Jakub
> > > > >
> > >
> > >
> > >
> > > --
> > > BR,
> > > Hongtao
> >
> > Update patch:
> > Update Changelog, delete O0 testcase, and add testcase in sse-14.c, sse-22.c
>
> OK.

Please also commit ChangeLog entries to relevant ChangeLog files.

Uros.

[PATCH] sra: Avoid verification failure (PR 93516)

[Martin Jambor]

Hi,

get_ref_base_and_extent can return different sizes for COMPONENT_REFs
and DECLs of the same type, with the latter including (more?)  padding.
When in the IL there is an assignment between such a COMPONENT_REF and a
DECL, SRA will try to propagate the access from the former as a child of
the latter, creating an artificial reference that does not match the
access's declared size, which triggers a verifier assert.

Fixed by teaching the propagation functions about this special situation
so that they don't do it.  The condition is the same that
build_user_friendly_ref_for_offset uses so the artificial reference
causing the verifier is guaranteed not to be created.

Bootstrapped and tested on x86_64-linux.  OK for trunk?

Thanks,

Martin


2020-02-10  Martin Jambor  
PR tree-optimization/93516
* tree-sra.c (propagate_subaccesses_from_rhs): Do not create
access of the same type as the parent.
(propagate_subaccesses_from_lhs): Likewise.

gcc/testsuite/
* g++.dg/tree-ssa/pr93516.C: New test.
---
 gcc/ChangeLog   |  7 ++
 gcc/testsuite/ChangeLog |  5 
 gcc/testsuite/g++.dg/tree-ssa/pr93516.C | 24 +++
 gcc/tree-sra.c  | 31 +++--
 4 files changed, 60 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr93516.C

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fa3cbb895e9..daba335cf79 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2020-02-10  Martin Jambor  
+
+   PR tree-optimization/93516
+   * tree-sra.c (propagate_subaccesses_from_rhs): Do not create
+   access of the same type as the parent.
+   (propagate_subaccesses_from_lhs): Likewise.
+
 2020-02-10  Feng Xue  
 
PR ipa/93203
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 0ede9604611..eada2ebed63 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-02-10  Martin Jambor  
+
+   PR tree-optimization/93516
+   * g++.dg/tree-ssa/pr93516.C: New test.
+
 2020-02-10  Feng Xue  
 
PR ipa/93203
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr93516.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr93516.C
new file mode 100644
index 000..2bba37c1386
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr93516.C
@@ -0,0 +1,24 @@
+// { dg-do compile }
+// { dg-options "-O2" } */
+
+struct b;
+struct c {
+  b *operator->();
+};
+class e {
+  void *f;
+  int d;
+
+public:
+  template  a g() { return *static_cast(this); }
+};
+struct h : e {};
+struct b {
+  void i(e);
+  e j();
+};
+void m() {
+  c k;
+  h l = k->j().g();
+  k->i(l);
+}
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index ea8594db193..a3bcd5f3e03 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2785,9 +2785,17 @@ propagate_subaccesses_from_rhs (struct access *lacc, 
struct access *racc)
}
 
   rchild->grp_hint = 1;
-  new_acc = create_artificial_child_access (lacc, rchild, norm_offset,
-   false, (lacc->grp_write
-   || rchild->grp_write));
+  /* Because get_ref_base_and_extent always includes padding in size for
+accesses to DECLs but not necessarily for COMPONENT_REFs of the same
+type, we might be actually attempting to here to create a child of the
+same type as the parent.  */
+  if (!types_compatible_p (lacc->type, rchild->type))
+   new_acc = create_artificial_child_access (lacc, rchild, norm_offset,
+ false,
+ (lacc->grp_write
+  || rchild->grp_write));
+  else
+   new_acc = lacc;
   gcc_checking_assert (new_acc);
   if (racc->first_child)
propagate_subaccesses_from_rhs (new_acc, rchild);
@@ -2834,10 +2842,19 @@ propagate_subaccesses_from_lhs (struct access *lacc, 
struct access *racc)
  continue;
}
 
-  struct access *new_acc
-   =  create_artificial_child_access (racc, lchild, norm_offset,
-  true, false);
-  propagate_subaccesses_from_lhs (lchild, new_acc);
+  /* Because get_ref_base_and_extent always includes padding in size for
+accesses to DECLs but not necessarily for COMPONENT_REFs of the same
+type, we might be actually attempting to here to create a child of the
+same type as the parent.  */
+  if (!types_compatible_p (racc->type, lchild->type))
+   {
+ struct access *new_acc
+   = create_artificial_child_access (racc, lchild, norm_offset,
+ true, false);
+ propagate_subaccesses_from_lhs (lchild, new_acc);
+   }
+  else
+   propagate_subaccesses_from_lhs (lchild, racc);
   ret = true;
 }
   return 

Re: [PATCH] sra: Avoid verification failure (PR 93516)

[Richard Biener]

On Fri, 14 Feb 2020, Martin Jambor wrote:

> Hi,
> 
> get_ref_base_and_extent can return different sizes for COMPONENT_REFs
> and DECLs of the same type, with the latter including (more?)  padding.
> When in the IL there is an assignment between such a COMPONENT_REF and a
> DECL, SRA will try to propagate the access from the former as a child of
> the latter, creating an artificial reference that does not match the
> access's declared size, which triggers a verifier assert.

"both" use DECL_SIZE, but those can differ dependent on alignment
for example.

> Fixed by teaching the propagation functions about this special situation
> so that they don't do it.  The condition is the same that
> build_user_friendly_ref_for_offset uses so the artificial reference
> causing the verifier is guaranteed not to be created.
> 
> Bootstrapped and tested on x86_64-linux.  OK for trunk?

OK.

Thanks,
Richard.

> Thanks,
> 
> Martin
> 
> 
> 2020-02-10  Martin Jambor  
>   PR tree-optimization/93516
>   * tree-sra.c (propagate_subaccesses_from_rhs): Do not create
>   access of the same type as the parent.
>   (propagate_subaccesses_from_lhs): Likewise.
> 
>   gcc/testsuite/
>   * g++.dg/tree-ssa/pr93516.C: New test.
> ---
>  gcc/ChangeLog   |  7 ++
>  gcc/testsuite/ChangeLog |  5 
>  gcc/testsuite/g++.dg/tree-ssa/pr93516.C | 24 +++
>  gcc/tree-sra.c  | 31 +++--
>  4 files changed, 60 insertions(+), 7 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr93516.C
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index fa3cbb895e9..daba335cf79 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,10 @@
> +2020-02-10  Martin Jambor  
> +
> + PR tree-optimization/93516
> + * tree-sra.c (propagate_subaccesses_from_rhs): Do not create
> + access of the same type as the parent.
> + (propagate_subaccesses_from_lhs): Likewise.
> +
>  2020-02-10  Feng Xue  
>  
>   PR ipa/93203
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 0ede9604611..eada2ebed63 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2020-02-10  Martin Jambor  
> +
> + PR tree-optimization/93516
> + * g++.dg/tree-ssa/pr93516.C: New test.
> +
>  2020-02-10  Feng Xue  
>  
>   PR ipa/93203
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr93516.C 
> b/gcc/testsuite/g++.dg/tree-ssa/pr93516.C
> new file mode 100644
> index 000..2bba37c1386
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr93516.C
> @@ -0,0 +1,24 @@
> +// { dg-do compile }
> +// { dg-options "-O2" } */
> +
> +struct b;
> +struct c {
> +  b *operator->();
> +};
> +class e {
> +  void *f;
> +  int d;
> +
> +public:
> +  template  a g() { return *static_cast(this); }
> +};
> +struct h : e {};
> +struct b {
> +  void i(e);
> +  e j();
> +};
> +void m() {
> +  c k;
> +  h l = k->j().g();
> +  k->i(l);
> +}
> diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
> index ea8594db193..a3bcd5f3e03 100644
> --- a/gcc/tree-sra.c
> +++ b/gcc/tree-sra.c
> @@ -2785,9 +2785,17 @@ propagate_subaccesses_from_rhs (struct access *lacc, 
> struct access *racc)
>   }
>  
>rchild->grp_hint = 1;
> -  new_acc = create_artificial_child_access (lacc, rchild, norm_offset,
> - false, (lacc->grp_write
> - || rchild->grp_write));
> +  /* Because get_ref_base_and_extent always includes padding in size for
> +  accesses to DECLs but not necessarily for COMPONENT_REFs of the same
> +  type, we might be actually attempting to here to create a child of the
> +  same type as the parent.  */
> +  if (!types_compatible_p (lacc->type, rchild->type))
> + new_acc = create_artificial_child_access (lacc, rchild, norm_offset,
> +   false,
> +   (lacc->grp_write
> +|| rchild->grp_write));
> +  else
> + new_acc = lacc;
>gcc_checking_assert (new_acc);
>if (racc->first_child)
>   propagate_subaccesses_from_rhs (new_acc, rchild);
> @@ -2834,10 +2842,19 @@ propagate_subaccesses_from_lhs (struct access *lacc, 
> struct access *racc)
> continue;
>   }
>  
> -  struct access *new_acc
> - =  create_artificial_child_access (racc, lchild, norm_offset,
> -true, false);
> -  propagate_subaccesses_from_lhs (lchild, new_acc);
> +  /* Because get_ref_base_and_extent always includes padding in size for
> +  accesses to DECLs but not necessarily for COMPONENT_REFs of the same
> +  type, we might be actually attempting to here to create a child of the
> +  same type as the parent.  */
> +  if (!types_compatible_p (racc->type, lchild->type))
> + 

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

[Richard Earnshaw (lists)]

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.

R.

OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

ChangeLog:
* config/aarch64/aarch64.c (aarch64_override_options): Don't
warn when the selected cpu was generic.
---
  gcc/config/aarch64/aarch64.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4a34dce..9173afe 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -14075,10 +14075,12 @@ aarch64_override_options (void)
explicit_tune_core = selected_tune->ident;
  }
/* If both -mcpu and -march are specified check that they are 
architecturally
- compatible, warn if they're not and prefer the -march ISA flags.  */
+ compatible, warn if they're not and prefer the -march ISA flags.
+ Only warn if not using the generic cpu.  */
else if (selected_arch)
  {
-  if (selected_arch->arch != selected_cpu->arch)
+  if (selected_cpu->ident != generic
+ && selected_arch->arch != selected_cpu->arch)
{
  warning (0, "switch %<-mcpu=%s%> conflicts with %<-march=%s%> switch",
   all_architectures[selected_cpu->arch].name,

Re: [PATCH] wwwdocs: P1042R1: mention only partial support [PR92319]

[Jason Merrill]

On 2/14/20 9:18 AM, Jakub Jelinek wrote:

On Fri, Feb 14, 2020 at 08:41:45AM +0100, Jason Merrill wrote:

I'm afraid I'm completely lost about the padding preservation/removal
changes that are also in the paper, so haven't touched that part.


For this, shall we mention the support is only partial like this?
The standard has some example testcases that aren't handled properly by
libcpp.


OK.


diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index f698393d..3f69d443 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -86,7 +86,9 @@
http://wg21.link/p0306r4;>P0306R4
http://wg21.link/p1042r1;>P1042R1
 8
-(partial, no #__VA_OPT__ support) 
+(partial, no #__VA_OPT__ support) 
+  10
+(partial, no placemarker token handling changes)
 
  
  


Jakub

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

[Andrew Pinski]

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.

Thanks,
Andrew Pinski


>
> R.
> > OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> >
> > Thanks,
> > Andrew Pinski
> >
> > ChangeLog:
> > * config/aarch64/aarch64.c (aarch64_override_options): Don't
> > warn when the selected cpu was generic.
> > ---
> >   gcc/config/aarch64/aarch64.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> > index 4a34dce..9173afe 100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/aarch64/aarch64.c
> > @@ -14075,10 +14075,12 @@ aarch64_override_options (void)
> >   explicit_tune_core = selected_tune->ident;
> >   }
> > /* If both -mcpu and -march are specified check that they are 
> > architecturally
> > - compatible, warn if they're not and prefer the -march ISA flags.  */
> > + compatible, warn if they're not and prefer the -march ISA flags.
> > + Only warn if not using the generic cpu.  */
> > else if (selected_arch)
> >   {
> > -  if (selected_arch->arch != selected_cpu->arch)
> > +  if (selected_cpu->ident != generic
> > +   && selected_arch->arch != selected_cpu->arch)
> >   {
> > warning (0, "switch %<-mcpu=%s%> conflicts with %<-march=%s%> 
> > switch",
> >  all_architectures[selected_cpu->arch].name,
> >
>