Re: enable sincos optimization on cygming targets

2020-10-22 Thread Jonathan Yong via Gcc-patches

On 10/22/20 11:30 AM, Alexandre Oliva wrote:

On Oct 22, 2020, Jonathan Yong wrote:


No objections for mingw-w64 since it has been tested, but I'm not
certain if the original mingw.org version has it.


Prompted by you, I looked into the original mingw32, and found it does
NOT have sincos, so I withdraw the patch, in favor of this one.  Since
this one affects only mingw-w64, I haven't checked whether cygwin has
it.  Hopefully someone with easier access to the platform can do so and
duplicate the change in the Cygwin-specific compiler configuration
header.



Thanks this patch is acceptable.




OpenPGP_0x713B5FE29C145D45_and_old_rev.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Re: [committed 1/2] libstdc++: Reduce header dependencies in and on

2020-10-22 Thread Jonathan Wakely via Gcc-patches

On 22/10/20 18:59 +0100, Jonathan Wakely wrote:

By moving std::make_obj_using_allocator and the related "utility
functions for uses-allocator construction" to a new header, we can avoid
including the whole of  in  and
.

In order to simplify the implementation of those utility functions they
now use concepts unconditionally. They are no longer defined if
__cpp_concepts is not defined. To simplify the code that uses those
functions I've introduced a __cpp_lib_make_obj_using_allocator feature
test macro (not specified in the standard, which might be an oversight).
That allows the code in  and  to
check the feature test macro to decide whether to use the new utilities,
or fall back to the C++17 code.

At the same time, this reshuffles some of the headers included by
 so that they are (mostly?) self-contained. It should no longer
be necessary to include other headers before  when
other parts of the library want to use std::shared_ptr without including
the whole of .

libstdc++-v3/ChangeLog:

* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/shared_ptr.h: Include .
* include/bits/shared_ptr_base.h: Include required headers here
directly, instead of in .
* include/bits/uses_allocator_args.h: New file. Move utility
functions for uses-allocator construction from  to here.
Only define the utility functions when concepts are available.
(__cpp_lib_make_obj_using_allocator): Define non-standard
feature test macro.
* include/std/condition_variable: Remove unused headers.
* include/std/future: Likewise.
* include/std/memory: Remove headers that are not needed
directly, and are now inclkuded where they're needed. Include
new  header.
* include/std/memory_resource: Include only the necessary
headers. Use new feature test macro to detect support for the
utility functions.
* include/std/scoped_allocator: Likewise.
* include/std/version (__cpp_lib_make_obj_using_allocator):
Define.



The recent changes to reduce includes in  went a bit
too far, and it's possible for std::forward_as_tuple to not be defined
when used.

While doing this, I noticed the problematic calls to forward_as_tuple

were not qualified, so performed unwanted ADL.
 
Fixed with this patch.


Tested powerpc64le-linux. Committed to trunk.
commit ca021ac617277ba73cb694f8d26ec0f5e1293451
Author: Jonathan Wakely 
Date:   Fri Oct 23 00:58:35 2020

libstdc++: Ensure std::forward_as_tuple is defined

The recent changes to reduce includes in  went a bit
too far, and it's possible for std::forward_as_tuple to not be defined
when used.

While doing this, I noticed the problematic calls to forward_as_tuple
were not qualified, so performed unwanted ADL.

libstdc++-v3/ChangeLog:

* include/experimental/memory_resource: Include .
(polymorphic_allocator::construct): Qualify forward_as_tuple.
* include/std/memory_resource: Likewise.

diff --git a/libstdc++-v3/include/experimental/memory_resource b/libstdc++-v3/include/experimental/memory_resource
index 1c4de70c533..ca1bad9ecd0 100644
--- a/libstdc++-v3/include/experimental/memory_resource
+++ b/libstdc++-v3/include/experimental/memory_resource
@@ -36,6 +36,7 @@
 
 #include 			// align, uses_allocator, __uses_alloc
 #include 		// pair, experimental::erased_type
+#include 			// tuple, forward_as_tuple
 #include 			// atomic
 #include // placement new
 #include 			// max_align_t
@@ -196,8 +197,8 @@ namespace pmr {
 	construct(pair<_Tp1,_Tp2>* __p, _Up&& __x, _Vp&& __y)
 	{
 	  this->construct(__p, piecewise_construct,
-			  forward_as_tuple(std::forward<_Up>(__x)),
-			  forward_as_tuple(std::forward<_Vp>(__y)));
+	  std::forward_as_tuple(std::forward<_Up>(__x)),
+	  std::forward_as_tuple(std::forward<_Vp>(__y)));
 	}
 
   template 
@@ -205,8 +206,8 @@ namespace pmr {
 	construct(pair<_Tp1,_Tp2>* __p, const std::pair<_Up, _Vp>& __pr)
 	{
 	  this->construct(__p, piecewise_construct,
-			  forward_as_tuple(__pr.first),
-			  forward_as_tuple(__pr.second));
+	  std::forward_as_tuple(__pr.first),
+	  std::forward_as_tuple(__pr.second));
 	}
 
   template 
@@ -214,8 +215,8 @@ namespace pmr {
 	construct(pair<_Tp1,_Tp2>* __p, pair<_Up, _Vp>&& __pr)
 	{
 	  this->construct(__p, piecewise_construct,
-			  forward_as_tuple(std::forward<_Up>(__pr.first)),
-			  forward_as_tuple(std::forward<_Vp>(__pr.second)));
+	  std::forward_as_tuple(std::forward<_Up>(__pr.first)),
+	  std::forward_as_tuple(std::forward<_Vp>(__pr.second)));
 	}
 
   template 
diff --git a/libstdc++-v3/include/std/memory_resource b/libstdc++-v3/include/std/memory_resource
index 350799ee382..40e23a2f9ce 100644
--- a/libstdc++-v3/include/std/memory_resource
+++ b/libstdc++-v3/include/std/memory_resource
@@ -45,6 +45,7 @@
 
 #if ! 

Re: [RS6000] Power10 vec-splati-runnable multiple test failures

2020-10-22 Thread Alan Modra via Gcc-patches
On Thu, Oct 22, 2020 at 09:08:58AM -0700, Carl Love wrote:
> I see the error print statement you changed so that it would not wrap. 
> I have always been told it is best not to break the print statement
> across two lines.  The argument is it makes it harder to find it in the
> code when using grep.  In this case, it should be clear what file the
> error statement is in.  What is your take in general about breaking or
> not breaking the body of an error print statement across lines?

Submit to https://gcc.gnu.org/codingconventions.html which says

"Formatting Conventions
 Line Length

 Lines shall be at most 80 columns."

Seriously, it doesn't matter what you or I think about the formatting
rules, they are in place for good reason.

-- 
Alan Modra
Australia Development Lab, IBM


Re: [RS6000] VSX_MM_SUFFIX

2020-10-22 Thread Alan Modra via Gcc-patches
On Thu, Oct 22, 2020 at 11:03:14AM -0500, Segher Boessenkool wrote:
> On Thu, Oct 22, 2020 at 08:58:10AM -0700, Carl Love wrote:
> > OK, looks like VSX_MM_SUFFIX doesn't exist anymore.  Don't know what
> > happed to it.  Thanks.
> 
> It never existed on trunk.  Please always regstrap patches on trunk
> before committing.  It feels unnecessary at times, but now you know
> why :-)

Regression testing wouldn't have caught the problem, unless Carl had
done so on power10.  "dg_do compile" tests don't run the assembler,
and "dg_do run" tests with "dg_require_effective_target power10_hw" do
nothing at all if not on power10 hardware.  The single test that might
have caught the problem, vec-splati-runnable.c wasn't even compiled.
That's why I submitted
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556757.html

-- 
Alan Modra
Australia Development Lab, IBM


Re: [Ada] Improve precision of Ada.Directories.Modification_Time

2020-10-22 Thread Hans-Peter Nilsson
On Wed, 21 Oct 2020, Iain Sandoe wrote:

> Arnaud Charlet  wrote:
>
> > > This patch breaks bootstrap on Darwin platforms.
> > >
> > > Pierre-Marie de Rodat  wrote:
> > >
> > > > The modification file time precision now defined by OS.
> > > >
> > > > Tested on x86_64-pc-linux-gnu, committed on trunk
> > > >
> > > > gcc/ada/
> > > >
> > > > * adaint.c (__gnat_file_time): New routine.
> > > > (__gnat_copy_attribs): Copy timestamps in nanoseconds.
> > > > * libgnat/a-direct.adb (C_Modification_Time): Bind to
> > > > __gnat_file_time.
> > > > (Modification_Time): Call to C_Modification_Time.
> > >
> > > #if defined(st_mtime)
> > >
> > > is a necessary test - but the fields in the stat structure on Darwin
> > > platforms are
> > > named st_{a,c,m}timespec rather than the Linux st_{a,c,m}tim.
> >
> > What about instead putting above extern long long __gnat_file_time the
> > following:
> >
> > #if __APPLE__
> > #define st_mtim st_mtimespec
> > #define st_atim st_atimespec
> > #endif
> >
> > To avoid having the two (nested) #if __APPLE__ and keep the code easier
> > to follow?
>
> works for me (the test patch was drafted quickly to allow bootstrap to
> continue)
> - I can amend the patch and (re-)test more widely.
>
> Iain

For future reference, TRT for this kind of problem is to
autoconf for the right struct field name, using AC_CHECK_MEMBER
or AC_CHECK_MEMBERS (then use e.g. #if HAVE_STAT_ST_MTIM / #if
HAVE_STAT_ST_MTIMESPEC, definitely not #if __APPLE__).

brgds, H-P


[r11-4270 Regression] FAIL: 20_util/polymorphic_allocator/construct_pair.cc (test for excess errors) on Linux/x86_64

2020-10-22 Thread sunil.k.pandey via Gcc-patches
On Linux/x86_64,

f5d9bc8ae81abe46640477bc9e655aa093947f5f is the first bad commit
commit f5d9bc8ae81abe46640477bc9e655aa093947f5f
Author: Jonathan Wakely 
Date:   Thu Oct 22 18:42:03 2020 +0100

libstdc++: Only include  in  if needed

caused

FAIL: 20_util/polymorphic_allocator/construct_pair.cc (test for excess errors)

with GCC configured with

Configured with: ../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-4270/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check 
RUNTESTFLAGS="conformance.exp=20_util/polymorphic_allocator/construct_pair.cc 
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check 
RUNTESTFLAGS="conformance.exp=20_util/polymorphic_allocator/construct_pair.cc 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check 
RUNTESTFLAGS="conformance.exp=20_util/polymorphic_allocator/construct_pair.cc 
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check 
RUNTESTFLAGS="conformance.exp=20_util/polymorphic_allocator/construct_pair.cc 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)


[committed] libstdc++: Fix custom clock in test

2020-10-22 Thread Jonathan Wakely via Gcc-patches
This test fails in C++20 mode because std::is_clock is false for the
test clock, because it doesn't define a duration member.

libstdc++-v3/ChangeLog:

* testsuite/30_threads/condition_variable/members/68519.cc:
Define recent_epoch_float_clock::duration to meet the Cpp17Clock
requirements.

Tested powerpc64le-linux. Committed to trunk.

commit 0a74a0e1a2d4668613bd5913a600ab644402cefd
Author: Jonathan Wakely 
Date:   Thu Oct 22 20:28:10 2020

libstdc++: Fix custom clock in test

This test fails in C++20 mode because std::is_clock is false for the
test clock, because it doesn't define a duration member.

libstdc++-v3/ChangeLog:

* testsuite/30_threads/condition_variable/members/68519.cc:
Define recent_epoch_float_clock::duration to meet the Cpp17Clock
requirements.

diff --git 
a/libstdc++-v3/testsuite/30_threads/condition_variable/members/68519.cc 
b/libstdc++-v3/testsuite/30_threads/condition_variable/members/68519.cc
index c86ca2ccdbf..307dccd7183 100644
--- a/libstdc++-v3/testsuite/30_threads/condition_variable/members/68519.cc
+++ b/libstdc++-v3/testsuite/30_threads/condition_variable/members/68519.cc
@@ -47,10 +47,11 @@ test_wait_for()
 // needs to use a more recent epoch.
 struct recent_epoch_float_clock
 {
-  using rep = std::chrono::duration::rep;
-  using period = std::chrono::duration::period;
-  using time_point = std::chrono::time_point>;
+  using duration = std::chrono::duration;
+  using rep = duration::rep;
+  using period = duration::period;
+  using time_point
+= std::chrono::time_point;
   static constexpr bool is_steady = true;
 
   static const std::chrono::steady_clock::time_point epoch;


PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

This is a new patch.  It turns off the warning about switching the long double
type via compile line if the GLIBC is 2.32 or newer.  It only does this if the
languages are C or C++, since those language libraries support switching the
long double type.  Other languages like Fortran don't have any current support
to provide both sets of interfaces to the library.

2020-10-21  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_option_override_internal): Allow
long double type to be changed for C/C++ if glibc 2.32 or newer.
---
 gcc/config/rs6000/rs6000.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 50039c0a53d..940c15f3265 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4158,10 +4158,16 @@ rs6000_option_override_internal (bool global_init_p)
 
   if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT && TARGET_LONG_DOUBLE_128)
{
+ /* Determine if the user can change the default long double type at
+compilation time.  Only C and C++ support this, and you need GLIBC
+2.32 or newer.  Only issue one warning.  */
  static bool warned_change_long_double;
- if (!warned_change_long_double)
+
+ if (!warned_change_long_double
+ && (!OPTION_GLIBC
+ || (!lang_GNU_C () && !lang_GNU_CXX ())
+ || ((TARGET_GLIBC_MAJOR * 1000) + TARGET_GLIBC_MINOR) < 2032))
{
- warned_change_long_double = true;
  if (TARGET_IEEEQUAD)
warning (OPT_Wpsabi, "Using IEEE extended precision "
 "%");
-- 
2.22.0


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


PowerPC: Use __float128 instead of __ieee128 in tests.

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Use __float128 instead of __ieee128 in tests.

I have split all of these patches into separate patches to hopefully get them
into the tree.

Two of the tests used the __ieee128 keyword instead of __float128.  This
patch changes those cases to use the official keyword.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

gcc/testsuite/
2020-10-22  Michael Meissner  

* gcc.target/powerpc/float128-cmp2-runnable.c: Use __float128
keyword instead of __ieee128.
* gcc.target/powerpc/pr92796.c: Use __float128 keyword instead of
__ieee128.
---
 gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr92796.c| 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c 
b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
index d376a3ca68e..16b70877355 100644
--- a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
@@ -18,7 +18,7 @@ int main(void)
 {
   int result;
   double a_dble, b_dble;
-  __ieee128 a_ieee128, b_ieee128;
+  __float128 a_ieee128, b_ieee128;
   
   a_dble = 3.10;
   b_dble = 3.10;
diff --git a/gcc/testsuite/gcc.target/powerpc/pr92796.c 
b/gcc/testsuite/gcc.target/powerpc/pr92796.c
index 1e671e175de..f2c6b8b7f5c 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr92796.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr92796.c
@@ -4,14 +4,14 @@
 
 typedef union
 {
-  __ieee128 a;
+  __float128 a;
   int b;
 } c;
 
-__ieee128
-d (__ieee128 x)
+__float128
+d (__float128 x)
 {
-  __ieee128 g;
+  __float128 g;
   c h;
   h.a = x;
   g = h.b & 5;
-- 
2.22.0


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


PowerPC: Update __float128 and __ibm128 error messages.

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Update __float128 and __ibm128 error messages.

I have split all of these patches into separate patches to hopefully get them
into the tree.

This patch attempts to make the error messages for intermixing IEEE 128-bit
floating point with IBM 128-bit extended double types to be clearer if the long
double type uses the IEEE 128-bit format.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

gcc/
2020-10-22  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_invalid_binary_op): Update error
messages about mixing IBM long double and IEEE 128-bit.

gcc/testsuite/
2020-10-22  Michael Meissner  

* gcc.target/powerpc/bfp/scalar-extract-exp-4.c: Update failure
messages.
* gcc.target/powerpc/bfp/scalar-extract-sig-4.c: Update failure
messages.
* gcc.target/powerpc/bfp/scalar-test-data-class-11.c: Update
failure messages.
* gcc.target/powerpc/bfp/scalar-test-neg-5.c: Update failure
messages.
* gcc.target/powerpc/float128-mix-2.c: New test.
* gcc.target/powerpc/float128-mix-3.c: New test.
* gcc.target/powerpc/float128-mix.c: Update failure messages.
---
 gcc/config/rs6000/rs6000.c| 20 ---
 .../powerpc/bfp/scalar-extract-exp-4.c|  4 +---
 .../powerpc/bfp/scalar-extract-sig-4.c|  2 +-
 .../powerpc/bfp/scalar-test-data-class-11.c   |  2 +-
 .../powerpc/bfp/scalar-test-neg-5.c   |  2 +-
 .../gcc.target/powerpc/float128-mix-2.c   | 17 
 .../gcc.target/powerpc/float128-mix-3.c   | 17 
 .../gcc.target/powerpc/float128-mix.c | 19 ++
 8 files changed, 53 insertions(+), 30 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-mix-2.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-mix-3.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 8c2544ee88d..50039c0a53d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -14386,22 +14386,10 @@ rs6000_invalid_binary_op (int op ATTRIBUTE_UNUSED,
 
   if (!TARGET_FLOAT128_CVT)
 {
-  if ((mode1 == KFmode && mode2 == IFmode)
- || (mode1 == IFmode && mode2 == KFmode))
-   return N_("__float128 and __ibm128 cannot be used in the same "
- "expression");
-
-  if (TARGET_IEEEQUAD
- && ((mode1 == IFmode && mode2 == TFmode)
- || (mode1 == TFmode && mode2 == IFmode)))
-   return N_("__ibm128 and long double cannot be used in the same "
- "expression");
-
-  if (!TARGET_IEEEQUAD
- && ((mode1 == KFmode && mode2 == TFmode)
- || (mode1 == TFmode && mode2 == KFmode)))
-   return N_("__float128 and long double cannot be used in the same "
- "expression");
+  if ((FLOAT128_IEEE_P (mode1) && FLOAT128_IBM_P (mode2))
+ || (FLOAT128_IBM_P (mode1) && FLOAT128_IEEE_P (mode2)))
+   return N_("Invalid mixing of IEEE 128-bit and IBM 128-bit floating "
+ "point types");
 }
 
   return NULL;
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-4.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-4.c
index 850ff620490..2065a287bb3 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-4.c
@@ -11,7 +11,5 @@ get_exponent (__ieee128 *p)
 {
   __ieee128 source = *p;
 
-  return __builtin_vec_scalar_extract_exp (source); /* { dg-error 
"'__builtin_vsx_scalar_extract_expq' requires" } */
+  return __builtin_vec_scalar_extract_exp (source); /* { dg-error 
"'__builtin_vsx_scalar_extract_exp.*' requires" } */
 }
-
-
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-4.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-4.c
index 32a53c6fffd..37bc8332961 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-4.c
@@ -11,5 +11,5 @@ get_significand (__ieee128 *p)
 {
   __ieee128 source = *p;
 
-  return __builtin_vec_scalar_extract_sig (source);/* { dg-error 
"'__builtin_vsx_scalar_extract_sigq' requires" } */
+  

PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

I have split all of these patches into separate patches to hopefully get them
into the tree.

This patch adds long double variants of the power10 __float128 built-in
functions.  This is needed when long double uses IEEE 128-bit because
__float128 uses TFmode in this case instead of KFmode.  If this patch is not
applied, these built-in functions can't be used when long double is IEEE
128-bit.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

gcc/
2020-10-22  Michael Meissner  

* config/rs6000/rs6000-call.c (altivec_overloaded_builtins): Add
built-in functions for long double built-ins that use IEEE
128-bit.
(rs6000_expand_builtin): Change the KF IEEE 128-bit comparison
insns to TF if long double is IEEE 128-bit.
* config/rs6000/rs6000-builtin.def (scalar_extract_exptf): Add
support for long double being IEEE 128-bit built-in functions.
(scalar_extract_sigtf): Likewise.
(scalar_test_neg_tf): Likewise.
(scalar_insert_exp_tf): Likewise.
(scalar_insert_exp_tfp): Likewise.
(scalar_cmp_exp_tf_gt): Likewise.
(scalar_cmp_exp_tf_lt): Likewise.
(scalar_cmp_exp_tf_eq): Likewise.
(scalar_cmp_exp_tf_unordered): Likewise.
(scalar_test_data_class_tf): Likewise.
---
 gcc/config/rs6000/rs6000-builtin.def | 11 
 gcc/config/rs6000/rs6000-call.c  | 40 
 2 files changed, 51 insertions(+)

diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 3eb55f0ae43..6f5685bf697 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -2401,8 +2401,11 @@ BU_P9V_64BIT_VSX_1 (VSESDP,  "scalar_extract_sig",   
CONST,  xsxsigdp)
 
 BU_FLOAT128_HW_VSX_1 (VSEEQP,  "scalar_extract_expq",  CONST,  xsxexpqp_kf)
 BU_FLOAT128_HW_VSX_1 (VSESQP,  "scalar_extract_sigq",  CONST,  xsxsigqp_kf)
+BU_FLOAT128_HW_VSX_1 (VSEETF,  "scalar_extract_exptf", CONST,  xsxexpqp_tf)
+BU_FLOAT128_HW_VSX_1 (VSESTF,  "scalar_extract_sigtf", CONST,  xsxsigqp_tf)
 
 BU_FLOAT128_HW_VSX_1 (VSTDCNQP, "scalar_test_neg_qp",  CONST,  xststdcnegqp_kf)
+BU_FLOAT128_HW_VSX_1 (VSTDCNTF, "scalar_test_neg_tf",  CONST,  xststdcnegqp_tf)
 BU_P9V_VSX_1 (VSTDCNDP,"scalar_test_neg_dp",   CONST,  xststdcnegdp)
 BU_P9V_VSX_1 (VSTDCNSP,"scalar_test_neg_sp",   CONST,  xststdcnegsp)
 
@@ -2420,6 +2423,8 @@ BU_P9V_64BIT_VSX_2 (VSIEDPF,  "scalar_insert_exp_dp", 
CONST,  xsiexpdpf)
 
 BU_FLOAT128_HW_VSX_2 (VSIEQP,  "scalar_insert_exp_q",  CONST,  xsiexpqp_kf)
 BU_FLOAT128_HW_VSX_2 (VSIEQPF, "scalar_insert_exp_qp", CONST,  xsiexpqpf_kf)
+BU_FLOAT128_HW_VSX_2 (VSIETF,  "scalar_insert_exp_tf", CONST,  xsiexpqp_tf)
+BU_FLOAT128_HW_VSX_2 (VSIETFF, "scalar_insert_exp_tfp", CONST, xsiexpqpf_tf)
 
 BU_P9V_VSX_2 (VSCEDPGT,"scalar_cmp_exp_dp_gt", CONST,  xscmpexpdp_gt)
 BU_P9V_VSX_2 (VSCEDPLT,"scalar_cmp_exp_dp_lt", CONST,  xscmpexpdp_lt)
@@ -2431,7 +2436,13 @@ BU_P9V_VSX_2 (VSCEQPLT,  "scalar_cmp_exp_qp_lt", CONST,  
xscmpexpqp_lt_kf)
 BU_P9V_VSX_2 (VSCEQPEQ,"scalar_cmp_exp_qp_eq", CONST,  
xscmpexpqp_eq_kf)
 BU_P9V_VSX_2 (VSCEQPUO,"scalar_cmp_exp_qp_unordered",  CONST,  
xscmpexpqp_unordered_kf)
 
+BU_P9V_VSX_2 (VSCETFGT,"scalar_cmp_exp_tf_gt", CONST,  
xscmpexpqp_gt_tf)
+BU_P9V_VSX_2 (VSCETFLT,"scalar_cmp_exp_tf_lt", CONST,  
xscmpexpqp_lt_tf)
+BU_P9V_VSX_2 (VSCETFEQ,"scalar_cmp_exp_tf_eq", CONST,  
xscmpexpqp_eq_tf)
+BU_P9V_VSX_2 (VSCETFUO,"scalar_cmp_exp_tf_unordered", CONST, 
xscmpexpqp_unordered_tf)
+
 BU_FLOAT128_HW_VSX_2 (VSTDCQP, "scalar_test_data_class_qp",CONST,  
xststdcqp_kf)
+BU_FLOAT128_HW_VSX_2 (VSTDCTF, "scalar_test_data_class_tf",CONST,  
xststdcqp_tf)
 BU_P9V_VSX_2 (VSTDCDP, "scalar_test_data_class_dp",CONST,  xststdcdp)
 BU_P9V_VSX_2 (VSTDCSP, "scalar_test_data_class_sp",CONST,  xststdcsp)
 
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 9fdf97bc803..15dd99ac68d 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -4585,6 +4585,8 @@ const struct altivec_builtin_types 

PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.

I have split all of these patches into separate patches to hopefully get them
into the tree.

This patch changes the __ibm128 emulator to use __builtin_pack_ieee128
instead of __builtin_pack_longdouble if long double is IEEE 128-bit, and
we need to use the __ibm128 type.  The code will run without this patch,
but this patch slightly optimizes it better.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

libgcc/
2020-10-22  Michael Meissner  

* config/rs6000/ibm-ldouble.c (pack_ldouble): Use
__builtin_pack_ieee128 if long double is IEEE 128-bit.
---
 libgcc/config/rs6000/ibm-ldouble.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libgcc/config/rs6000/ibm-ldouble.c 
b/libgcc/config/rs6000/ibm-ldouble.c
index dd2a02373f2..767fdd72683 100644
--- a/libgcc/config/rs6000/ibm-ldouble.c
+++ b/libgcc/config/rs6000/ibm-ldouble.c
@@ -102,9 +102,17 @@ __asm__ (".symver __gcc_qadd,_xlqadd@GCC_3.4\n\t"
 static inline IBM128_TYPE
 pack_ldouble (double dh, double dl)
 {
+  /* If we are building on a non-VSX system, the __ibm128 type is not defined.
+ This means we can't always use __builtin_pack_ibm128.  Instead, we use
+ __builtin_pack_longdouble if long double uses the IBM extended double
+ 128-bit format, and use the explicit __builtin_pack_ibm128 if long double
+ is IEEE 128-bit.  */
 #if defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IBM128__)  \
 && !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__))
   return __builtin_pack_longdouble (dh, dl);
+#elif defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IEEE128__) \
+&& !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__))
+  return __builtin_pack_ibm128 (dh, dl);
 #else
   union
   {
-- 
2.22.0


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


Re: [PATCH] Use precision and sign to compare types for ranges - update

2020-10-22 Thread Eric Botcazou
> Sorry for missing the regression.. it was there, it just snuck by me in
> the noise :-P
> 
> THis seems to resolve the issue on my end, and its the right thing.
> 
> Bootstrapped on x86_64-pc-linux-gnu, no regressions, for SURE this time,
> pushed.

No problem, thanks for the quick turnaround!

-- 
Eric Botcazou




PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.

I have split all of these patches into separate patches to hopefully get them
into the tree.

If we map nanq to nanf128 when long double is IEEE, it seems to lose the
special signaling vs. non-signaling NAN support.  This patch maps the functions
to the long double version if long double is IEEE 128-bit.  If this patch
is not applied, a few tests in the testsuite will start failing.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

gcc/
2020-10-22  Michael Meissner  

* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): If long
double is IEEE-128 map the nanq built-in functions to the long
double function, not the f128 function.
---
 gcc/config/rs6000/rs6000-c.c | 31 ---
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index cc1e997524e..bee78fcbac4 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -684,15 +684,32 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
   builtin_define ("__builtin_vsx_xvnmsubmsp=__builtin_vsx_xvnmsubsp");
 }
 
-  /* Map the old _Float128 'q' builtins into the new 'f128' builtins.  */
+  /* Map the old _Float128 'q' builtins into the new 'f128' builtins if long
+ double is IBM or 64-bit.
+
+ However, if long double is IEEE 128-bit, map both sets of built-in
+ functions to the normal long double version.  This shows up in nansf128
+ vs. nanf128.  */
   if (TARGET_FLOAT128_TYPE)
 {
-  builtin_define ("__builtin_fabsq=__builtin_fabsf128");
-  builtin_define ("__builtin_copysignq=__builtin_copysignf128");
-  builtin_define ("__builtin_nanq=__builtin_nanf128");
-  builtin_define ("__builtin_nansq=__builtin_nansf128");
-  builtin_define ("__builtin_infq=__builtin_inff128");
-  builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
+  if (FLOAT128_IEEE_P (TFmode))
+   {
+ builtin_define ("__builtin_fabsq=__builtin_fabsl");
+ builtin_define ("__builtin_copysignq=__builtin_copysignl");
+ builtin_define ("__builtin_nanq=__builtin_nanl");
+ builtin_define ("__builtin_nansq=__builtin_nansl");
+ builtin_define ("__builtin_infq=__builtin_infl");
+ builtin_define ("__builtin_huge_valq=__builtin_huge_vall");
+   }
+  else
+   {
+ builtin_define ("__builtin_fabsq=__builtin_fabsf128");
+ builtin_define ("__builtin_copysignq=__builtin_copysignf128");
+ builtin_define ("__builtin_nanq=__builtin_nanf128");
+ builtin_define ("__builtin_nansq=__builtin_nansf128");
+ builtin_define ("__builtin_infq=__builtin_inff128");
+ builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
+   }
 }
 
   /* Tell users they can use __builtin_bswap{16,64}.  */
-- 
2.22.0


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


PowerPC: Update long double IEEE 128-bit tests.

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Update long double IEEE 128-bit tests.

I have split all of these patches into separate patches to hopefully get them
into the tree.

This patch fixes 3 tests in the testsuite that fail if long double is set
to IEEE 128-bit.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

gcc/testsuite/
2020-10-22  Michael Meissner  

* c-c++-common/dfp/convert-bfp-11.c: If long double is IEEE
128-bit, skip the test.
* gcc.dg/nextafter-2.c: On PowerPC, if long double is IEEE
128-bit, include math.h to get the built-in mapped correctly.
* gcc.target/powerpc/pr70117.c: Add support for long double being
IEEE 128-bit.
---
 gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c |  7 +++
 gcc/testsuite/gcc.dg/nextafter-2.c  | 10 ++
 gcc/testsuite/gcc.target/powerpc/pr70117.c  |  6 --
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c 
b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
index 95c433d2c24..6ee0c1c6ae9 100644
--- a/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
+++ b/gcc/testsuite/c-c++-common/dfp/convert-bfp-11.c
@@ -5,6 +5,7 @@
Don't force 128-bit long doubles because runtime support depends
on glibc.  */
 
+#include 
 #include "convert.h"
 
 volatile _Decimal32 sd;
@@ -39,6 +40,12 @@ main ()
   if (sizeof (long double) != 16)
 return 0;
 
+  /* This test is written to test IBM extended double, which is a pair of
+ doubles.  If long double can hold a larger value than a double can, such
+ as when long double is IEEE 128-bit, just exit immediately.  */
+  if (LDBL_MAX_10_EXP > DBL_MAX_10_EXP)
+return 0;
+
   convert_101 ();
   convert_102 ();
 
diff --git a/gcc/testsuite/gcc.dg/nextafter-2.c 
b/gcc/testsuite/gcc.dg/nextafter-2.c
index e51ae94be0c..64e9e3c485f 100644
--- a/gcc/testsuite/gcc.dg/nextafter-2.c
+++ b/gcc/testsuite/gcc.dg/nextafter-2.c
@@ -13,4 +13,14 @@
 #  define NO_LONG_DOUBLE 1
 # endif
 #endif
+
+#if defined(_ARCH_PPC) && defined(__LONG_DOUBLE_IEEE128__)
+/* On PowerPC systems, long double uses either the IBM long double format, or
+   IEEE 128-bit format.  The compiler switches the long double built-in
+   function names and glibc switches the names when math.h is included.
+   Because this test is run with -fno-builtin, include math.h so that the
+   appropriate nextafter functions are called.  */
+#include 
+#endif
+
 #include "nextafter-1.c"
diff --git a/gcc/testsuite/gcc.target/powerpc/pr70117.c 
b/gcc/testsuite/gcc.target/powerpc/pr70117.c
index 3bbd2c595e0..928efe39c7b 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70117.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c
@@ -9,9 +9,11 @@
128-bit floating point, because the type is not enabled on those
systems.  */
 #define LDOUBLE __ibm128
+#define IBM128_MAX ((__ibm128) 1.79769313486231580793728971405301199e+308L)
 
 #elif defined(__LONG_DOUBLE_IBM128__)
 #define LDOUBLE long double
+#define IBM128_MAX LDBL_MAX
 
 #else
 #error "long double must be either IBM 128-bit or IEEE 128-bit"
@@ -75,10 +77,10 @@ main (void)
   if (__builtin_isnormal (ld))
 __builtin_abort ();
 
-  ld = LDBL_MAX;
+  ld = IBM128_MAX;
   if (!__builtin_isnormal (ld))
 __builtin_abort ();
-  ld = -LDBL_MAX;
+  ld = -IBM128_MAX;
   if (!__builtin_isnormal (ld))
 __builtin_abort ();
 
-- 
2.22.0


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


PowerPC: Add __float128 conversions to/from Decimal

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Add __float128 conversions to/from Decimal.

I have split all of these patches into separate patches to hopefully get them
into the tree.

This patch adds the various decimal to/from IEEE 128-bit conversions.  I
had to make some changes to the infrastructure, since that infrastructure
assumed that there is a sprintf/scanf format modifier to convert floating
point.  Instead, I used to str* conversion functions.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

libgcc/
2020-10-22  Michael Meissner  

* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
* config/rs6000/t-float128: Build __float128 conversions to and
from Decimal support functions.
* dfp-bit.c: Add support for building the PowerPC _Float128
to/from Decimal conversion functions.
* dfp-bit.h: Likewise.
---
 libgcc/config/rs6000/_dd_to_kf.c | 30 ++
 libgcc/config/rs6000/_kf_to_dd.c | 30 ++
 libgcc/config/rs6000/_kf_to_sd.c | 30 ++
 libgcc/config/rs6000/_kf_to_td.c | 30 ++
 libgcc/config/rs6000/_sd_to_kf.c | 30 ++
 libgcc/config/rs6000/_td_to_kf.c | 30 ++
 libgcc/config/rs6000/t-float128  | 20 -
 libgcc/dfp-bit.c | 10 +++--
 libgcc/dfp-bit.h | 37 +---
 9 files changed, 241 insertions(+), 6 deletions(-)
 create mode 100644 libgcc/config/rs6000/_dd_to_kf.c
 create mode 100644 libgcc/config/rs6000/_kf_to_dd.c
 create mode 100644 libgcc/config/rs6000/_kf_to_sd.c
 create mode 100644 libgcc/config/rs6000/_kf_to_td.c
 create mode 100644 libgcc/config/rs6000/_sd_to_kf.c
 create mode 100644 libgcc/config/rs6000/_td_to_kf.c

diff --git a/libgcc/config/rs6000/_dd_to_kf.c b/libgcc/config/rs6000/_dd_to_kf.c
new file mode 100644
index 000..081415fd393
--- /dev/null
+++ b/libgcc/config/rs6000/_dd_to_kf.c
@@ -0,0 +1,30 @@
+/* Copyright (C) 1989-2020 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+/* Decimal64 -> _Float128 conversion.  */
+#define FINE_GRAINED_LIBRARIES 1
+#define L_dd_to_kf 1
+#define WIDTH  64
+
+/* Use dfp-bit.c to do the real work.  */
+#include "dfp-bit.c"
diff --git a/libgcc/config/rs6000/_kf_to_dd.c b/libgcc/config/rs6000/_kf_to_dd.c
new file mode 100644
index 000..09a62cbe629
--- /dev/null
+++ b/libgcc/config/rs6000/_kf_to_dd.c
@@ -0,0 +1,30 @@
+/* Copyright (C) 1989-2020 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library 

PowerPC: Add -mno-gnu-attributes to ibm-ldouble.o

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Add -mno-gnu-attributes to ibm-ldouble.o.

I have split all of these patches into separate patches to hopefully get them
into the tree.

This patch is split off from the patch adding __float128 <-> Decimal
conversions.  This patch is needed to prevent the linker from issuing a
warning when the long double format is IEEE 128-bit.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

libgcc/
2020-10-22  Michael Meissner  

* config/rs6000/t-float128: Compile ibm-ldouble.o with
-mno-gnu-attributes.
---
 libgcc/config/rs6000/t-float128 | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
index d5413445189..c2cb3e2b705 100644
--- a/libgcc/config/rs6000/t-float128
+++ b/libgcc/config/rs6000/t-float128
@@ -69,6 +69,11 @@ $(fp128_ppc_obj)  : INTERNAL_CFLAGS += $(FP128_CFLAGS_SW)
 $(fp128_obj): $(fp128_includes)
 $(fp128_obj): $(srcdir)/config/rs6000/quad-float128.h
 
+
+# Turn off gnu attributes to allow using the IBM extended double support for
+# __ibm128 if long double uses the IEEE 128-bit representation.
+ibm-ldouble$(objext)   : INTERNAL_CFLAGS += -mno-gnu-attribute
+
 $(fp128_softfp_src) : $(srcdir)/soft-fp/$(subst -sw,,$(subst kf,tf,$@)) 
$(fp128_dep)
@src="$(srcdir)/soft-fp/$(subst -sw,,$(subst kf,tf,$@))"; \
echo "Create $@"; \
-- 
2.22.0


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


PowerPC: Map IEEE 128-bit long double built-in functions

2020-10-22 Thread Michael Meissner via Gcc-patches
PowerPC: Map IEEE 128-bit long double built-in functions

This patch is revised from the first and second versions of the patch posted.
It now uses the names that are not in the user's namespace (i.e. __sinieee128
instead of sinf128) that Joseph Myers suggested.

In addition, I added the changes suggested by Segher the last time this patch
was submitted (changing where the default is, fixing the scalbl built-in name,
using strlen and xaprintf).

I have split all of these patches into separate patches to hopefully get them
into the tree.

This patch goes through the built-in functions and changes the name of the
math, scanf, and printf built-in functions to use the functions that GLIBC
provides when long double uses the IEEE 128-bit representation.

In addition, changing the name in GCC allows the Fortran compiler to
automatically use the correct name.

To map the math functions, typically this patch changes l to
__ieee128.  However there are some exceptions that are handled with this
patch.

To map the printf functions,  is mapped to __ieee128.

To map the scanf functions,  is mapped to __isoc99_ieee128.

I have tested this patch with bootstrap builds on a little endian power9 system
running Linux.  With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch.  One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit.  I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler.  There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.

Can I install this into the trunk?

We have gotten some requests to back port these changes to GCC 10.x.  At the
moment, I am not planning to do the back port, but I may need to in the future.

gcc/
2020-10-22  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_mangle_decl_assembler_name): Add
support for mapping built-in function names for long double
built-in functions if long double is IEEE 128-bit.

gcc/testsuite/
2020-10-22  Michael Meissner  

* gcc.target/powerpc/float128-longdouble-math.c: New test.
* gcc.target/powerpc/float128-longdouble-stdio.c: New test.
* gcc.target/powerpc/float128-math.c: Adjust test for new name
being generated.
---
 gcc/config/rs6000/rs6000.c| 135 -
 .../powerpc/float128-longdouble-math.c| 567 ++
 .../powerpc/float128-longdouble-stdio.c   |  37 ++
 .../gcc.target/powerpc/float128-math.c|   6 +-
 4 files changed, 710 insertions(+), 35 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-math.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-longdouble-stdio.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 141684e3157..8c2544ee88d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -26893,56 +26893,127 @@ rs6000_globalize_decl_name (FILE * stream, tree decl)
library before you can switch the real*16 type at compile time.
 
We use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change this name.  We
-   only do this if the default is that long double is IBM extended double, and
-   the user asked for IEEE 128-bit.  */
+   only do this transformation if the __float128 type is enabled.  This
+   prevents us from doing the transformation on older 32-bit ports that might
+   have enabled using IEEE 128-bit floating point as the default long double
+   type.  */
 
 static tree
 rs6000_mangle_decl_assembler_name (tree decl, tree id)
 {
-  if (!TARGET_IEEEQUAD_DEFAULT && TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128
-  && TREE_CODE (decl) == FUNCTION_DECL && DECL_IS_BUILTIN (decl) )
+  if (TARGET_FLOAT128_TYPE && TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128
+  && TREE_CODE (decl) == FUNCTION_DECL
+  && fndecl_built_in_p (decl, BUILT_IN_NORMAL))
 {
   size_t len = IDENTIFIER_LENGTH (id);
   const char *name = IDENTIFIER_POINTER (id);
+  char *newname = NULL;
 
-  if (name[len - 1] == 'l')
+  /* See if it is one of the built-in functions with an unusual name.  */
+  switch (DECL_FUNCTION_CODE (decl))
{
- bool uses_ieee128_p = false;
- tree type = TREE_TYPE (decl);
- machine_mode ret_mode = TYPE_MODE (type);
+   case BUILT_IN_DREML:
+ newname = xstrdup ("__remainderieee128");
+ break;
 
- /* See if the function returns a IEEE 128-bit floating point type or
-complex type.  */
- if (ret_mode == TFmode || ret_mode == TCmode)
-   uses_ieee128_p = true;
- else
-   {
- function_args_iterator args_iter;
- tree arg;
+   case BUILT_IN_GAMMAL:
+ newname = xstrdup ("__lgammaieee128");
+ break;
+
+   case 

Re: [PATCH] c++: Fix verify_ctor_sanity ICE [PR96241]

2020-10-22 Thread Jason Merrill via Gcc-patches

On 10/15/20 6:18 PM, Marek Polacek wrote:

The code added in r10-6437 caused us to create a CONSTRUCTOR when we're
{}-initializing an aggregate.  Then we pass this new CONSTRUCTOR down to
cxx_eval_constant_expression which, if the CONSTRUCTOR isn't TREE_CONSTANT
or reduced_constant_expression_p, calls cxx_eval_bare_aggregate.  In
this case the CONSTRUCTOR wasn't reduced_constant_expression_p because
for r_c_e_p a CONST_DECL isn't good enough so it returns false.  So we
go to cxx_eval_bare_aggregate where we crash, because ctx->ctor wasn't
set up properly.  So my fix is to do so.  Since we're value-initializing,
I'm not setting CONSTRUCTOR_NO_CLEARING.

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

gcc/cp/ChangeLog:

PR c++/96241
* constexpr.c (cxx_eval_array_reference): Set up ctx->ctor if we
are initializing an aggregate.

gcc/testsuite/ChangeLog:

PR c++/96241
* g++.dg/cpp1y/constexpr-96241.C: New test.
---
  gcc/cp/constexpr.c   |  4 ++
  gcc/testsuite/g++.dg/cpp1y/constexpr-96241.C | 47 
  2 files changed, 51 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-96241.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index a118f8a810b..5193047670c 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3657,10 +3657,14 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, 
tree t,
   initializer, it's initialized from {}.  But use build_value_init
   directly for non-aggregates to avoid creating a garbage CONSTRUCTOR.  */
tree val;
+  constexpr_ctx new_ctx;
if (CP_AGGREGATE_TYPE_P (elem_type))
  {
tree empty_ctor = build_constructor (init_list_type_node, NULL);
val = digest_init (elem_type, empty_ctor, tf_warning_or_error);
+  new_ctx = *ctx;
+  new_ctx.ctor = build_constructor (elem_type, NULL);
+  ctx = _ctx;


In the case that 'val' is reduced_constant_expression_p, this results in 
a garbage constructor.  Let's try to free the new CONSTRUCTOR if it 
isn't returned from cxx_eval_constant_expression.



  }
else
  val = build_value_init (elem_type, tf_warning_or_error);
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-96241.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-96241.C
new file mode 100644
index 000..107f2b09de9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-96241.C
@@ -0,0 +1,47 @@
+// PR c++/96241
+// { dg-do compile { target c++14 } }
+
+#define assert(expr) static_assert (expr, #expr)
+
+enum E { o };
+
+struct S {
+  int e = o;
+};
+
+using T = S[3];
+
+constexpr struct S s[1][1][1] = { };
+assert (0 == s[0][0][0].e);
+
+constexpr int
+fn0 ()
+{
+  return T{}[0].e;
+}
+assert(fn0 () == 0);
+
+constexpr int
+fn1 ()
+{
+  S d[1];
+  int x = d[0].e;
+  return x;
+}
+assert(fn1 () == 0);
+
+constexpr int
+fn2 ()
+{
+  S d[1];
+  return d[0].e;
+}
+assert(fn2 () == 0);
+
+constexpr int
+fn3 ()
+{
+  struct X { int e = o; } d[1]{};
+  return d[0].e;
+}
+assert(fn3 () == 0);

base-commit: 7dbf96e2a2a673d78a23da9155c0b4c4c36621c7





[PATCH] Use precision and sign to compare types for ranges - update

2020-10-22 Thread Andrew MacLeod via Gcc-patches

On 10/22/20 3:16 PM, Andrew MacLeod via Gcc-patches wrote:

On 10/22/20 12:53 PM, Eric Botcazou wrote:

There are a few places in the ranger where we sanity check the types of
the ranges.  We were using types_compatible_p() but thats not really
acccurate as gimple allows types which are useless_type_conversion_p()
in only one direction, whereas types_compatible_p() requires casts in
both directions to be useless_type_conversion_p().

And, since its only a sanity check, ranges really only require that the
precision and sign be the same, so its a faster check anyway.

bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.

The Ada regression comes from this hunk:

diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index c4bfc658319..983f4c97e87 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -552,7 +552,7 @@ is_gimple_logical_p (const gimple *gs)
  case BIT_AND_EXPR:
  case BIT_IOR_EXPR:
    // Bitwise operations on single bits are logical too.
-  if (types_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
+  if (range_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
    boolean_type_node))
  return true;
    break;

which overlooks that boolean_type_node may have a precision not equal 
to 1

(it's 8 in Ada).  See useless_type_conversion_p which has:

   /* Preserve conversions to/from BOOLEAN_TYPE if types are not
 of precision one.  */
   if (((TREE_CODE (inner_type) == BOOLEAN_TYPE)
   != (TREE_CODE (outer_type) == BOOLEAN_TYPE))
  && TYPE_PRECISION (outer_type) != 1)
return false

bah.  And I cant seem to reproduce it on my machine with your 
reproducer, but I am seeing the other result it in my log. Point is 
still taken tho.
range_compatible_p should only be used during asserts as a sanity 
check for range interactions, not during actual code processing like 
that.


im currently testing the following, which reverts 2 places (both which 
check for logicals)  to use types_compatible_p instead.  The remaining 
uses are in range assertion code. This seems to resolve the original 
problem in my log.


Thanks for reducing it to the problematic change.  I'm verifying a new 
failure in libgomp isnt a result of this before I check it in.


Andrew



Sorry for missing the regression.. it was there, it just snuck by me in 
the noise :-P


THis seems to resolve the issue on my end, and its the right thing.

Bootstrapped on x86_64-pc-linux-gnu, no regressions, for SURE this time, 
pushed.






Author: Andrew MacLeod 
Date:   Thu Oct 22 15:39:37 2020 -0400

Use precision and sign to compare types for ranges

Updated to only use range_compatible_p in range assert sanity checks,
not for actual type cmpatibility.

* gimple-range-gori.cc (is_gimple_logical_p): Use types_compatible_p
for logical compatibility.
(logical_stmt_cache::cacheable_p): Ditto.

diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 983f4c97e87..5d50b111d2a 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -552,7 +552,7 @@ is_gimple_logical_p (const gimple *gs)
 	case BIT_AND_EXPR:
 	case BIT_IOR_EXPR:
 	  // Bitwise operations on single bits are logical too.
-	  if (range_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
+	  if (types_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
   boolean_type_node))
 	return true;
 	  break;
@@ -1165,7 +1165,7 @@ bool
 logical_stmt_cache::cacheable_p (gimple *stmt, const irange *lhs_range) const
 {
   if (gimple_code (stmt) == GIMPLE_ASSIGN
-  && range_compatible_p (TREE_TYPE (gimple_assign_lhs (stmt)),
+  && types_compatible_p (TREE_TYPE (gimple_assign_lhs (stmt)),
 			 boolean_type_node)
   && TREE_CODE (gimple_assign_rhs1 (stmt)) == SSA_NAME)
 {


Re: [patch] Add an if-exists-then-else spec function

2020-10-22 Thread Joseph Myers
This is OK.

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


Re: [PATCH v3] c, c++: Implement -Wsizeof-array-div [PR91741]

2020-10-22 Thread Joseph Myers
The C parts are OK.

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


Re: Patch ping

2020-10-22 Thread Joseph Myers
On Thu, 22 Oct 2020, Jakub Jelinek via Gcc-patches wrote:

> https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554804.html
>   - PR97164 - reject forming arrays with elt sizes not divisible by elt 
> alignment

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556153.html
>   - fix up plugin header install

OK.

The other patches need a self-contained submission showing the proposed 
commit message for that version of the patch, not just a discussion from 
the middle of a thread that can't be understood on its own without going 
through the rest of the discussion (and possibly previous patch versions) 
and doesn't say what form of explanation is proposed as a commit message.

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


Re: [PATCH 2/2] combine: Don't turn (mult (extend x) 2^n) into extract

2020-10-22 Thread Segher Boessenkool
On Thu, Oct 15, 2020 at 09:59:24AM +0100, Alex Coplan wrote:
> Currently, make_extraction() identifies where we can emit an ASHIFT of
> an extend in place of an extraction, but fails to make the corresponding
> canonicalization/simplification when presented with a MULT by a power of
> two. Such a representation is canonical when representing a left-shifted
> address inside a MEM.
> 
> This patch remedies this situation: after the patch, make_extraction()
> now also identifies RTXs such as:
> 
> (mult:DI (subreg:DI (reg:SI r)) (const_int 2^n))
> 
> and rewrites this as:
> 
> (mult:DI (sign_extend:DI (reg:SI r)) (const_int 2^n))
> 
> instead of using a sign_extract.

That is only correct if SUBREG_PROMOTED_VAR_P is true and
SUBREG_PROMOTED_UNSIGNED_P is false for r.  Is that guaranteed to be
true here (and how then?)


Segher


Re: [PATCH 2/2] combine: Don't turn (mult (extend x) 2^n) into extract

2020-10-22 Thread Segher Boessenkool
Hi Alex,

On Thu, Oct 22, 2020 at 09:36:02AM +0100, Alex Coplan wrote:
> Ping.
> 
> Hopefully this is easier to review/test now that we fix the AArch64 bug first
> and deliberately regress code quality so that the impact of the combine patch
> can be measured.

Yes, I am just busy.  I'll get to it soon.


Segher


Re: [PATCH 1/2] [OpenACC] Kernels loops annotation: C and C++.

2020-10-22 Thread Jason Merrill via Gcc-patches

On 9/9/20 1:53 PM, Sandra Loosemore wrote:

This patch detects loops in kernels regions that are candidates for
parallelization, and adds "#pragma acc loop auto" annotations to them.
This annotation is controlled by the -fopenacc-kernels-annotate-loops
option, which is enabled by default.  -Wopenacc-kernels-annotate-loops
can be used to produce diagnostics about loops that cannot be
annotated.


For the main body of the patch, I hope Jakub will look at it as the 
OpenMP maintainer.  I just have a couple of minor comments below.



2020-09-08  Sandra Loosemore  

gcc/c-family/
* c-common.h (c_oacc_annotate_loops_in_kernels_regions): Declare.
* c-omp.c: Include tree-iterator.h.
(enum annotation_state): New.
(struct annotation_info): New.
(do_not_annotate_loop): New.
(do_not_annotate_loop_nest): New.
(annotation_error): New.
(c_finish_omp_for_internal): New.
(c_finish_omp_for): Use c_finish_omp_for_internal.
(is_local_var): New.
(end_test_ok_for_annotation_r): New.
(end_test_ok_for_annotation): New.
(lang_specific_unwrap_initializer): New.
(annotate_for_loop): New.
(annotate_and_check_for_loop): New.
(annotate_loops_in_kernels_regions): New.
(c_oacc_annotate_loops_in_kernels_regions): New.
* c.opt (Wopenacc-kernels-annotate-loops): New.
(fopenacc-kernels-annotate-loops): New.

gcc/c/
* c-decl.c (c_unwrap_for_init): New.
(finish_function): Call c_oacc_annotate_loops_in_kernels_regions.
* c-parser.c (c_parser_oacc_loop): Set OACC_LOOP_COMBINED.

gcc/cp/
* decl.c (cp_unwrap_for_init): New.
(finish_function): Call c_oacc_annotate_loops_in_kernels_regions.
* parser.c (cp_parser_oacc_loop): Set OACC_LOOP_COMBINED.
* semantics.c (handle_omp_array_sections_1): Call STRIP_NOPS
on length and bound.
(handle_omp_array_sections): Likewise.

gcc/
* doc/invoke.texi (Option Summary): Add entries for
-Wopenacc-kernels-annotate-loops and
-fno-openacc-kernels-annotate-loops.
(Warning Options): Document -Wopenacc-kernels-annotate-loops.
(Optimization Options): Document
-fno-openacc-kernels-annotate-loops.
* tree.h (OACC_LOOP_COMBINED): New.

gcc/testsuite/
* c-c++-common/goacc/classify-kernels-unparallelized.c: Add
-fno-openacc-kernels-annotate-loops option.
* c-c++-common/goacc/classify-kernels.c: Likewise.
* c-c++-common/goacc/combined-directives.c: Likewise.
* c-c++-common/goacc/kernels-counter-var-redundant-load.c:
Likewise.
* c-c++-common/goacc/kernels-counter-vars-function-scope.c:
Likewise.
* c-c++-common/goacc/kernels-double-reduction-n.c: Likewise.
* c-c++-common/goacc/kernels-double-reduction.c: Likewise.
* c-c++-common/goacc/kernels-loop-2.c: Likewise.
* c-c++-common/goacc/kernels-loop-3.c: Likewise.
* c-c++-common/goacc/kernels-loop-data-2.c: Likewise.
* c-c++-common/goacc/kernels-loop-data-enter-exit-2.c: Likewise.
* c-c++-common/goacc/kernels-loop-data-enter-exit.c: Likewise.
* c-c++-common/goacc/kernels-loop-data-update.c: Likewise.
* c-c++-common/goacc/kernels-loop-data.c: Likewise.
* c-c++-common/goacc/kernels-loop-g.c: Likewise.
* c-c++-common/goacc/kernels-loop-mod-not-zero.c: Likewise.
* c-c++-common/goacc/kernels-loop-n.c: Likewise.
* c-c++-common/goacc/kernels-loop-nest.c: Likewise.
* c-c++-common/goacc/kernels-loop.c: Likewise.
* c-c++-common/goacc/kernels-one-counter-var.c: Likewise.
* c-c++-common/goacc/kernels-parallel-loop-data-enter-exit.c:
Likewise.
* c-c++-common/goacc/kernels-reduction.c: Likewise.
* c-c++-common/goacc/kernels-loop-annotation-1.c: New.
* c-c++-common/goacc/kernels-loop-annotation-2.c: New.
* c-c++-common/goacc/kernels-loop-annotation-3.c: New.
* c-c++-common/goacc/kernels-loop-annotation-4.c: New.
* c-c++-common/goacc/kernels-loop-annotation-5.c: New.
* c-c++-common/goacc/kernels-loop-annotation-6.c: New.
* c-c++-common/goacc/kernels-loop-annotation-7.c: New.
* c-c++-common/goacc/kernels-loop-annotation-8.c: New.
* c-c++-common/goacc/kernels-loop-annotation-9.c: New.
* c-c++-common/goacc/kernels-loop-annotation-10.c: New.
* c-c++-common/goacc/kernels-loop-annotation-11.c: New.
* c-c++-common/goacc/kernels-loop-annotation-12.c: New.
* c-c++-common/goacc/kernels-loop-annotation-13.c: New.
* c-c++-common/goacc/kernels-loop-annotation-14.c: New.
* c-c++-common/goacc/kernels-loop-annotation-15.c: New.
* c-c++-common/goacc/kernels-loop-annotation-16.c: New.
* c-c++-common/goacc/kernels-loop-annotation-17.c: New.
* 

[r11-4226 Regression] FAIL: gfortran.dg/bound_6.f90 -O3 -g execution test on Linux/x86_64

2020-10-22 Thread sunil.k.pandey via Gcc-patches
On Linux/x86_64,

b960a9c83a93b58a84a7a370002990810675ac5d is the first bad commit
commit b960a9c83a93b58a84a7a370002990810675ac5d
Author: Richard Biener 
Date:   Thu Oct 22 09:29:47 2020 +0200

middle-end/97521 - fix VECTOR_CST expansion

caused

FAIL: c-c++-common/torture/vector-compare-2.c   -O0  execution test
FAIL: gcc.target/i386/avx2-vpcmpeqq-2.c execution test
FAIL: gfortran.dg/allocate_zerosize_3.f   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/allocate_zerosize_3.f   -O3 -g  execution test
FAIL: gfortran.dg/bound_6.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/bound_6.f90   -O3 -g  execution test

with GCC configured with

Configured with: ../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-4226/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg-torture.exp=c-c++-common/torture/vector-compare-2.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg-torture.exp=c-c++-common/torture/vector-compare-2.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/avx2-vpcmpeqq-2.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/allocate_zerosize_3.f 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/bound_6.f90 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)


Re: [patch] Use precision and sign to compare types for ranges

2020-10-22 Thread Andrew MacLeod via Gcc-patches

On 10/22/20 12:53 PM, Eric Botcazou wrote:

There are a few places in the ranger where we sanity check the types of
the ranges.  We were using types_compatible_p() but thats not really
acccurate as gimple allows types which are useless_type_conversion_p()
in only one direction, whereas types_compatible_p() requires casts in
both directions to be useless_type_conversion_p().

And, since its only a sanity check, ranges really only require that the
precision and sign be the same, so its a faster check anyway.

bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.

The Ada regression comes from this hunk:

diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index c4bfc658319..983f4c97e87 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -552,7 +552,7 @@ is_gimple_logical_p (const gimple *gs)
case BIT_AND_EXPR:
case BIT_IOR_EXPR:
  // Bitwise operations on single bits are logical too.
- if (types_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
+ if (range_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
  boolean_type_node))
return true;
  break;

which overlooks that boolean_type_node may have a precision not equal to 1
(it's 8 in Ada).  See useless_type_conversion_p which has:

   /* Preserve conversions to/from BOOLEAN_TYPE if types are not
 of precision one.  */
   if (((TREE_CODE (inner_type) == BOOLEAN_TYPE)
   != (TREE_CODE (outer_type) == BOOLEAN_TYPE))
  && TYPE_PRECISION (outer_type) != 1)
return false

bah.  And I cant seem to reproduce it on my machine with your 
reproducer, but I am seeing the other result it in my log.    Point is 
still taken tho.
range_compatible_p should only be used during asserts as a sanity check 
for range interactions, not during actual code processing like that.


im currently testing the following, which reverts 2 places (both which 
check for logicals)  to use types_compatible_p instead.  The remaining 
uses are in range assertion code. This seems to resolve the original 
problem in my log.


Thanks for reducing it to the problematic change.  I'm verifying a new 
failure in libgomp isnt a result of this before I check it in.


Andrew




diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 983f4c97e87..5d50b111d2a 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -552,7 +552,7 @@ is_gimple_logical_p (const gimple *gs)
 	case BIT_AND_EXPR:
 	case BIT_IOR_EXPR:
 	  // Bitwise operations on single bits are logical too.
-	  if (range_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
+	  if (types_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
   boolean_type_node))
 	return true;
 	  break;
@@ -1165,7 +1165,7 @@ bool
 logical_stmt_cache::cacheable_p (gimple *stmt, const irange *lhs_range) const
 {
   if (gimple_code (stmt) == GIMPLE_ASSIGN
-  && range_compatible_p (TREE_TYPE (gimple_assign_lhs (stmt)),
+  && types_compatible_p (TREE_TYPE (gimple_assign_lhs (stmt)),
 			 boolean_type_node)
   && TREE_CODE (gimple_assign_rhs1 (stmt)) == SSA_NAME)
 {


Re: [Ada,FYI] revamp ada.numerics.aux

2020-10-22 Thread Eric Botcazou
> So I'm going ahead and checking this in, approved by Eric Botcazou.
> (Rainer's followup patch is coming up separately but momentarily)
> 
> 
> aarch64-* and ppc*-linux-gnu long long float/long double mismatch

Does this fix https://gcc.gnu.org/PR97504 for PowerPC64?  Note that S/390 is 
affected as well according to Stefan.

-- 
Eric Botcazou




[committed 2/2] libstdc++: Only include in if needed

2020-10-22 Thread Jonathan Wakely via Gcc-patches

The  header is not small, so  should
not include it unless it actually needs std::condition_variable, which
is only the case when we don't have pthread_rwlock_t and the POSIX
Timers option.

The  header would be even smaller if we had a header for
std::condition_variable (separate from std::condition_variable_any).
That's already planned for a future change.

And  would be even smaller if it was possible to get
std::shared_mutex without std::shared_timed_mutex (which depends on
). For that to be effective, the synchronized_pool_resource
would have to create its own simpler version of std::shared_lock without
the timed waiting functions. I have no plans to do that.

libstdc++-v3/ChangeLog:

* include/std/shared_mutex: Only include 
when pthread_rwlock_t and POSIX timers are not available.
(__cpp_lib_shared_mutex, __cpp_lib_shared_timed_mutex): Change
value to be type 'long'.
* include/std/version (__cpp_lib_shared_mutex)
(__cpp_lib_shared_timed_mutex): Likewise.


Tested powerpc64le-linux. Committed to trunk.


commit f5d9bc8ae81abe46640477bc9e655aa093947f5f
Author: Jonathan Wakely 
Date:   Thu Oct 22 18:42:03 2020

libstdc++: Only include  in  if needed

The  header is not small, so  should
not include it unless it actually needs std::condition_variable, which
is only the case when we don't have pthread_rwlock_t and the POSIX
Timers option.

The  header would be even smaller if we had a header for
std::condition_variable (separate from std::condition_variable_any).
That's already planned for a future change.

And  would be even smaller if it was possible to get
std::shared_mutex without std::shared_timed_mutex (which depends on
). For that to be effective, the synchronized_pool_resource
would have to create its own simpler version of std::shared_lock without
the timed waiting functions. I have no plans to do that.

libstdc++-v3/ChangeLog:

* include/std/shared_mutex: Only include 
when pthread_rwlock_t and POSIX timers are not available.
(__cpp_lib_shared_mutex, __cpp_lib_shared_timed_mutex): Change
value to be type 'long'.
* include/std/version (__cpp_lib_shared_mutex)
(__cpp_lib_shared_timed_mutex): Likewise.

diff --git a/libstdc++-v3/include/std/shared_mutex b/libstdc++-v3/include/std/shared_mutex
index 414dce3a1b7..7d683a0e0c4 100644
--- a/libstdc++-v3/include/std/shared_mutex
+++ b/libstdc++-v3/include/std/shared_mutex
@@ -33,9 +33,14 @@
 
 #if __cplusplus >= 201402L
 
-#include 
-#include 
+#include 
 #include 
+#include // move, __exchange
+#include// defer_lock_t
+
+#if ! (_GLIBCXX_USE_PTHREAD_RWLOCK_T && _GTHREAD_USE_MUTEX_TIMEDLOCK)
+# include 
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -49,11 +54,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #ifdef _GLIBCXX_HAS_GTHREADS
 
 #if __cplusplus >= 201703L
-#define __cpp_lib_shared_mutex 201505
+#define __cpp_lib_shared_mutex 201505L
   class shared_mutex;
 #endif
 
-#define __cpp_lib_shared_timed_mutex 201402
+#define __cpp_lib_shared_timed_mutex 201402L
   class shared_timed_mutex;
 
   /// @cond undocumented
@@ -399,7 +404,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
   /// @endcond
 
-#if __cplusplus > 201402L
+#if __cplusplus >= 201703L
   /// The standard shared mutex type.
   class shared_mutex
   {
@@ -814,7 +819,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   release() noexcept
   {
 	_M_owns = false;
-	return std::exchange(_M_pm, nullptr);
+	return std::__exchange(_M_pm, nullptr);
   }
 
   // Getters
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 9c16f2c4e70..ebb50a04d24 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -89,7 +89,7 @@
 # define __cpp_lib_quoted_string_io 201304
 # define __cpp_lib_robust_nonmodifying_seq_ops 201304
 # ifdef _GLIBCXX_HAS_GTHREADS
-#  define __cpp_lib_shared_timed_mutex 201402
+#  define __cpp_lib_shared_timed_mutex 201402L
 # endif
 # define __cpp_lib_string_udls 201304
 # define __cpp_lib_transparent_operators 201510
@@ -157,7 +157,7 @@
 #define __cpp_lib_sample 201603
 #ifdef _GLIBCXX_HAS_GTHREADS
 # define __cpp_lib_scoped_lock 201703
-# define __cpp_lib_shared_mutex 201505
+# define __cpp_lib_shared_mutex 201505L
 #endif
 #define __cpp_lib_shared_ptr_weak_type 201606
 #define __cpp_lib_string_view 201803L


[committed 1/2] libstdc++: Reduce header dependencies in and on

2020-10-22 Thread Jonathan Wakely via Gcc-patches
By moving std::make_obj_using_allocator and the related "utility
functions for uses-allocator construction" to a new header, we can avoid
including the whole of  in  and
.

In order to simplify the implementation of those utility functions they
now use concepts unconditionally. They are no longer defined if
__cpp_concepts is not defined. To simplify the code that uses those
functions I've introduced a __cpp_lib_make_obj_using_allocator feature
test macro (not specified in the standard, which might be an oversight).
That allows the code in  and  to
check the feature test macro to decide whether to use the new utilities,
or fall back to the C++17 code.

At the same time, this reshuffles some of the headers included by
 so that they are (mostly?) self-contained. It should no longer
be necessary to include other headers before  when
other parts of the library want to use std::shared_ptr without including
the whole of .

libstdc++-v3/ChangeLog:

* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/shared_ptr.h: Include .
* include/bits/shared_ptr_base.h: Include required headers here
directly, instead of in .
* include/bits/uses_allocator_args.h: New file. Move utility
functions for uses-allocator construction from  to here.
Only define the utility functions when concepts are available.
(__cpp_lib_make_obj_using_allocator): Define non-standard
feature test macro.
* include/std/condition_variable: Remove unused headers.
* include/std/future: Likewise.
* include/std/memory: Remove headers that are not needed
directly, and are now inclkuded where they're needed. Include
new  header.
* include/std/memory_resource: Include only the necessary
headers. Use new feature test macro to detect support for the
utility functions.
* include/std/scoped_allocator: Likewise.
* include/std/version (__cpp_lib_make_obj_using_allocator):
Define.

Tested powerpc64le-linux. Committed to trunk.

commit b1e7c6fce15b8ad222f265df2537701407fd289e
Author: Jonathan Wakely 
Date:   Thu Oct 22 18:42:03 2020

libstdc++: Reduce header dependencies in and on 

By moving std::make_obj_using_allocator and the related "utility
functions for uses-allocator construction" to a new header, we can avoid
including the whole of  in  and
.

In order to simplify the implementation of those utility functions they
now use concepts unconditionally. They are no longer defined if
__cpp_concepts is not defined. To simplify the code that uses those
functions I've introduced a __cpp_lib_make_obj_using_allocator feature
test macro (not specified in the standard, which might be an oversight).
That allows the code in  and  to
check the feature test macro to decide whether to use the new utilities,
or fall back to the C++17 code.

At the same time, this reshuffles some of the headers included by
 so that they are (mostly?) self-contained. It should no longer
be necessary to include other headers before  when
other parts of the library want to use std::shared_ptr without including
the whole of .

libstdc++-v3/ChangeLog:

* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/shared_ptr.h: Include .
* include/bits/shared_ptr_base.h: Include required headers here
directly, instead of in .
* include/bits/uses_allocator_args.h: New file. Move utility
functions for uses-allocator construction from  to here.
Only define the utility functions when concepts are available.
(__cpp_lib_make_obj_using_allocator): Define non-standard
feature test macro.
* include/std/condition_variable: Remove unused headers.
* include/std/future: Likewise.
* include/std/memory: Remove headers that are not needed
directly, and are now inclkuded where they're needed. Include
new  header.
* include/std/memory_resource: Include only the necessary
headers. Use new feature test macro to detect support for the
utility functions.
* include/std/scoped_allocator: Likewise.
* include/std/version (__cpp_lib_make_obj_using_allocator):
Define.

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 28d273924ee..c90ac555e15 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -222,6 +222,7 @@ bits_headers = \
${bits_srcdir}/unordered_map.h \
${bits_srcdir}/unordered_set.h \
${bits_srcdir}/uses_allocator.h \
+   ${bits_srcdir}/uses_allocator_args.h \
${bits_srcdir}/valarray_array.h \
${bits_srcdir}/valarray_array.tcc \

[PATCH/RFC] Add -fdiagnostics-path-format=html

2020-10-22 Thread David Malcolm via Gcc-patches
The patch generalizes diagnostic-show-locus.c so that it can print
HTML, as well as the existing text output.
It uses this to implement a new -fdiagnostics-path-format=html
option, in which diagnostic paths are written out as HTML files
of the form "DUMP_BASE_NAME.path-[0-9]+.html"

For example:

LANG=C ./xgcc -B. -fanalyzer -c test.c -fdiagnostics-path-format=html
test.c: In function 'wrapped_free':
test.c:11:3: warning: double-'free' of 'ptr' [CWE-415] [-Wanalyzer-double-free]
   11 |   free (ptr);
  |   ^~
test.c:11:3: note: path with 23 events written to 'test.c.path-1.html'

which moves the verbose path information from stderr to the HTML file.

I've uploaded the generated HTML for that example to:
  
https://dmalcolm.fedorapeople.org/gcc/2020-10-22/html-examples/test.c.path-1.html
and other examples can be seen in that directory.

The interprocedural calls and returns are visualized in the generated
HTML by using embedded SVG elements to generate arrows.

There is a little JavaScript to allow for using the "j" and "k" keys
to go backwards and forwards through the events in the path.

Currently it merely emits the path information; it doesn't capture the
associated diagnostic; perhaps this should be a diagnostic format option
instead?  As is, the only HTML that's emitted are the paths for
diagnostics that have a path, so any result summarization script that
tries to scrape the build tree looking for HTML files is going to
miss diagnostics without a path.

Also, there are various places that could be improved.  For example,
LTO paths where the filename changes are currently printed rather
plainly:
  
https://dmalcolm.fedorapeople.org/gcc/2020-10-22/html-examples/a.wpa.path-1.html
Help with HTML, JS and CSS would be appreciated.

Tested lightly on Firefox, Chromium, and lynx.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

Thoughts?

gcc/ChangeLog:
* common.opt (diagnostic_path_format): Add DPF_HTML.
* diagnostic-show-locus.c (colorizer::m_context): Replace with...
(colorizer::m_pp): ...this new field.
(layout::m_context): Make const.
(layout::m_is_html): New field.
(layout::m_html_writer): New field.
(colorizer::colorizer): Update for use of pp rather than context.
(colorizer::begin_state): Likewise.
(colorizer::finish_state): Likewise.
(colorizer::get_color_by_name): Likewise.
(layout::layout): Make "context" param const.  Add "pp", "is_html"
and "writer" params, with defaults.  Use them to initialize new
fields.  Update for change to m_colorizer.
(layout::print_source_line): Add HTML support.
(layout::start_annotation_line): Likewise.
(layout::print_annotation_line): Likewise.
(line_label::line_label): Make context const.
(layout::print_any_labels): Add HTML support.
(get_affected_range): Make context const.
(get_printed_columns): Likewise.
(line_corrections::line_corrections): Likewise.
(line_corrections::m_context): Likewise.
(layout::print_line): Don't print fix-it hints for HTML support.
(diagnostic_show_locus_as_html): New.
(class selftest::html_printer): New.
(selftest::assert_html_eq): New.
(ASSERT_HTML_EQ): New.
(selftest::test_one_liner_simple_caret): Verify the HTML output.
(selftest::test_diagnostic_show_locus_fixit_lines): Likewise.
(selftest::test_html): New.
(selftest::diagnostic_show_locus_c_tests): Call it.
* diagnostic.c (diagnostic_show_any_path): Pass the location to
the print_path callback.
* diagnostic.h (enum diagnostic_path_format): Add DPF_HTML.
(diagnostic_context::num_html_paths): New field.
(diagnostic_context::print_path): Add location_t param.
(class html_writer): New.
(diagnostic_show_locus_as_html): New decl.
* doc/invoke.texi (Diagnostic Message Formatting Options): Add
"html" to -fdiagnostics-path-format=.
(-fdiagnostics-path-format=): Add html.
* pretty-print.c (pp_write_text_as_html_to_stream): New.
* pretty-print.h (pp_write_text_as_html_to_stream): New decl.
* tree-diagnostic-path.cc: Define GCC_DIAG_STYLE where possible
and necessary.  Include "options.h" for dump_base_name.
(path_label::path_label): Add "colorize" param and use it to
initialize m_colorize.
(path_label::get_text): Use m_colorizer rather than accessing
global_dc's printer.
(path_label::m_colorize): New field.
(event_range::event_range): Add "colorize" param and use it to
initialize m_path_label.
(event_range::print_as_html): New.
(event_range::get_filename): New.
(path_summary::path_summary): Add "colorize" param and use it when
creating event_ranges.
(class html_path_writer): New.
(path_summary::print_as_html): 

[PATCH] c++: Implement DR2303 [PR97453]

2020-10-22 Thread kamlesh kumar via Gcc-patches
Attaching the patch file.

>>Instead of building a hash table, would it work to handle ambiguity by
>>checking whether one of the classes is a base of the other?
Fixing for cases like: struct B: A,A may not be cleaner this
way.

On Thu, Oct 22, 2020 at 3:23 AM Jason Merrill  wrote:
>
> On 10/21/20 6:32 AM, kamlesh kumar wrote:
> > gcc/cp/ChangeLog
> > ---
> >
> > 2020-10-21  Kamlesh Kumar  
> >
> > PR c++/97453
> > * pt.c (get_template_base): Implement DR2303,
> > Consider closest base while template
> > deduction when base of base also matches.
> >
> > gcc/testsuite/ChangeLog
> > --
> >
> > 2020-10-21  Kamlesh Kumar  
> >
> > * g++.dg/Drs/dr2303.C: New Test
> >
> > --
> >
> > As part of this patch I Implemented fix for below defect report in cwg
> > https://wg21.cmeerw.net/cwg/issue2303 .
>
> Thanks!
>
> Please see https://gcc.gnu.org/contribute.html for guidance on email
> subject lines; for this patch I'd think something like
>
> [PATCH] c++: Implement DR2303 [PR97453]
>
> Also, your patch was corrupted by word wrap; the easiest way to avoid
> that is probably to attach the file rather than copy it into the message.
>
> > Reg tested on x86_64 and did not found any failure.
> > Patch summary: Remove base of base from list of bases
> >
> > created a hash_set from list of bases and then iterate over each
> > element of hash_set and find its  list of bases and remove this from
> > hash_set if present.
> > and finally, deduction succeeds if in hash_set remains only single
> > element or it's empty.
> > otherwise deduction is ambiguous.
>
> Instead of building a hash table, would it work to handle ambiguity by
> checking whether one of the classes is a base of the other?
>
> > ---
> > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> > index dc664ec3798..7adf461e108 100644
> > --- a/gcc/cp/pt.c
> > +++ b/gcc/cp/pt.c
> > @@ -22643,8 +22643,9 @@ static enum template_base_result
> >   get_template_base (tree tparms, tree targs, tree parm, tree arg,
> >   bool explain_p, tree *result)
> >   {
> > -  tree rval = NULL_TREE;
> > +  *result = NULL_TREE;
> > tree binfo;
> > +  hash_set binfo_set;
> >
> > gcc_assert (RECORD_OR_UNION_CODE_P (TREE_CODE (arg)));
> >
> > @@ -22659,31 +22660,51 @@ get_template_base (tree tparms, tree targs,
> > tree parm, tree arg,
> > /* Walk in inheritance graph order.  The search order is not
> >important, and this avoids multiple walks of virtual bases.  */
> > for (binfo = TREE_CHAIN (binfo); binfo; binfo = TREE_CHAIN (binfo))
> > -{
> > -  tree r = try_class_unification (tparms, targs, parm,
> > -   BINFO_TYPE (binfo), explain_p);
> > -
> > -  if (r)
> > - {
> > -   /* If there is more than one satisfactory baseclass, then:
> > -
> > -[temp.deduct.call]
> > + {
> > +   tree r = try_class_unification (tparms, targs, parm,
> > +   BINFO_TYPE (binfo), explain_p);
> > +   if (r)
> > + {
> > +   binfo_set.add(r);
> > + }
> > + }
> >
> > -   If they yield more than one possible deduced A, the type
> > -   deduction fails.
> > +  /* If there is more than one satisfactory baseclass, then:
> > + [temp.deduct.call]
> > +  If they yield more than one possible deduced A, the type
> > +  deduction fails.
> > + However, if there is a class C that is a (direct or indirect)
> > base class of
> > + D and derived (directly or indirectly) from a class B and that
would be a
> > + valid deduced A, the deduced A cannot be B or pointer to B,
> > respectively.  */
> > +  for (hash_set::iterator it = binfo_set.begin();
> > +it != binfo_set.end(); ++it)
> > +{
> > +  binfo = TYPE_BINFO (*it);
> > +  for (binfo = TREE_CHAIN (binfo); binfo; binfo = TREE_CHAIN
(binfo))
> > +{
> > +  tree r = try_class_unification (tparms, targs, parm,
> > +  BINFO_TYPE (binfo), explain_p);
> > +  if (r && binfo_set.contains(r))
> > +{
> > +  binfo_set.remove(r);
> > +}
> > +}
> > +}
> >
> > -  applies.  */
> > -   if (rval && !same_type_p (r, rval))
> > - {
> > -   *result = NULL_TREE;
> > -   return tbr_ambiguous_baseclass;
> > - }
> > +  if (binfo_set.elements() > 1)
> > +{
> > +  return tbr_ambiguous_baseclass;
> > +}
> >
> > -   rval = r;
> > - }
> > +  if (binfo_set.is_empty())
> > +{
> > +  return tbr_success;
> >   }
> >
> > -  *result = rval;
> > +  if (binfo_set.elements() == 1)
> > +{
> > +  *result = *binfo_set.begin();
> > +}
> > return tbr_success;
> >   }
> >
> > diff --git a/gcc/testsuite/g++.dg/DRs/dr2303.C
> > b/gcc/testsuite/g++.dg/DRs/dr2303.C
> > new file mode 100644
> > index 000..b4c23332358
> 

[PATCH] Implement the "retain" attribute

2020-10-22 Thread Jozef Lawrynowicz
Hi,

The attached patch adds support for the new "retain" attribute, which
can be applied to function and variable declarations, to protect them
from linker garbage collection.

Declarations with this attribute will be placed in a new, unique
section, and the ".section" assembler directive that gets output for
that new section will have the "R" flag applied. The "R" flag indicates
to GAS that the SHF_GNU_RETAIN flag should be applied to the section.
SHF_GNU_RETAIN is a GNU OSABI ELF extension.

SHF_GNU_RETAIN was discussed on the GNU gABI mailing list here:
https://sourceware.org/pipermail/gnu-gabi/2020q3/000429.html

The Binutils patch for SHF_GNU_RETAIN was discussed in the following
threads:
https://sourceware.org/pipermail/binutils/2020-September/113406.html
https://sourceware.org/pipermail/binutils/2020-September/113499.html

The latest Binutils patch is posted here:
https://sourceware.org/pipermail/binutils/2020-October/113769.html
It is awaiting final approval, but in the meantime I'm posting the GCC
part of the implementation for review.

Successfully bootstrapped and regtested for x86_64-pc-linux-gnu, and
regtested for arm-none-eabi.

Ok for trunk?

Thanks,
Jozef
>From 82c4f86cde2155dd8b89ba01a2da88761586787b Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Thu, 22 Oct 2020 14:23:40 +0100
Subject: [PATCH] Implement the "retain" attribute

The "retain" attribute is used to protect the function or variable
declaration it is applied to from linker garbage collection.

Declarations with this attribute will be placed in a new, unique
section, and the ".section" assembler directive that gets output for
that new section will have the "R" flag applied. The "R" flag indicates
to GAS that the SHF_GNU_RETAIN flag should be applied to the section.
SHF_GNU_RETAIN is a GNU OSABI ELF extension.

gcc/c-family/ChangeLog:

* c-attribs.c (handle_retain_attribute): New.

gcc/ChangeLog:

* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Define HAVE_GAS_SECTION_RETAIN if the assembler
.section directive supports the "R" flag.
* doc/extend.texi: Document the "retain" function and variable
attribute.
* doc/sourcebuild.texi: Document the "retain" DejaGNU effective target
keyword.
* output.h (SECTION_RETAIN): Define.
(SECTION_MACH_DEP): Adjust value.
* tree-core.h (struct tree_decl_common): Add "retain_flag" member.
* tree.h (DECL_RETAIN_P): New.
* varasm.c (resolve_unique_section): Create unique section for
DECL_RETAIN_P decls.
(default_section_type_flags): Set the SECTION_RETAIN flag for
sections created for DECL_RETAIN_P decls.
(default_elf_asm_named_section): Emit "R" flag in .section directive
for SECTION_RETAIN sections.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_retain): New.
* c-c++-common/attr-retain-1.c: New test.
* c-c++-common/attr-retain-2.c: New test.
* c-c++-common/attr-retain-3.c: New test.
* c-c++-common/attr-retain-main.inc: New test.
---
 gcc/c-family/c-attribs.c  | 42 +++
 gcc/config.in |  6 +++
 gcc/configure | 36 
 gcc/configure.ac  |  9 
 gcc/doc/extend.texi   | 23 ++
 gcc/doc/sourcebuild.texi  |  3 ++
 gcc/output.h  |  3 +-
 gcc/testsuite/c-c++-common/attr-retain-1.c| 19 +
 gcc/testsuite/c-c++-common/attr-retain-2.c| 21 ++
 gcc/testsuite/c-c++-common/attr-retain-3.c| 10 +
 .../c-c++-common/attr-retain-main.inc | 26 
 gcc/testsuite/lib/target-supports.exp |  9 
 gcc/tree-core.h   |  1 +
 gcc/tree.h|  7 
 gcc/varasm.c  |  8 +++-
 15 files changed, 221 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/attr-retain-1.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-retain-2.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-retain-3.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-retain-main.inc

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index a3b2b3d58bd..72c0c61993e 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -155,6 +155,7 @@ static tree handle_designated_init_attribute (tree *, tree, 
tree, int, bool *);
 static tree handle_patchable_function_entry_attribute (tree *, tree, tree,
   int, bool *);
 static tree handle_copy_attribute (tree *, tree, tree, int, bool *);
+static tree handle_retain_attribute (tree *, tree, tree, int, bool *);
 
 /* Helper to define attribute exclusions.  */
 #define ATTR_EXCL(name, function, type, 

Re: [patch] Use precision and sign to compare types for ranges

2020-10-22 Thread Eric Botcazou
> There are a few places in the ranger where we sanity check the types of
> the ranges.  We were using types_compatible_p() but thats not really
> acccurate as gimple allows types which are useless_type_conversion_p()
> in only one direction, whereas types_compatible_p() requires casts in
> both directions to be useless_type_conversion_p().
> 
> And, since its only a sanity check, ranges really only require that the
> precision and sign be the same, so its a faster check anyway.
> 
> bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.

The Ada regression comes from this hunk:

diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index c4bfc658319..983f4c97e87 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -552,7 +552,7 @@ is_gimple_logical_p (const gimple *gs)
case BIT_AND_EXPR:
case BIT_IOR_EXPR:
  // Bitwise operations on single bits are logical too.
- if (types_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
+ if (range_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
  boolean_type_node))
return true;
  break;

which overlooks that boolean_type_node may have a precision not equal to 1 
(it's 8 in Ada).  See useless_type_conversion_p which has:

  /* Preserve conversions to/from BOOLEAN_TYPE if types are not
 of precision one.  */
  if (((TREE_CODE (inner_type) == BOOLEAN_TYPE)
   != (TREE_CODE (outer_type) == BOOLEAN_TYPE))
  && TYPE_PRECISION (outer_type) != 1)
return false

-- 
Eric Botcazou




Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

2020-10-22 Thread Qing Zhao via Gcc-patches



> On Oct 22, 2020, at 10:34 AM, Uros Bizjak  wrote:
> 
> On Thu, Oct 22, 2020 at 4:47 PM Qing Zhao  > wrote:
>> 
>> Hi, Uros,
>> 
>>> On Oct 21, 2020, at 9:45 AM, Qing Zhao via Gcc-patches 
>>>  wrote:
>> 
 
 Something like this:
 
 --cut here--
 long double
 __attribute__ ((noinline))
 test (long double a, long double b)
 {
 long double r = a + b;
 
 asm volatile ("fldz;\
  fldz;\
  fldz;\
  fldz;\
  fldz;\
  fldz;\
  fldz;\
  fstp %%st(0);\
  fstp %%st(0);\
  fstp %%st(0);\
  fstp %%st(0);\
  fstp %%st(0);\
  fstp %%st(0);\
  fstp %%st(0)" : : "X"(r));
 return r;
 }
 
 int
 main ()
 {
 long double a = 1.1, b = 1.2;
 
 long double c = test (a, b);
 
 printf ("%Lf\n", c);
 
 return 0;
 }
 --cut here—
>>> 
>>> 
>>> Okay, so,
>>> 
>>> 1. First compute how many st registers need to be zeroed,  num_of_zeroed_st
>>> 2. Then issue (8 - num_of_zeroed_st) fldz to push 0 to the stack to clear 
>>> all the dead stack slots;
>>> 3. Then issue (8 - num_of_zeroed_st) fstp %st(0) to pop the stack and empty 
>>> the stack.
>>> 
>> 
>> How to generate such asm volatile insn at i386 backend? Is there any code in 
>> i386 backend I can refer for this ?
> 
> fldz is plain move of zero to XF register, fstp is generated from an
> XF move of FIRST_STACK_REG to itself with REG_DEAD note added:
> 
> #(insn 366 128 129 9 (set (reg:XF 8 st)
> #(reg:XF 8 st)) "test.c":711:14 110 {*movxf_internal}
> # (expr_list:REG_DEAD (reg:XF 8 st)
> #(nil)))

What’s the reason to add the “REG_DEAD” note?

Qing
> 
> Uros.



Re: [patch] Use precision and sign to compare types for ranges

2020-10-22 Thread Eric Botcazou
> Just as a heads up ...
> 
> This regresses ACATs  C35507N on at least all X86 Darwin I’ve tried.
> Both 32 and 64Bit hosts fail (not had the chance to test on power darwin
> yet, because that’s got bootstrap issues).

I have attached a reproducer, compile it with

  gnatmake p -O2

and

  gnatmake p -O2 -fno-tree-vrp

to see the regression.

-- 
Eric Botcazouwith Text_IO; use Text_IO;

procedure P is

  type Enum is (A, B);
  for Enum use (A => 4, B => 5);
  Pos : Natural := 0;

begin
  for E in Enum loop
IF Enum'Pos (E) /= Pos THEN
  Put_Line ("There is something wrong");
end if;
Pos := Pos + 1;
  end loop;
end;


Re: [RS6000] Power10 vec-splati-runnable multiple test failures

2020-10-22 Thread Segher Boessenkool
Hi!

On Thu, Oct 22, 2020 at 09:08:58AM -0700, Carl Love wrote:
> On Thu, 2020-10-22 at 17:26 +1030, Alan Modra wrote:
> > FAIL: gcc.target/powerpc/vec-splati-runnable.c 1 blank line(s) in
> > output
> > FAIL: gcc.target/powerpc/vec-splati-runnable.c (test for excess
> > errors)
> > Excess errors:
> > rs6000_emit_xxspltidp_v2df called ...

> > --- a/gcc/config/rs6000/rs6000.c
> > +++ b/gcc/config/rs6000/rs6000.c
> > @@ -27485,11 +27485,10 @@ rs6000_const_f32_to_i32 (rtx operand)
> >  void
> >  rs6000_emit_xxspltidp_v2df (rtx dst, long value)
> >  {
> > -  printf("rs6000_emit_xxspltidp_v2df called %ld\n", value);
> > -  printf("rs6000_emit_xxspltidp_v2df called 0x%lx\n", value);
> >if (((value & 0x7F80) == 0) && ((value & 0x7F) != 0))
> >  inform (input_location,
> > -   "the result for the xxspltidp instruction is undefined for
> > subnormal input values.\n");
> > +   "the result for the xxspltidp instruction "
> > +   "is undefined for subnormal input values");

> I see the error print statement you changed so that it would not wrap. 
> I have always been told it is best not to break the print statement
> across two lines.

It is only broken up in the source code :-)

> The argument is it makes it harder to find it in the
> code when using grep.  In this case, it should be clear what file the
> error statement is in.  What is your take in general about breaking or
> not breaking the body of an error print statement across lines?

Everyone agrees on that (I hope :-) )

The patch is okay for trunk.  Thanks!


Segher


Re: [RS6000] Power10 vec-splati-runnable multiple test failures

2020-10-22 Thread Carl Love via Gcc-patches
On Thu, 2020-10-22 at 17:26 +1030, Alan Modra wrote:
> FAIL: gcc.target/powerpc/vec-splati-runnable.c 1 blank line(s) in
> output
> FAIL: gcc.target/powerpc/vec-splati-runnable.c (test for excess
> errors)
> Excess errors:
> rs6000_emit_xxspltidp_v2df called ...
> 
> and running the test fails.  As the comment says
>   /* Although the instruction says the results are not defined, it
> does seem
>  to work, at least on Mambo.  But no guarentees!  */
> So the simulator works but not real hardware.
> 
> Regstrapped powerpc64le-linux on power10 and power8.  OK?
> 
> gcc/
>   * config/rs6000/rs6000.c (rs6000_emit_xxspltidp_v2df): Delete
>   debug printf.  Remove trailing ".\n" from inform message.
>   Break long line.
> gcc/testsuite/
>   * gcc.target/powerpc/vec-splati-runnable.c: Don't abort on
>   undefined output.
> 
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index c0adc56387f..2f0ca7af030 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -27485,11 +27485,10 @@ rs6000_const_f32_to_i32 (rtx operand)
>  void
>  rs6000_emit_xxspltidp_v2df (rtx dst, long value)
>  {
> -  printf("rs6000_emit_xxspltidp_v2df called %ld\n", value);
> -  printf("rs6000_emit_xxspltidp_v2df called 0x%lx\n", value);
>if (((value & 0x7F80) == 0) && ((value & 0x7F) != 0))
>  inform (input_location,
> - "the result for the xxspltidp instruction is undefined for
> subnormal input values.\n");
> + "the result for the xxspltidp instruction "
> + "is undefined for subnormal input values");
>emit_insn( gen_xxspltidp_v2df_inst (dst, GEN_INT (value)));
>  }
> 
> diff --git a/gcc/testsuite/gcc.target/powerpc/vec-splati-runnable.c
> b/gcc/testsuite/gcc.target/powerpc/vec-splati-runnable.c
> index afb0bfdef3a..e5a4935644f 100644
> --- a/gcc/testsuite/gcc.target/powerpc/vec-splati-runnable.c
> +++ b/gcc/testsuite/gcc.target/powerpc/vec-splati-runnable.c
> @@ -5,7 +5,7 @@
> 
>  #define DEBUG 0
> 
> -#ifdef DEBUG
> +#if DEBUG
>  #include 
>  #endif
> 
> @@ -100,7 +100,7 @@ main (int argc, char *argv [])
>printf(" vresult_d[%i] = %e, expected_vresult_d[%i] = %e\n",
>i, vresult_d[i], i, expected_vresult_d[i]);
>  #else
> -abort();
> +;
>  #endif
>}

Alan:

Yea, the #ifdef should be #if.  

I see the error print statement you changed so that it would not wrap. 
I have always been told it is best not to break the print statement
across two lines.  The argument is it makes it harder to find it in the
code when using grep.  In this case, it should be clear what file the
error statement is in.  What is your take in general about breaking or
not breaking the body of an error print statement across lines?

  Carl 



Re: [RS6000] VSX_MM_SUFFIX

2020-10-22 Thread Segher Boessenkool
On Thu, Oct 22, 2020 at 08:58:10AM -0700, Carl Love wrote:
> OK, looks like VSX_MM_SUFFIX doesn't exist anymore.  Don't know what
> happed to it.  Thanks.

It never existed on trunk.  Please always regstrap patches on trunk
before committing.  It feels unnecessary at times, but now you know
why :-)


Segher


Re: [RS6000] VSX_MM_SUFFIX

2020-10-22 Thread Carl Love via Gcc-patches
On Thu, 2020-10-22 at 17:21 +1030, Alan Modra wrote:
> gcc.target/powerpc/vsx_mask-count-runnable.c and others
> Assembler messages:
> Error: unrecognized opcode: `vcntmb'
> 
> I'm applying this one as obvious.  Ref
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549757.html 
> 
>   * config/rs6000/vsx.md (vec_cntmb_, vec_extract_),
>   (vec_expand_): Replace  with .
> 
> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
> index c023bc0baaa..d96269367bf 100644
> --- a/gcc/config/rs6000/vsx.md
> +++ b/gcc/config/rs6000/vsx.md
> @@ -6035,7 +6035,7 @@
>  (match_operand:QI 2 "const_0_to_1_operand" "n")]
>  UNSPEC_VCNTMB))]
>"TARGET_POWER10"
> -  "vcntmb %0,%1,%2"
> +  "vcntmb %0,%1,%2"
>[(set_attr "type" "vecsimple")])
>  
>  (define_insn "vec_extract_"
> @@ -6043,7 +6043,7 @@
>   (unspec:SI [(match_operand:VSX_MM 1 "altivec_register_operand"
> "v")]
>   UNSPEC_VEXTRACT))]
>"TARGET_POWER10"
> -  "vextractm %0,%1"
> +  "vextractm %0,%1"
>[(set_attr "type" "vecsimple")])
>  
>  (define_insn "vec_expand_"
> @@ -6051,5 +6051,5 @@
>  (unspec:VSX_MM [(match_operand:VSX_MM 1
> "vsx_register_operand" "v")]
>  UNSPEC_VEXPAND))]
>"TARGET_POWER10"
> -  "vexpandm %0,%1"
> +  "vexpandm %0,%1"
>[(set_attr "type" "vecsimple")])
> 

Alan:

OK, looks like VSX_MM_SUFFIX doesn't exist anymore.  Don't know what
happed to it.  Thanks.

Carl 



Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

2020-10-22 Thread Uros Bizjak via Gcc-patches
On Thu, Oct 22, 2020 at 4:47 PM Qing Zhao  wrote:
>
> Hi, Uros,
>
> > On Oct 21, 2020, at 9:45 AM, Qing Zhao via Gcc-patches 
> >  wrote:
> 
> >>
> >> Something like this:
> >>
> >> --cut here--
> >> long double
> >> __attribute__ ((noinline))
> >> test (long double a, long double b)
> >> {
> >> long double r = a + b;
> >>
> >> asm volatile ("fldz;\
> >>   fldz;\
> >>   fldz;\
> >>   fldz;\
> >>   fldz;\
> >>   fldz;\
> >>   fldz;\
> >>   fstp %%st(0);\
> >>   fstp %%st(0);\
> >>   fstp %%st(0);\
> >>   fstp %%st(0);\
> >>   fstp %%st(0);\
> >>   fstp %%st(0);\
> >>   fstp %%st(0)" : : "X"(r));
> >> return r;
> >> }
> >>
> >> int
> >> main ()
> >> {
> >> long double a = 1.1, b = 1.2;
> >>
> >> long double c = test (a, b);
> >>
> >> printf ("%Lf\n", c);
> >>
> >> return 0;
> >> }
> >> --cut here—
> >
> >
> > Okay, so,
> >
> > 1. First compute how many st registers need to be zeroed,  num_of_zeroed_st
> > 2. Then issue (8 - num_of_zeroed_st) fldz to push 0 to the stack to clear 
> > all the dead stack slots;
> > 3. Then issue (8 - num_of_zeroed_st) fstp %st(0) to pop the stack and empty 
> > the stack.
> >
>
> How to generate such asm volatile insn at i386 backend? Is there any code in 
> i386 backend I can refer for this ?

fldz is plain move of zero to XF register, fstp is generated from an
XF move of FIRST_STACK_REG to itself with REG_DEAD note added:

#(insn 366 128 129 9 (set (reg:XF 8 st)
#(reg:XF 8 st)) "test.c":711:14 110 {*movxf_internal}
# (expr_list:REG_DEAD (reg:XF 8 st)
#(nil)))

Uros.


Re: [PATCH] arm: Fix multiple inheritance thunks for thumb-1 with -mpure-code

2020-10-22 Thread Richard Earnshaw via Gcc-patches
On 22/10/2020 09:45, Christophe Lyon via Gcc-patches wrote:
> On Wed, 21 Oct 2020 at 19:36, Richard Earnshaw
>  wrote:
>>
>> On 21/10/2020 17:11, Christophe Lyon via Gcc-patches wrote:
>>> On Wed, 21 Oct 2020 at 18:07, Richard Earnshaw
>>>  wrote:

 On 21/10/2020 16:49, Christophe Lyon via Gcc-patches wrote:
> On Tue, 20 Oct 2020 at 13:25, Richard Earnshaw
>  wrote:
>>
>> On 20/10/2020 12:22, Richard Earnshaw wrote:
>>> On 19/10/2020 17:32, Christophe Lyon via Gcc-patches wrote:
 On Mon, 19 Oct 2020 at 16:39, Richard Earnshaw
  wrote:
>
> On 12/10/2020 08:59, Christophe Lyon via Gcc-patches wrote:
>> On Thu, 8 Oct 2020 at 11:58, Richard Earnshaw
>>  wrote:
>>>
>>> On 08/10/2020 10:07, Christophe Lyon via Gcc-patches wrote:
 On Tue, 6 Oct 2020 at 18:02, Richard Earnshaw
  wrote:
>
> On 29/09/2020 20:50, Christophe Lyon via Gcc-patches wrote:
>> When mi_delta is > 255 and -mpure-code is used, we cannot load 
>> delta
>> from code memory (like we do without -mpure-code).
>>
>> This patch builds the value of mi_delta into r3 with a series of
>> movs/adds/lsls.
>>
>> We also do some cleanup by not emitting the function address and 
>> delta
>> via .word directives at the end of the thunk since we don't use 
>> them
>> with -mpure-code.
>>
>> No need for new testcases, this bug was already identified by
>> eg. pr46287-3.C
>>
>> 2020-09-29  Christophe Lyon  
>>
>>   gcc/
>>   * config/arm/arm.c (arm_thumb1_mi_thunk): Build mi_delta 
>> in r3 and
>>   do not emit function address and delta when -mpure-code is 
>> used.
>
 Hi Richard,

 Thanks for your comments.

> There are some optimizations you can make to this code.
>
> Firstly, for values between 256 and 510 (inclusive), it would be 
> better
> to just expand a mov of 255 followed by an add.
 I now see the splitted for the "Pe" constraint which I hadn't 
 noticed
 before, so I can write something similar indeed.

 However, I'm note quite sure to understand the benefit in the split
 when -mpure-code is NOT used.
 Consider:
 int f3_1 (void) { return 510; }
 int f3_2 (void) { return 511; }
 Compile with -O2 -mcpu=cortex-m0:
 f3_1:
 movsr0, #255
 lslsr0, r0, #1
 bx  lr
 f3_2:
 ldr r0, .L4
 bx  lr

 The splitter makes the code bigger, does it "compensate" for this 
 by
 not having to load the constant?
 Actually the constant uses 4 more bytes, which should be taken into
 account when comparing code size,
>>>
>>> Yes, the size of the literal pool entry needs to be taken into 
>>> account.
>>>  It might happen that the entry could be shared with another use of 
>>> that
>>> literal, but in general that's rare.
>>>
 so f3_1 uses 6 bytes, and f3_2 uses 8, so as you say below three
 thumb1 instructions would be equivalent in size compared to loading
 from the literal pool. Should the 256-510 range be extended?
>>>
>>> It's a bit borderline at three instructions when literal pools are 
>>> not
>>> expensive to use, but in thumb1 literal pools tend to be quite 
>>> small due
>>> to the limited pc offsets we can use.  I think on balance we 
>>> probably
>>> want to use the instruction sequence unless optimizing for size.
>>>


> This is also true for
> the literal pools alternative as well, so should be handled 
> before all
> this.
 I am not sure what you mean: with -mpure-code, the above sample is 
 compiled as:
 f3_1:
 movsr0, #255
 lslsr0, r0, #1
 bx  lr
 f3_2:
 movsr0, #1
 lslsr0, r0, #8
 addsr0, r0, #255
 bx  lr

 so the "return 510" case is already handled as without -mpure-code.
>>>
>>> I was thinking specifically of the thunk sequence where you seem to 
>>> be
>>> emitting instructions directly 

Re: [patch] Use precision and sign to compare types for ranges

2020-10-22 Thread Iain Sandoe

Hi Andrew,

Andrew MacLeod via Gcc-patches  wrote:


This fixes the second test case in pr 97360.

There are a few places in the ranger where we sanity check the types of  
the ranges.  We were using types_compatible_p() but thats not really  
acccurate as gimple allows types which are useless_type_conversion_p() in  
only one direction, whereas types_compatible_p() requires casts in both  
directions to be useless_type_conversion_p().


And, since its only a sanity check, ranges really only require that the  
precision and sign be the same, so its a faster check anyway.


bootstrapped on x86_64-pc-linux-gnu, no regressions, pushed.


Just as a heads up ...

This regresses ACATs  C35507N on at least all X86 Darwin I’ve tried.
Both 32 and 64Bit hosts fail (not had the chance to test on power darwin  
yet, because that’s got bootstrap issues).


The sympom is :

,.,. C35507N ACATS 2.5 20-10-22 02:23:12
 C35507N CHECK THAT THE ATTRIBUTES 'POS' AND 'VAL' YIELD THE CORRECT
RESULTS WHEN THE PREFIX IS A FORMAL DISCRETE TYPE WHOSE
ACTUAL PARAMETER IS A CHARACTER TYPE WITH AN ENUMERATION
REPRESENTATION CLAUSE.
   * C35507N INCORRECT VALUE FOR CHAR'POS OF 'A'.
   * C35507N INCORRECT VALUE FOR CHAR'VAL OF CHARACTER IN POSITION -  1.

The last two lines repeat until the test times out.



... acats are not the easiest to debug :/ .. will try to get something more  
constructive to

put in a PR.

Iain



Re: [PATCH] libstdc++: Apply proposed resolutions for LWG 3428, 3447

2020-10-22 Thread Jonathan Wakely via Gcc-patches

On 22/10/20 11:05 -0400, Patrick Palka via Libstdc++ wrote:

Tested on x86_64-pc-linux-gnu.  Does this look OK for trunk and the 10
branch?


Yes for both, thanks.


libstdc++-v3/ChangeLog:

* include/std/ranges (single_view::single_view): Mark the
in place constructor explicit as per LWG 3428.
(take_view): Remove the constraint on the deduction guide's
template parameter as per LWG 3447.
---
libstdc++-v3/include/std/ranges | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 4d3a4940c6f..a3e5354848a 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -205,9 +205,11 @@ namespace ranges
  : _M_value(std::move(__t))
  { }

+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3428. single_view's in place constructor should be explicit
  template
requires constructible_from<_Tp, _Args...>
-   constexpr
+   constexpr explicit
single_view(in_place_t, _Args&&... __args)
: _M_value{in_place, std::forward<_Args>(__args)...}
{ }
@@ -1801,7 +1803,10 @@ namespace views
  }
};

-  template
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3447. Deduction guides for take_view and drop_view have different
+  // constraints
+  template
take_view(_Range&&, range_difference_t<_Range>)
  -> take_view>;

--
2.29.0.rc0





[PATCH] libstdc++: Apply proposed resolutions for LWG 3428, 3447

2020-10-22 Thread Patrick Palka via Gcc-patches
Tested on x86_64-pc-linux-gnu.  Does this look OK for trunk and the 10
branch?

libstdc++-v3/ChangeLog:

* include/std/ranges (single_view::single_view): Mark the
in place constructor explicit as per LWG 3428.
(take_view): Remove the constraint on the deduction guide's
template parameter as per LWG 3447.
---
 libstdc++-v3/include/std/ranges | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 4d3a4940c6f..a3e5354848a 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -205,9 +205,11 @@ namespace ranges
   : _M_value(std::move(__t))
   { }
 
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3428. single_view's in place constructor should be explicit
   template
requires constructible_from<_Tp, _Args...>
-   constexpr
+   constexpr explicit
single_view(in_place_t, _Args&&... __args)
: _M_value{in_place, std::forward<_Args>(__args)...}
{ }
@@ -1801,7 +1803,10 @@ namespace views
   }
 };
 
-  template
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3447. Deduction guides for take_view and drop_view have different
+  // constraints
+  template
 take_view(_Range&&, range_difference_t<_Range>)
   -> take_view>;
 
-- 
2.29.0.rc0



Re: [patch] OpenMP: Fortran - support omp flush's memorder clauses

2020-10-22 Thread Jakub Jelinek via Gcc-patches
On Thu, Oct 22, 2020 at 04:52:10PM +0200, Tobias Burnus wrote:
> +  else
> +{
> +  enum memmodel mo = MEMMODEL_LAST;
> +  switch (code->ext.omp_clauses->memorder)
> + {
> + case OMP_MEMORDER_ACQ_REL: mo = MEMMODEL_ACQ_REL; break;
> + case OMP_MEMORDER_RELEASE: mo = MEMMODEL_RELEASE; break;
> + case OMP_MEMORDER_ACQUIRE: mo = MEMMODEL_ACQUIRE; break;
> + case OMP_MEMORDER_LAST: gcc_unreachable (); break;

I'd probably use
default: gcc_unreachable (); break;
here instead.
Otherwise LGTM, thanks.

Jakub



[patch] OpenMP: Fortran - support omp flush's memorder clauses

2020-10-22 Thread Tobias Burnus

Add the memorder clause of OpenMP 5 which are already supported by C/C++.

(I copied & adapted the two C/C++ testcases.)

OK?

Tobias

PS: An alternative to creating an additional enum would be to
include memmodel.h in gfortran.h - and use it directly. But at
the end, I decided to copy to follow the current code and
add a new enum – and include it only in trans-openmp.c.

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
OpenMP: Fortran - support omp flush's memorder clauses

gcc/fortran/ChangeLog:

	* gfortran.h (enum gfc_omp_memorder): Add.
	(gfc_omp_clauses): Use it.
	* openmp.c (gfc_match_omp_flush): Match memorder clauses.
	* trans-openmp.c (gfc_trans_omp_flush): Handle them.
	(gfc_trans_omp_directive): Update call.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/flush-1.f90: New test.
	* gfortran.dg/gomp/flush-2.f90: New test.

 gcc/fortran/gfortran.h |  9 +++
 gcc/fortran/openmp.c   | 29 +
 gcc/fortran/trans-openmp.c | 30 +++---
 gcc/testsuite/gfortran.dg/gomp/flush-1.f90 | 41 ++
 gcc/testsuite/gfortran.dg/gomp/flush-2.f90 | 18 +
 5 files changed, 123 insertions(+), 4 deletions(-)

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index d0cea838444..931b908a16e 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1361,6 +1361,14 @@ enum gfc_omp_requires_kind
    | OMP_REQ_ATOMIC_MEM_ORDER_RELAXED)
 };
 
+enum gfc_omp_memorder
+{
+  OMP_MEMORDER_ACQ_REL,
+  OMP_MEMORDER_RELEASE,
+  OMP_MEMORDER_ACQUIRE,
+  OMP_MEMORDER_LAST
+};
+
 typedef struct gfc_omp_clauses
 {
   struct gfc_expr *if_expr;
@@ -1376,6 +1384,7 @@ typedef struct gfc_omp_clauses
   bool inbranch, notinbranch, defaultmap, nogroup;
   bool sched_simd, sched_monotonic, sched_nonmonotonic;
   bool simd, threads, depend_source, order_concurrent;
+  enum gfc_omp_memorder memorder;
   enum gfc_omp_cancel_kind cancel;
   enum gfc_omp_proc_bind_kind proc_bind;
   struct gfc_expr *safelen_expr;
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 1efce33e519..b143ba7454a 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2766,15 +2766,44 @@ match
 gfc_match_omp_flush (void)
 {
   gfc_omp_namelist *list = NULL;
+  gfc_omp_clauses *c = NULL;
+  gfc_gobble_whitespace ();
+  enum gfc_omp_memorder mo = OMP_MEMORDER_LAST;
+  if (gfc_match_omp_eos () == MATCH_NO && gfc_peek_ascii_char () != '(')
+{
+  if (gfc_match ("acq_rel") == MATCH_YES)
+	mo = OMP_MEMORDER_ACQ_REL;
+  else if (gfc_match ("release") == MATCH_YES)
+	mo = OMP_MEMORDER_RELEASE;
+  else if (gfc_match ("acquire") == MATCH_YES)
+	mo = OMP_MEMORDER_ACQUIRE;
+  else
+	{
+	  gfc_error ("Expected AQC_REL, RELEASE, or ACQUIRE at %C");
+	  return MATCH_ERROR;
+	}
+  c = gfc_get_omp_clauses ();
+  c->memorder = mo;
+}
   gfc_match_omp_variable_list (" (", , true);
+  if (list && mo != OMP_MEMORDER_LAST)
+{
+  gfc_error ("List specified together with memory order clause in FLUSH "
+		 "directive at %C");
+  gfc_free_omp_namelist (list);
+  gfc_free_omp_clauses (c);
+  return MATCH_ERROR;
+}
   if (gfc_match_omp_eos () != MATCH_YES)
 {
   gfc_error ("Unexpected junk after $OMP FLUSH statement at %C");
   gfc_free_omp_namelist (list);
+  gfc_free_omp_clauses (c);
   return MATCH_ERROR;
 }
   new_st.op = EXEC_OMP_FLUSH;
   new_st.ext.omp_namelist = list;
+  new_st.ext.omp_clauses = c;
   return MATCH_YES;
 }
 
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 378088a9d04..fdb573f8072 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -38,6 +38,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "gomp-constants.h"
 #include "omp-general.h"
 #include "omp-low.h"
+#include "memmodel.h"  /* For MEMMODEL_ enums.  */
+
 #undef GCC_DIAG_STYLE
 #define GCC_DIAG_STYLE __gcc_tdiag__
 #include "diagnostic-core.h"
@@ -4785,10 +4787,30 @@ gfc_trans_oacc_combined_directive (gfc_code *code)
 }
 
 static tree
-gfc_trans_omp_flush (void)
+gfc_trans_omp_flush (gfc_code *code)
 {
-  tree decl = builtin_decl_explicit (BUILT_IN_SYNC_SYNCHRONIZE);
-  return build_call_expr_loc (input_location, decl, 0);
+  tree call;
+  if (!code->ext.omp_clauses
+  || code->ext.omp_clauses->memorder == OMP_MEMORDER_LAST)
+{
+  call = builtin_decl_explicit (BUILT_IN_SYNC_SYNCHRONIZE);
+  call = build_call_expr_loc (input_location, call, 0);
+}
+  else
+{
+  enum memmodel mo = MEMMODEL_LAST;
+  switch (code->ext.omp_clauses->memorder)
+	{
+	case OMP_MEMORDER_ACQ_REL: mo = MEMMODEL_ACQ_REL; break;
+	case OMP_MEMORDER_RELEASE: mo = MEMMODEL_RELEASE; break;
+	case OMP_MEMORDER_ACQUIRE: mo = MEMMODEL_ACQUIRE; break;
+	case OMP_MEMORDER_LAST: 

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

2020-10-22 Thread Qing Zhao via Gcc-patches
Hi, Uros,

> On Oct 21, 2020, at 9:45 AM, Qing Zhao via Gcc-patches 
>  wrote:
 
>> 
>> Something like this:
>> 
>> --cut here--
>> long double
>> __attribute__ ((noinline))
>> test (long double a, long double b)
>> {
>> long double r = a + b;
>> 
>> asm volatile ("fldz;\
>>   fldz;\
>>   fldz;\
>>   fldz;\
>>   fldz;\
>>   fldz;\
>>   fldz;\
>>   fstp %%st(0);\
>>   fstp %%st(0);\
>>   fstp %%st(0);\
>>   fstp %%st(0);\
>>   fstp %%st(0);\
>>   fstp %%st(0);\
>>   fstp %%st(0)" : : "X"(r));
>> return r;
>> }
>> 
>> int
>> main ()
>> {
>> long double a = 1.1, b = 1.2;
>> 
>> long double c = test (a, b);
>> 
>> printf ("%Lf\n", c);
>> 
>> return 0;
>> }
>> --cut here—
> 
> 
> Okay, so,
> 
> 1. First compute how many st registers need to be zeroed,  num_of_zeroed_st
> 2. Then issue (8 - num_of_zeroed_st) fldz to push 0 to the stack to clear all 
> the dead stack slots;
> 3. Then issue (8 - num_of_zeroed_st) fstp %st(0) to pop the stack and empty 
> the stack.
> 

How to generate such asm volatile insn at i386 backend? Is there any code in 
i386 backend I can refer for this ?

thanks.

Qing

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

2020-10-22 Thread Qing Zhao via Gcc-patches
Hi, Richard,

Could you please check the following documentation change, and let me know any 
suggestions?

Thanks.

Qing
> 
>> +pass parameters. @samp{used-arg} zeros used call-used registers that
>> +pass parameters. @samp{arg} zeros all call-used registers that pass
>> +parameters.  These 3 choices are used for ROP mitigation.
>> +
>> +@samp{used-gpr} zeros call-used general purpose registers
>> +which are used in function.  @samp{all-gpr} zeros all
>> +call-used registers.  @samp{used} zeros call-used registers which
>> +are used in function.  @samp{all} zeros all call-used registers.
>> +These 4 choices are used for preventing information leak through
>> +registers.
> 
> The description for all-gpr doesn't look right.  I think it would
> be easier to describe (and hopefully to follow) if we start with
> the three basic choices: “skip”, “used” and “all”.  Then describe
> how “used” and “all” can be modified by adding “-gpr” to limit the
> clearing to general-purpose registers and “-arg” to limit the
> clearing to argument registers.
> 
> We need to say what “call-used” and “used” mean in this context.
> In particular, “call-used” is also known as “call-clobbered”,
> “caller-saved“ and “volatile”, so it would be good to list those
> as alternatives.  We need to say what “used” registers are.

@item -fzero-call-used-regs=@var{choice}
@opindex fzero-call-used-regs
Zero call-used registers at function return to increase the program
security by either mitigating Return-Oriented Programming (ROP) or
preventing information leak through registers.

A "call-used" register is a register that is clobbered by function calls,
as a result, the caller has to save and restore it before or after a
function call. It is also called as "call-clobbered", "caller-saved", or
"volatile".

In order to satisfy users with different security needs and control the
run-time overhead at the same time,  GCC provides a flexible way to choose
the subset of the call-used registers to be zeroed.

@samp{skip}, which is the default, doesn't zero any call-used registers.
@samp{used} zeros call-used registers which are used in the function. A "used"
register is one whose content has been set or referenced in the function.
@samp{all} zeros all call-used registers.

In addition to the above three basic choices, the register set can be further
limited by adding "-gpr" (i.e., general purpose register), "-arg" (i.e.,
argument register), or both as following:

@samp{used-gpr-arg} zeros used call-used general purpose registers that
pass parameters.
@samp{used-arg} zeros used call-used registers that pass parameters.
@samp{all-gpr-arg} zeros all call-used general purpose registers that pass
parameters.
@samp{all-arg} zeros all call-used registers that pass parameters.
@samp{used-gpr} zeros call-used general purpose registers which are used in the
function.
@samp{all-gpr} zeros all call-used general purpose registers.

Among this list, "used-gpr-arg", "used-arg", "all-gpr-arg", and "all-arg" are
mainly used for ROP mitigation.

You can control this behavior for a specific function by using the function
attribute @code{zero_call_used_regs}.  @xref{Function Attributes}.





Re: [PATCH] LTO: check that make command works

2020-10-22 Thread Jeff Law via Gcc-patches


On 10/22/20 6:56 AM, Martin Liška wrote:
> Hello.
>
> The patch is about checking that make command exists for lto-wrapper.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
>     PR lto/97524
>     * lto-wrapper.c (make_exists): New function.
>     (run_gcc): Use it to check that make is present and working
>     for parallel execution.

OK

jeff




Re: [PATCH 2/8] [RS6000] rs6000_rtx_costs for AND

2020-10-22 Thread Segher Boessenkool
On Thu, Oct 22, 2020 at 08:41:50AM +1030, Alan Modra wrote:
> On Wed, Oct 21, 2020 at 03:29:11PM -0500, Segher Boessenkool wrote:
> > Anyway:
> > 
> > +  || (outer_code == AND
> > +  && rs6000_is_valid_2insn_and (x, mode)))
> > {
> >   *total = COSTS_N_INSNS (1);
> >   return true;
> > 
> > It should return COSTS_N_INSNS (2) for that?
> 
> No, it should not!
> 
>   /* (reg) is costed at zero by rtlanal.c:rtx_cost.  That sets a
>baseline for rtx costs:  If a constant is valid in an insn,
>it is free.  */

Yeah, this keeps tripping me up.

The patch is okay for trunk (as I told you offline).  Thanks!

The regressions are really from existing bad behaviour in expand :-(


Segher


Re: [PATCH] xfail and improve some failing libgomp tests

2020-10-22 Thread Jakub Jelinek via Gcc-patches
On Tue, Oct 06, 2020 at 05:45:31PM +0200, Tom de Vries wrote:
> I've updated the patch accordingly.
> 
> FWIW, I now run into an ICE which looks like PR96680:

With the patch I've posted today to fix up declare variant LTO handling,
Tobias reported the patch still doesn't work, and there are two
reasons for that.
One is that when the base function is marked implicitly as declare target,
we don't mark also implicitly the variants.  I'll need to ask on omp-lang
about details for that, but generally the compiler should do it some way.
The other one is that the way base_delay is written, it will always
call the usleep function, which is undesirable for nvptx.  While the
compiler will replace all direct calls to base_delay to nvptx_delay,
the base_delay definition which calls usleep stays.

The following should work instead (I've tested it without offloading and
Tobias with offloading):

2020-10-22  Jakub Jelinek  
Tom de Vries  

PR testsuite/81690
* testsuite/libgomp.c/usleep.h: New file.
* testsuite/libgomp.c/target-32.c: Include usleep.h.
(main): Use tgt_usleep instead of usleep.
* testsuite/libgomp.c/thread-limit-2.c: Include usleep.h.
(main): Use tgt_usleep instead of usleep.

--- gcc/libgomp/testsuite/libgomp.c/usleep.h.jj 2020-10-22 14:45:14.034196695 
+0200
+++ gcc/libgomp/testsuite/libgomp.c/usleep.h2020-10-22 14:48:05.186719495 
+0200
@@ -0,0 +1,24 @@
+#include 
+
+int
+nvptx_usleep (useconds_t d)
+{
+  /* This function serves as a replacement for usleep in
+ this test case.  It does not even attempt to be functionally
+ equivalent  - we just want some sort of delay. */
+  int i;
+  int N = d * 2000;
+  for (i = 0; i < N; i++)
+asm volatile ("" : : : "memory");
+  return 0;
+}
+
+#pragma omp declare variant (nvptx_usleep) 
match(construct={target},device={arch(nvptx)})
+#pragma omp declare variant (usleep) match(user={condition(1)})
+int
+tgt_usleep (useconds_t d)
+{
+  return 0;
+}
+
+#pragma omp declare target to (nvptx_usleep, tgt_usleep)
--- gcc/libgomp/testsuite/libgomp.c/target-32.c.jj  2020-01-12 
11:54:39.037373820 +0100
+++ gcc/libgomp/testsuite/libgomp.c/target-32.c 2020-10-22 14:46:23.211195456 
+0200
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include "usleep.h"
 
 int main ()
 {
@@ -18,28 +19,28 @@ int main ()
 
 #pragma omp target nowait map(alloc: b) depend(in: d[2]) depend(out: d[3])
 {
-  usleep (1000);
+  tgt_usleep (1000);
   #pragma omp atomic update
   b |= 4;
 }
 
 #pragma omp target nowait map(alloc: b) depend(in: d[2]) depend(out: d[4])
 {
-  usleep (5000);
+  tgt_usleep (5000);
   #pragma omp atomic update
   b |= 1;
 }
 
 #pragma omp target nowait map(alloc: c) depend(in: d[3], d[4]) depend(out: 
d[5])
 {
-  usleep (5000);
+  tgt_usleep (5000);
   #pragma omp atomic update
   c |= 8;
 }
 
 #pragma omp target nowait map(alloc: c) depend(in: d[3], d[4]) depend(out: 
d[6])
 {
-  usleep (1000);
+  tgt_usleep (1000);
   #pragma omp atomic update
   c |= 2;
 }
--- gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c.jj 2020-01-12 
11:54:39.037373820 +0100
+++ gcc/libgomp/testsuite/libgomp.c/thread-limit-2.c2020-10-22 
14:57:31.957516284 +0200
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include "usleep.h"
 
 int
 main ()
@@ -48,7 +49,7 @@ main ()
  v = ++cnt;
  if (v > 6)
abort ();
- usleep (1);
+ tgt_usleep (1);
  #pragma omp atomic
  --cnt;
}


Jakub



[PATCH] LTO: check that make command works

2020-10-22 Thread Martin Liška

Hello.

The patch is about checking that make command exists for lto-wrapper.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

PR lto/97524
* lto-wrapper.c (make_exists): New function.
(run_gcc): Use it to check that make is present and working
for parallel execution.
---
 gcc/lto-wrapper.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 9072a3cc0fe..b2af3caa021 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1334,6 +1334,26 @@ jobserver_active_p (void)
 return JS_PREFIX "cannot access %<" JS_NEEDLE "%> file descriptors";
 }
 
+/* Test that a make command is present and working, return true if so.  */

+
+static bool
+make_exists (void)
+{
+  const char *make = "make";
+  char **make_argv = buildargv (getenv ("MAKE"));
+  if (make_argv)
+make = make_argv[0];
+  const char *make_args[] = {make, "--version", NULL};
+
+  int exit_status = 0;
+  int err = 0;
+  const char *errmsg
+= pex_one (PEX_SEARCH, make_args[0], CONST_CAST (char **, make_args),
+  "make", NULL, NULL, _status, );
+  freeargv (make_argv);
+  return errmsg == NULL && exit_status == 0 && err == 0;
+}
+
 /* Execute gcc. ARGC is the number of arguments. ARGV contains the arguments. 
*/
 
 static void

@@ -1570,6 +1590,10 @@ run_gcc (unsigned argc, char *argv[])
}
 }
 
+  /* We need make working for a parallel execution.  */

+  if (parallel && !make_exists ())
+parallel = 0;
+
   if (!dumppfx)
 {
   if (!linker_output
--
2.28.0



Re: [RS6000] Adjust testcases for power10 instructions

2020-10-22 Thread Alan Modra via Gcc-patches
On Thu, Oct 22, 2020 at 05:33:46PM +1030, Alan Modra wrote:
>   * gcc.dg/pr56727-2.c,
>   * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c,
>   * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c,
>   * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-double.c,
>   * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-float.c,
>   * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-int.c,
>   * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-longlong.c,
>   * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-short.c,
>   * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-char.c,
>   * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-double.c,
>   * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-float.c,
>   * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-int.c,
>   * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-longlong.c,
>   * gcc.target/powerpc/fold-vec-load-vec_vsx_ld-short.c,
>   * gcc.target/powerpc/fold-vec-load-vec_xl-char.c,
>   * gcc.target/powerpc/fold-vec-load-vec_xl-double.c,
>   * gcc.target/powerpc/fold-vec-load-vec_xl-float.c,
>   * gcc.target/powerpc/fold-vec-load-vec_xl-int.c,
>   * gcc.target/powerpc/fold-vec-load-vec_xl-longlong.c,
>   * gcc.target/powerpc/fold-vec-load-vec_xl-short.c,
>   * gcc.target/powerpc/fold-vec-splat-floatdouble.c,
>   * gcc.target/powerpc/fold-vec-splat-longlong.c,
>   * gcc.target/powerpc/fold-vec-st-double.c,
>   * gcc.target/powerpc/fold-vec-st-longlong.c,
>   * gcc.target/powerpc/fold-vec-st-pixel.c,
>   * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-char.c,
>   * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-double.c,
>   * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-float.c,
>   * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-int.c,
>   * gcc.target/powerpc/fold-vec-store-builtin_vec_xst-short.c,
>   * gcc.target/powerpc/fold-vec-store-vec_vsx_st-char.c,
>   * gcc.target/powerpc/fold-vec-store-vec_vsx_st-double.c,
>   * gcc.target/powerpc/fold-vec-store-vec_vsx_st-float.c,
>   * gcc.target/powerpc/fold-vec-store-vec_vsx_st-int.c,
>   * gcc.target/powerpc/fold-vec-store-vec_vsx_st-longlong.c,
>   * gcc.target/powerpc/fold-vec-store-vec_vsx_st-short.c,
>   * gcc.target/powerpc/fold-vec-store-vec_xst-char.c,
>   * gcc.target/powerpc/fold-vec-store-vec_xst-double.c,
>   * gcc.target/powerpc/fold-vec-store-vec_xst-float.c,
>   * gcc.target/powerpc/fold-vec-store-vec_xst-int.c,
>   * gcc.target/powerpc/fold-vec-store-vec_xst-longlong.c,
>   * gcc.target/powerpc/fold-vec-store-vec_xst-short.c,
>   * gcc.target/powerpc/lvsl-lvsr.c,
>   * gcc.target/powerpc/ppc-eq0-1.c,
>   * gcc.target/powerpc/ppc-ne0-1.c,
>   * gcc.target/powerpc/pr86731-fwrapv-longlong.c: Match power10 insns.
>   * gcc.target/powerpc/lvsl-lvsr.c: Avoid file name match.
> 
> Regstrapped powerpc64le-linux power10 and power8.  OK?

Some of these are wrong, sorry.  I need to go over and check them
thoroughly.  Please consider the patch withdrawn.

> diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-st-pixel.c 
> b/gcc/testsuite/gcc.target/powerpc/fold-vec-st-pixel.c
> index 5b95cc73d8d..0a3aaec6d8d 100644
> --- a/gcc/testsuite/gcc.target/powerpc/fold-vec-st-pixel.c
> +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-st-pixel.c
> @@ -19,4 +19,4 @@ testst_cst1 (vector pixel vp1, int i1, vector pixel * vpp)
>   return vec_st(vp1, 12, vpp);
>  }
>  
> -/* { dg-final { scan-assembler-times {\mstvx\M}  2 } } */
> +/* { dg-final { scan-assembler-times {\mstvx\M|\mpstxv\M}  2 } } */

For example, this one.  We don't get two stvx insns here on power10,
as we should, but we do need altivec style addressing (ie. & -16).  So
pstxv should not be a pass.

-- 
Alan Modra
Australia Development Lab, IBM


[PATCH 1/2] GCC: Pass --plugin to AR and RANLIB

2020-10-22 Thread H.J. Lu via Gcc-patches
Detect GCC LTO plugin.  Pass --plugin to AR and RANLIB to support LTO
build.

* Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@
(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
* configure.ac: Include config/gcc-plugin.m4.
AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION.
* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Pass --plugin to AR and
RANLIB if possible.
* Makefile.in: Regenerated.
* configure: Likewise.

config/

* gcc-plugin.m4 (GCC_PLUGIN_OPTION): New.

libiberty/

* Makefile.in (AR): Add @AR_PLUGIN_OPTION@
(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
(configure_deps): Depend on ../config/gcc-plugin.m4.
* aclocal.m4: Include ../config/gcc-plugin.m4.
* configure.ac: AC_SUBST AR_PLUGIN_OPTION and
RANLIB_PLUGIN_OPTION.
* configure: Regenerated.

zlib/

* configure: Regenerated.
---
 Makefile.in|   4 +-
 Makefile.tpl   |   5 +-
 config/gcc-plugin.m4   |  28 ++
 configure  |  37 
 configure.ac   |  13 +++
 libiberty/Makefile.in  |   5 +-
 libiberty/aclocal.m4   |   1 +
 libiberty/configure|  37 
 libiberty/configure.ac |  12 +++
 libtool.m4 |  25 -
 zlib/configure | 206 -
 11 files changed, 363 insertions(+), 10 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index fe34132f9e5..87179f5ac9b 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -387,7 +387,7 @@ MAKEINFOFLAGS = --split-size=500
 # -
 
 AS = @AS@
-AR = @AR@
+AR = @AR@ @AR_PLUGIN_OPTION@
 AR_FLAGS = rc
 CC = @CC@
 CXX = @CXX@
@@ -396,7 +396,7 @@ LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
 OBJDUMP = @OBJDUMP@
-RANLIB = @RANLIB@
+RANLIB = @RANLIB@ @RANLIB_PLUGIN_OPTION@
 READELF = @READELF@
 STRIP = @STRIP@
 WINDRES = @WINDRES@
diff --git a/Makefile.tpl b/Makefile.tpl
index 5b118a8ba4a..a280a1498c0 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -390,7 +390,7 @@ MAKEINFOFLAGS = --split-size=500
 # -
 
 AS = @AS@
-AR = @AR@
+AR = @AR@ @AR_PLUGIN_OPTION@
 AR_FLAGS = rc
 CC = @CC@
 CXX = @CXX@
@@ -399,7 +399,7 @@ LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
 OBJDUMP = @OBJDUMP@
-RANLIB = @RANLIB@
+RANLIB = @RANLIB@ @RANLIB_PLUGIN_OPTION@
 READELF = @READELF@
 STRIP = @STRIP@
 WINDRES = @WINDRES@
@@ -1967,6 +1967,7 @@ AUTOCONF = autoconf
 $(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/config/acx.m4 \
$(srcdir)/config/override.m4 $(srcdir)/config/proginstall.m4 \
$(srcdir)/config/elf.m4 $(srcdir)/config/isl.m4 \
+   $(srcdir)/config/gcc-plugin.m4 \
$(srcdir)/libtool.m4 $(srcdir)/ltoptions.m4 $(srcdir)/ltsugar.m4 \
$(srcdir)/ltversion.m4 $(srcdir)/lt~obsolete.m4
cd $(srcdir) && $(AUTOCONF)
diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
index 8f278719118..c5b72e9a13d 100644
--- a/config/gcc-plugin.m4
+++ b/config/gcc-plugin.m4
@@ -124,3 +124,31 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
  fi
fi
 ])
+
+dnl
+dnl
+dnl GCC_PLUGIN_OPTION
+dnl(SHELL-CODE_HANDLER)
+dnl
+AC_DEFUN([GCC_PLUGIN_OPTION],[dnl
+AC_MSG_CHECKING([for -plugin option])
+
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+plugin_option=
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+if test -n "$plugin_option"; then
+  $1="$plugin_option"
+  AC_MSG_RESULT($plugin_option)
+else
+  AC_MSG_RESULT([no])
+fi
+])
diff --git a/configure b/configure
index 68779feb42b..8b9e7b34fdb 100755
--- a/configure
+++ b/configure
@@ -616,6 +616,8 @@ GFORTRAN_FOR_TARGET
 GCC_FOR_TARGET
 CXX_FOR_TARGET
 CC_FOR_TARGET
+RANLIB_PLUGIN_OPTION
+AR_PLUGIN_OPTION
 READELF
 OBJDUMP
 OBJCOPY
@@ -10007,6 +10009,41 @@ fi
 
 
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -plugin option" >&5
+$as_echo_n "checking for -plugin option... " >&6; }
+
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+plugin_option=
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+if test -n "$plugin_option"; then
+  PLUGIN_OPTION="$plugin_option"
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $plugin_option" >&5
+$as_echo "$plugin_option" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+if test -n "$PLUGIN_OPTION"; then
+  if $AR --help 2>&1 | grep -q "\--plugin"; then
+AR_PLUGIN_OPTION="$PLUGIN_OPTION"
+
+  fi
+  if $RANLIB --help 2>&1 | grep -q 

[PATCH 0/2] GCC/Binutils: Pass --plugin to AR and RANLIB

2020-10-22 Thread H.J. Lu via Gcc-patches
In order to support LTO build in binutils, we need to pass --plugin to
AR and RANLIB.  Add GCC_PLUGIN_OPTION to gcc-plugin.m4 to detect the GCC
plugin name.  Pass the --plugin option to AR and RANLIB.

H.J. Lu (2):
  GCC: Pass --plugin to AR and RANLIB
  Binutils: Pass --plugin to AR and RANLIB

 Makefile.in|   4 +-
 Makefile.tpl   |   5 +-
 bfd/configure  |  27 +-
 config/gcc-plugin.m4   |  28 ++
 configure  |  37 
 configure.ac   |  13 +++
 gas/configure  |  27 +-
 gprof/configure|  27 +-
 ld/configure   |  27 +-
 libctf/configure   |  27 +-
 libiberty/Makefile.in  |   5 +-
 libiberty/aclocal.m4   |   1 +
 libiberty/configure|  37 
 libiberty/configure.ac |  12 +++
 libtool.m4 |  25 -
 opcodes/configure  |  27 +-
 zlib/configure | 206 -
 17 files changed, 513 insertions(+), 22 deletions(-)

-- 
2.26.2



[PATCH 2/2] Binutils: Pass --plugin to AR and RANLIB

2020-10-22 Thread H.J. Lu via Gcc-patches
Detect GCC LTO plugin.  Pass --plugin to AR and RANLIB to support LTO
build.

bfd/

* configure: Regenerated.

gas/

* configure: Regenerated.

gprof/

* configure: Regenerated.

ld/

* configure: Regenerated.

libctf/

* configure: Regenerated.

opcodes/

* configure: Regenerated.
---
 bfd/configure | 27 +--
 gas/configure | 27 +--
 gprof/configure   | 27 +--
 ld/configure  | 27 +--
 libctf/configure  | 27 +--
 opcodes/configure | 27 +--
 6 files changed, 150 insertions(+), 12 deletions(-)

diff --git a/bfd/configure b/bfd/configure
index 5d84aed069d..12f4c88782c 100755
--- a/bfd/configure
+++ b/bfd/configure
@@ -6824,6 +6824,19 @@ test -z "$deplibs_check_method" && 
deplibs_check_method=unknown
 
 
 
+plugin_option=
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+
 if test -n "$ac_tool_prefix"; then
   # Extract the first word of "${ac_tool_prefix}ar", so it can be a program 
name with args.
 set dummy ${ac_tool_prefix}ar; ac_word=$2
@@ -6917,6 +6930,11 @@ else
 fi
 
 test -z "$AR" && AR=ar
+if test -n "$plugin_option"; then
+  if $AR --help 2>&1 | grep -q "\--plugin"; then
+AR="$AR $plugin_option"
+  fi
+fi
 test -z "$AR_FLAGS" && AR_FLAGS=cru
 
 
@@ -7121,6 +7139,11 @@ else
 fi
 
 test -z "$RANLIB" && RANLIB=:
+if test -n "$plugin_option" && test "$RANLIB" != ":"; then
+  if $RANLIB --help 2>&1 | grep -q "\--plugin"; then
+RANLIB="$RANLIB $plugin_option"
+  fi
+fi
 
 
 
@@ -11729,7 +11752,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11732 "configure"
+#line 11755 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11835,7 +11858,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11838 "configure"
+#line 11861 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/gas/configure b/gas/configure
index 813ed93f14c..ac64b617dcb 100755
--- a/gas/configure
+++ b/gas/configure
@@ -6408,6 +6408,19 @@ test -z "$deplibs_check_method" && 
deplibs_check_method=unknown
 
 
 
+plugin_option=
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+
 if test -n "$ac_tool_prefix"; then
   # Extract the first word of "${ac_tool_prefix}ar", so it can be a program 
name with args.
 set dummy ${ac_tool_prefix}ar; ac_word=$2
@@ -6501,6 +6514,11 @@ else
 fi
 
 test -z "$AR" && AR=ar
+if test -n "$plugin_option"; then
+  if $AR --help 2>&1 | grep -q "\--plugin"; then
+AR="$AR $plugin_option"
+  fi
+fi
 test -z "$AR_FLAGS" && AR_FLAGS=cru
 
 
@@ -6705,6 +6723,11 @@ else
 fi
 
 test -z "$RANLIB" && RANLIB=:
+if test -n "$plugin_option" && test "$RANLIB" != ":"; then
+  if $RANLIB --help 2>&1 | grep -q "\--plugin"; then
+RANLIB="$RANLIB $plugin_option"
+  fi
+fi
 
 
 
@@ -11344,7 +11367,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11347 "configure"
+#line 11370 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11450,7 +11473,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11453 "configure"
+#line 11476 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/gprof/configure b/gprof/configure
index 74d22db79b6..72ef1b2a373 100755
--- a/gprof/configure
+++ b/gprof/configure
@@ -6255,6 +6255,19 @@ test -z "$deplibs_check_method" && 
deplibs_check_method=unknown
 
 
 
+plugin_option=
+plugin_names="liblto_plugin.so liblto_plugin-0.dll cyglto_plugin-0.dll"
+for plugin in $plugin_names; do
+  plugin_so=`${CC} ${CFLAGS} --print-prog-name $plugin`
+  if test x$plugin_so = x$plugin; then
+plugin_so=`${CC} ${CFLAGS} --print-file-name $plugin`
+  fi
+  if test x$plugin_so != x$plugin; then
+plugin_option="--plugin $plugin_so"
+break
+  fi
+done
+
 if test -n "$ac_tool_prefix"; then
   # Extract the first word of "${ac_tool_prefix}ar", so it can be a program 
name with args.
 set dummy ${ac_tool_prefix}ar; ac_word=$2
@@ -6348,6 +6361,11 @@ else
 fi
 
 test -z "$AR" && AR=ar
+if test -n 

Re: [PATCH] LTO: get_section: add new argument

2020-10-22 Thread Martin Liška

On 10/22/20 1:42 PM, Martin Jambor wrote:

...is that I think this should be internal_error.  I am not sure what
difference it makes in practice, if any, though.


You are right, using internal_error is a better approach.

Martin
>From e6ab47df74113e7eae3160d5f9c2f7a7e724feb1 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 21 Oct 2020 11:11:03 +0200
Subject: [PATCH] LTO: get_section: add new argument

gcc/ChangeLog:

	PR lto/97508
	* langhooks.c (lhd_begin_section): Call get_section with
	not_existing = true.
	* output.h (get_section): Add new argument.
	* varasm.c (get_section): Fail when NOT_EXISTING is true
	and a section already exists.
	* ipa-cp.c (ipcp_write_summary): Remove.
	(ipcp_read_summary): Likewise.
	* ipa-fnsummary.c (ipa_fn_summary_read): Always read jump
	functions summary.
	(ipa_fn_summary_write): Always stream it.
---
 gcc/ipa-cp.c| 20 ++--
 gcc/ipa-fnsummary.c |  6 ++
 gcc/langhooks.c |  2 +-
 gcc/output.h|  3 ++-
 gcc/varasm.c|  9 +++--
 5 files changed, 14 insertions(+), 26 deletions(-)

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 2152f9e5876..db87329bc0c 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -5943,22 +5943,6 @@ ipcp_generate_summary (void)
 ipa_analyze_node (node);
 }
 
-/* Write ipcp summary for nodes in SET.  */
-
-static void
-ipcp_write_summary (void)
-{
-  ipa_prop_write_jump_functions ();
-}
-
-/* Read ipcp summary.  */
-
-static void
-ipcp_read_summary (void)
-{
-  ipa_prop_read_jump_functions ();
-}
-
 namespace {
 
 const pass_data pass_data_ipa_cp =
@@ -5980,8 +5964,8 @@ public:
   pass_ipa_cp (gcc::context *ctxt)
 : ipa_opt_pass_d (pass_data_ipa_cp, ctxt,
 		  ipcp_generate_summary, /* generate_summary */
-		  ipcp_write_summary, /* write_summary */
-		  ipcp_read_summary, /* read_summary */
+		  NULL, /* write_summary */
+		  NULL, /* read_summary */
 		  ipcp_write_transformation_summaries, /*
 		  write_optimization_summary */
 		  ipcp_read_transformation_summaries, /*
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index 9e3eda4d3cb..6479a03f2c6 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -4466,6 +4466,7 @@ ipa_fn_summary_read (void)
   struct lto_file_decl_data *file_data;
   unsigned int j = 0;
 
+  ipa_prop_read_jump_functions ();
   ipa_fn_summary_alloc ();
 
   while ((file_data = file_data_vec[j++]))
@@ -4484,8 +4485,6 @@ ipa_fn_summary_read (void)
 		 "ipa inline summary is missing in input file");
 }
   ipa_register_cgraph_hooks ();
-  if (!flag_ipa_cp)
-ipa_prop_read_jump_functions ();
 
   gcc_assert (ipa_fn_summaries);
   ipa_fn_summaries->enable_insertion_hook ();
@@ -4628,8 +4627,7 @@ ipa_fn_summary_write (void)
   produce_asm (ob, NULL);
   destroy_output_block (ob);
 
-  if (!flag_ipa_cp)
-ipa_prop_write_jump_functions ();
+  ipa_prop_write_jump_functions ();
 }
 
 
diff --git a/gcc/langhooks.c b/gcc/langhooks.c
index 8819a8859d4..d82f54251fd 100644
--- a/gcc/langhooks.c
+++ b/gcc/langhooks.c
@@ -790,7 +790,7 @@ lhd_begin_section (const char *name)
 saved_section = text_section;
 
   /* Create a new section and switch to it.  */
-  section = get_section (name, SECTION_DEBUG | SECTION_EXCLUDE, NULL);
+  section = get_section (name, SECTION_DEBUG | SECTION_EXCLUDE, NULL, true);
   switch_to_section (section);
 }
 
diff --git a/gcc/output.h b/gcc/output.h
index eb253c50329..2f2f1697fd8 100644
--- a/gcc/output.h
+++ b/gcc/output.h
@@ -523,7 +523,8 @@ extern GTY(()) bool in_cold_section_p;
 
 extern section *get_unnamed_section (unsigned int, void (*) (const void *),
  const void *);
-extern section *get_section (const char *, unsigned int, tree);
+extern section *get_section (const char *, unsigned int, tree,
+			 bool not_existing = false);
 extern section *get_named_section (tree, const char *, int);
 extern section *get_variable_section (tree, bool);
 extern void place_block_symbol (rtx);
diff --git a/gcc/varasm.c b/gcc/varasm.c
index ea0b59cf44a..435c7b348a5 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -277,10 +277,12 @@ get_noswitch_section (unsigned int flags, noswitch_section_callback callback)
 }
 
 /* Return the named section structure associated with NAME.  Create
-   a new section with the given fields if no such structure exists.  */
+   a new section with the given fields if no such structure exists.
+   When NOT_EXISTING, then fail if the section already exists.  */
 
 section *
-get_section (const char *name, unsigned int flags, tree decl)
+get_section (const char *name, unsigned int flags, tree decl,
+	 bool not_existing)
 {
   section *sect, **slot;
 
@@ -297,6 +299,9 @@ get_section (const char *name, unsigned int flags, tree decl)
 }
   else
 {
+  if (not_existing)
+	internal_error ("Section already exists: %qs", name);
+
   sect = *slot;
   /* It is fine if one of the sections has SECTION_NOTYPE as long as
  the other has none of the 

[Ada] Enable the support of 128-bit integer types by default

2020-10-22 Thread Pierre-Marie de Rodat
This enables the support of 128-bit integer types by default on 64-bit
platforms (except for BB ports): the -gnate128 switch is removed and
the debug switch -gnatd.H can now be used to disable again the support.

Technically speaking, apart from the obvious effect on integer types,
this will bump the size of the type representing Universal_Integer in
the compiler to 128 bits, which means that the attributes returning UI
will be properly range-checked when assigned e.g. to a 64-bit variable.

This will also bump the bit-packing limit from 64 to 128 bits, which
means that components up to 128 instead of 64 bits can be bit-packed
in array or record types subject to aspect/pragma Pack.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* Makefile.rtl (GNATRTL_128BIT_PAIRS): Add i-cexten.ads.
* debug.adb (d.H): Document new usage.
* doc/gnat_rm/representation_clauses_and_pragmas.rst (Size Clauses):
Document new limit on 64-bit platforms.
(Component_Size Clauses): Likewise.
(Pragma Pack for Arrays): Likewise.
(Pragma Pack for Records): Likewise.
(Record Representation Clauses): Likewise.
* gnat_rm.texi: Regenerate.
* gnat1drv.adb (Adjust_Global_Switches): Rewrite code enabling or
disabling the support for 128-bit integer types.
* switch-c.adb (Scan_Front_End_Switches): Do not deal with e128.
* usage.adb (Write_Switch_Char): Do not print -gnate128 switch.
* libgnat/i-cexten__128.ads: New file.

gcc/testsuite/

* ada/acats/run_all.sh: Define and substitute target_{max,min}_int.
* ada/acats/support/macro.dfs: Parameterize {MAX,MIN}_INT.
* gnat.dg/assert1.adb: Adjust conditionally to 128-bit integer types.
* gnat.dg/size_clause1.adb: Do not expect a warning for LP64 targets.
* gnat.dg/warn11.adb: Likewise.
* gnat.dg/specs/rep_clause5.ads (Array_2_Type): Add alignment clause.

patch.diff.gz
Description: application/gzip


[Ada] AI12-0211: Consistency of inherited nonoverridable aspects

2020-10-22 Thread Pierre-Marie de Rodat
AI12-0211 introduces two new legality rules. The first says that if a
nonoverridable aspect is explicitly specified for a type which also
inherits that aspect from another type (an ancestor or a progenitor),
then the explicit aspect specification shall be confirming. The second
says that if a type inherits a nonoverridable aspect from two different
sources (this can only occur if at least one of the two is an interface
type), then the two sources shall agree with respect to the given
aspect. Implement these new legality checks. This AI is a binding
interpretation, so these checks are performed even for pre-Ada202x Ada
versions.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* aspects.ads: Introduce the subtype Nonoverridable_Aspect_Id,
whose Static_Predicate reflects the list of nonoverridable
aspects given in Ada RM 13.1.1(18.7).
* sem_util.ads, sem_util.adb: Add two new visible subprograms,
Check_Inherited_Nonoverridable_Aspects and Is_Confirming. The
former is used to check the consistency of inherited
nonoverridable aspects from multiple sources. The latter
indicates whether two aspect specifications for a nonoverridable
aspect are confirming. Because of compatibility concerns in
compiling QGen, Is_Confirming always returns True if
Relaxed_RM_Semantics (i.e., -gnatd.M) is specified.
* sem_ch3.adb (Derived_Type_Declaration): Call new
Check_Inherited_Nonoverridable_Aspects procedure if interface
list is non-empty.
* sem_ch9.adb (Check_Interfaces): Call new
Check_Inherited_Nonoverridable_Aspects procedure if interface
list is non-empty.
* sem_ch13.adb (Analyze_Aspect_Specifications): When an explicit
aspect specification overrides an inherited nonoverridable
aspect, check that the explicit specification is confirming.diff --git a/gcc/ada/aspects.ads b/gcc/ada/aspects.ads
--- a/gcc/ada/aspects.ads
+++ b/gcc/ada/aspects.ads
@@ -229,6 +229,16 @@ package Aspects is
  Aspect_Id range Aspect_Id'Succ (No_Aspect) .. Aspect_Id'Last;
--  Aspect_Id's excluding No_Aspect
 
+   subtype Nonoverridable_Aspect_Id is Aspect_Id with
+ Static_Predicate => Nonoverridable_Aspect_Id in
+   Aspect_Default_Iterator | Aspect_Iterator_Element |
+   Aspect_Implicit_Dereference | Aspect_Constant_Indexing |
+   Aspect_Variable_Indexing | Aspect_Aggregate |
+   Aspect_Max_Entry_Queue_Length
+   --  | Aspect_No_Controlled_Parts
+   --  ??? No_Controlled_Parts not yet in Aspect_Id enumeration
+   ;  --  see RM 13.1.1(18.7)
+
--  The following array indicates aspects that accept 'Class
 
Class_Aspect_OK : constant array (Aspect_Id) of Boolean :=


diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -4159,7 +4159,7 @@ package body Sem_Ch13 is
when Aspect_Aggregate =>
   Validate_Aspect_Aggregate (Expr);
   Record_Rep_Item (E, Aspect);
-  return;
+  goto Continue;
 
when Aspect_Integer_Literal
   | Aspect_Real_Literal
@@ -4751,9 +4751,39 @@ package body Sem_Ch13 is
Insert_After (Ins_Node, Aitem);
Ins_Node := Aitem;
 end if;
+
+<>
+
+--  If a nonoverridable aspect is explicitly specified for a
+--  derived type, then check consistency with the parent type.
+
+if A_Id in Nonoverridable_Aspect_Id
+  and then Nkind (N) = N_Full_Type_Declaration
+  and then Nkind (Type_Definition (N)) = N_Derived_Type_Definition
+  and then not In_Instance_Body
+then
+   declare
+  Parent_Type  : constant Entity_Id := Etype (E);
+  Inherited_Aspect : constant Node_Id :=
+Find_Aspect (Parent_Type, A_Id);
+   begin
+  if Present (Inherited_Aspect)
+and then not Is_Confirming
+   (A_Id, Inherited_Aspect, Aspect)
+  then
+ Error_Msg_Name_1 := Aspect_Names (A_Id);
+ Error_Msg_Sloc := Sloc (Inherited_Aspect);
+
+ Error_Msg
+   ("overriding aspect specification for "
+  & "nonoverridable aspect % does not confirm "
+  & "aspect specification inherited from #",
+Sloc (Aspect));
+  end if;
+   end;
+end if;
  end Analyze_One_Aspect;
 
-  <>
  Next (Aspect);
   end loop Aspect_Loop;
 


diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -16754,6 +16754,14 @@ package body Sem_Ch3 is
Next (Intf);
   

[Ada] Update the head comment of Check_Compile_Time_Size

2020-10-22 Thread Pierre-Marie de Rodat
In order to reflect that the size limit is System_Max_Integer_Size now.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* freeze.ads (Check_Compile_Time_Size): Adjust size limit.diff --git a/gcc/ada/freeze.ads b/gcc/ada/freeze.ads
--- a/gcc/ada/freeze.ads
+++ b/gcc/ada/freeze.ads
@@ -152,15 +152,15 @@ package Freeze is
--occur.
--
--Size is known at compile time, but the actual value of the size is not
-   --known to the front end or is definitely greater than 64. In this case,
-   --Size_Known_At_Compile_Time is set, but the RM_Size field is left set
-   --to zero (to be set by Gigi).
+   --known to the front end or is greater than System_Max_Integer_Size. In
+   --this case, Size_Known_At_Compile_Time is set, but the RM_Size field is
+   --left set to zero (to be set by Gigi).
--
--Size is known at compile time, and the actual value of the size is
-   --known to the front end and is not greater than 64. In this case, the
-   --flag Size_Known_At_Compile_Time is set, and in addition RM_Size is set
-   --to the required size, allowing for possible front end packing of an
-   --array using this type as a component type.
+   --known to the front end and not greater than System_Max_Integer_Size.
+   --In this case, Size_Known_At_Compile_Time is set, and in addition the
+   --RM_Size field is set to the required size, allowing for possible front
+   --end packing of an array using this type as a component type.
--
--  Note: the flag Size_Known_At_Compile_Time is used to determine if the
--  secondary stack must be used to return a value of the type, and also




[Ada] Build support units for 128-bit integer types on 64-bit platforms

2020-10-22 Thread Pierre-Marie de Rodat
This enables the build of the support units for 128-bit integer types
in the full runtime of 64-bit platforms.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* Makefile.rtl (64-bit platforms): Add GNATRTL_128BIT_PAIRS to
the LIBGNAT_TARGET_PAIRS list and also GNATRTL_128BIT_OBJS to
the EXTRA_GNATRTL_NONTASKING_OBJS list.diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
--- a/gcc/ada/Makefile.rtl
+++ b/gcc/ada/Makefile.rtl
@@ -1060,6 +1060,11 @@ ifeq ($(strip $(filter-out powerpc% wrs vxworks vxworksspe vxworks7% vxworks7spe
 EXTRA_GNATRTL_NONTASKING_OBJS+=s-stchop.o
   endif
 
+  ifeq ($(strip $(filter-out powerpc64, $(target_cpu))),)
+LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS)
+EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS)
+  endif
+
   TOOLS_TARGET_PAIRS=indepsw.adb

[Ada] CUDA: discover runtime types instead of hard-coding

2020-10-22 Thread Pierre-Marie de Rodat
The CUDA bindings change very frequently, sometimes changing the
underlying representation of types. In order to reduce the amount of
work needed in the compiler on each CUDA update, we make GNAT infer the
types it needs instead of hard-coding them.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_prag.adb (Get_Launch_Kernel_Arg_Type): New function.
(Build_Shared_Memory_Declaration): Use
Get_Launch_Kernel_Arg_Type.
(Build_Stream_Declaration): Use Get_Launch_Kernel_Arg_Type.
* rtsfind.ads: Remove RO_IC_Unsigned_Long_Long.diff --git a/gcc/ada/exp_prag.adb b/gcc/ada/exp_prag.adb
--- a/gcc/ada/exp_prag.adb
+++ b/gcc/ada/exp_prag.adb
@@ -748,6 +748,10 @@ package body Exp_Prag is
   --  type of which is Integer, the value of which is Init_Val if present
   --  and 0 otherwise.
 
+  function Get_Launch_Kernel_Arg_Type (N : Positive) return Entity_Id;
+  --  Returns the type of the Nth argument of the Launch_Kernel CUDA
+  --  runtime function.
+
   function To_Addresses (Elmts : Elist_Id) return List_Id;
   --  Returns a new list containing each element of Elmts wrapped in an
   --  'address attribute reference. When passed No_Elist, returns an empty
@@ -910,7 +914,7 @@ package body Exp_Prag is
(Decl_Id => Decl_Id,
 Init_Val=> Init_Val,
 Typ =>
-  New_Occurrence_Of (RTE (RO_IC_Unsigned_Long_Long), Loc),
+  New_Occurrence_Of (Get_Launch_Kernel_Arg_Type (5), Loc),
 Default_Val => Make_Integer_Literal (Loc, 0));
   end Build_Shared_Memory_Declaration;
 
@@ -948,10 +952,25 @@ package body Exp_Prag is
  return Build_Simple_Declaration_With_Default
(Decl_Id => Decl_Id,
 Init_Val=> Init_Val,
-Typ => New_Occurrence_Of (RTE (RE_Stream_T), Loc),
+Typ =>
+  New_Occurrence_Of (Get_Launch_Kernel_Arg_Type (6), Loc),
 Default_Val => Make_Null (Loc));
   end Build_Stream_Declaration;
 
+  
+  -- Get_Launch_Kernel_Arg_Type --
+  
+
+  function Get_Launch_Kernel_Arg_Type (N : Positive) return Entity_Id is
+ Argument : Entity_Id := First_Entity (RTE (RE_Launch_Kernel));
+  begin
+ for J in 2 .. N loop
+Argument := Next_Entity (Argument);
+ end loop;
+
+ return Etype (Argument);
+  end Get_Launch_Kernel_Arg_Type;
+
   --
   -- To_Addresses --
   --


diff --git a/gcc/ada/rtsfind.ads b/gcc/ada/rtsfind.ads
--- a/gcc/ada/rtsfind.ads
+++ b/gcc/ada/rtsfind.ads
@@ -731,7 +731,6 @@ package Rtsfind is
  RE_Unsigned_128,-- Interfaces
 
  RO_IC_Unsigned, -- Interfaces.C
- RO_IC_Unsigned_Long_Long,   -- Interfaces.C
 
  RE_Chars_Ptr,   -- Interfaces.C.Strings
  RE_New_Char_Array,  -- Interfaces.C.Strings
@@ -2380,7 +2379,6 @@ package Rtsfind is
  RE_Unsigned_128 => Interfaces,
 
  RO_IC_Unsigned  => Interfaces_C,
- RO_IC_Unsigned_Long_Long=> Interfaces_C,
 
  RE_Chars_Ptr=> Interfaces_C_Strings,
  RE_New_Char_Array   => Interfaces_C_Strings,




[Ada] Wrong accessibility for conversion to named access

2020-10-22 Thread Pierre-Marie de Rodat
This patch fixes an error in the compiler whereby the accessibility
level for explicit type conversions from an anonymous access object to a
named access type led to spurious runtime accessibility errors.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_util.adb (Accessibility_Level_Helper): Conversions to
named access types get the level associated with the named
access type.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -751,6 +751,13 @@ package body Sem_Util is
 then
return Accessibility_Level_Helper (Expression (E), Static);
 
+--  We don't care about the master if we are looking at a named
+--  access type.
+
+elsif Is_Named_Access_Type (Etype (E)) then
+   return Make_Level_Literal
+(Type_Access_Level (Etype (E)));
+
 --  In section RM 3.10.2 (10/4) the accessibility rules for
 --  aggregates and value conversions are outlined. Are these
 --  followed in the case of initialization of an object ???




[Ada] AI12-0095 Formal types and Constrained Partial Views

2020-10-22 Thread Pierre-Marie de Rodat
AI12-0095 is a binding interpretation that revises the RM to have a
general rule about how generic formal discriminated types are considered
to have a constrained partial view within generic bodies, rather than
just have this rule appear in the sections of the RM on Access
attributes and type conversions, so that rule now also applies on the
rules for passing aliased parameters. GNAT was already implementing this
interpretation properly for parameters in generic bodies, but it was
noticed that a case involving Access in the spec of a generic unit was
not properly enforced in instantiations. If an Access attribute is
applied in a generic spec to a constrained aliased object of a formal
type with discriminants and in an instantiation the actual type has a
constrained partial view, then the Access attribute should be rejected
in the instantiation (assuming the access type in the generic has the
formal type as a designated subtype, with no constraint imposed). The
compiler was applying the function Has_Constrained_Partial_View to the
subtype that is created to rename the actual rather than to that
subtype's base type, so got a result of False rather than True. That
function is changed to apply Base_Type to its formal. Another fix is for
the case of a call with an aliased parameter of such a formal type that
occurs in a generic spec, which was incorrectly being flagged as
illegal, when it should be allowed in the generic spec and only rejected
in an instance (when the actual has a constrained partial view).

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* einfo.adb (Has_Constrained_Partial_View): Apply Base_Type to Id.
* sem_res.adb (Resolve_Actuals.Check_Aliased_Parameter): Remove
"not Is_Generic_Type" test and call
Object_Type_Has_Constrained_Partial_View instead of
Has_Constrained_Partial_View. Improve related error message to
say "does not statically match" instead of just "does not
match".diff --git a/gcc/ada/einfo.adb b/gcc/ada/einfo.adb
--- a/gcc/ada/einfo.adb
+++ b/gcc/ada/einfo.adb
@@ -1523,7 +1523,7 @@ package body Einfo is
function Has_Constrained_Partial_View (Id : E) return B is
begin
   pragma Assert (Is_Type (Id));
-  return Flag187 (Id);
+  return Flag187 (Base_Type (Id));
end Has_Constrained_Partial_View;
 
function Has_Controlled_Component (Id : E) return B is


diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.adb
@@ -3479,13 +3479,13 @@ package body Sem_Res is
 
elsif Has_Discriminants (F_Typ)
  and then not Is_Constrained (F_Typ)
- and then not Has_Constrained_Partial_View (F_Typ)
- and then not Is_Generic_Type (F_Typ)
+ and then not Object_Type_Has_Constrained_Partial_View
+(Typ => F_Typ, Scop => Current_Scope)
then
   null;
 
else
-  Error_Msg_NE ("untagged actual does not match "
+  Error_Msg_NE ("untagged actual does not statically match "
 & "aliased formal&", A, F);
end if;
 




[Ada] Ada_2020 AI12-0250: Iterator filters in Iterated_Element_Assocations

2020-10-22 Thread Pierre-Marie de Rodat
Iterator filters can appear in loop parameter specifications and
in iterator specifications, and thus in Iterated_Element_Awsociations
in container aggregates. This patch extend the parsing and expansion
of Iterated associations, to better distinguish the Ada_2020 construct
from the Ada_2012 Iterated_Component_Association.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* par-ch4.adb (P_Iterated_Component_Association): If the
construct includes an iterator filter it corresponds to an
Iterated_Element_Association, so build the proper node for it.
* exp_aggr.adb (Expand_Container_Aggregate, Aggregate_Size): If
the component is an Iterated_Element_Association, treat it as
having a non-static size.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -6954,6 +6954,16 @@ package body Exp_Aggr is
 
  if Present (Component_Associations (N)) then
 Comp := First (Component_Associations (N));
+
+--  If the component is an Iterated_Element_Association
+--  it includes an iterator or a loop parameter, possibly
+--  with a filter, so we do not attempt to compute its
+--  size. Room for future optimization ???
+
+if Nkind (Comp) = N_Iterated_Element_Association then
+   return -1;
+end if;
+
 while Present (Comp) loop
Choice := First (Choice_List (Comp));
 


diff --git a/gcc/ada/par-ch4.adb b/gcc/ada/par-ch4.adb
--- a/gcc/ada/par-ch4.adb
+++ b/gcc/ada/par-ch4.adb
@@ -3421,11 +3421,37 @@ package body Ch4 is
function P_Iterated_Component_Association return Node_Id is
   Assoc_Node : Node_Id;
   Choice : Node_Id;
+  Filter : Node_Id := Empty;
   Id : Node_Id;
   Iter_Spec  : Node_Id;
   Loop_Spec  : Node_Id;
   State  : Saved_Scan_State;
 
+  procedure Build_Iterated_Element_Association;
+  --  If the iterator includes a key expression or a filter, it is
+  --  an Ada_2020 Iterator_Element_Association within a container
+  --  aggregate.
+
+  
+  -- Build_Iterated_Element_Association --
+  
+
+  procedure Build_Iterated_Element_Association is
+  begin
+ Choice :=  First (Discrete_Choices (Assoc_Node));
+ Assoc_Node :=
+   New_Node (N_Iterated_Element_Association, Prev_Token_Ptr);
+ Set_Loop_Parameter_Specification (Assoc_Node, Loop_Spec);
+
+ if Present (Next (Choice)) then
+Error_Msg_N ("expect loop parameter specification", Choice);
+ end if;
+
+ Remove (Choice);
+ Set_Discrete_Subtype_Definition (Loop_Spec, Choice);
+ Set_Iterator_Filter (Loop_Spec, Filter);
+  end Build_Iterated_Element_Association;
+
--  Start of processing for P_Iterated_Component_Association
 
begin
@@ -3443,6 +3469,8 @@ package body Ch4 is
   --  In addition, if "use" is present after the specification,
   --  this is an Iterated_Element_Association that carries a
   --  key_expression, and we generate the appropriate node.
+  --  Finally, the Iterated_Element form is reserved for contwiner
+  --  aggregates, and is illegal in array aggregates.
 
   Id := P_Defining_Identifier;
   Assoc_Node :=
@@ -3453,29 +3481,34 @@ package body Ch4 is
  T_In;
  Set_Discrete_Choices (Assoc_Node, P_Discrete_Choice_List);
 
+ --  The iterator may include a filter.
+
+ if Token = Tok_When then
+Scan;-- past WHEN
+Filter := P_Condition;
+ end if;
+
+ --  Build loop_parameter specification.
+
+ Loop_Spec :=
+   New_Node (N_Loop_Parameter_Specification, Prev_Token_Ptr);
+ Set_Defining_Identifier (Loop_Spec, Id);
+
  if Token = Tok_Use then
 
 --  Ada_2020 Key-expression is present, rewrite node as an
 --  iterated_Element_Awwoiation.
 
 Scan;  --  past USE
-Loop_Spec :=
-  New_Node (N_Loop_Parameter_Specification, Prev_Token_Ptr);
-Set_Defining_Identifier (Loop_Spec, Id);
-
-Choice :=  First (Discrete_Choices (Assoc_Node));
-
-if Present (Next (Choice)) then
-   Error_Msg_N ("expect loop parameter specification", Choice);
-end if;
+Build_Iterated_Element_Association;
+Set_Key_Expression (Assoc_Node, P_Expression);
 
-Remove (Choice);
-Set_Discrete_Subtype_Definition (Loop_Spec, Choice);
+ elsif Present (Filter) then
+--  A loop_Parameter_Specification also indicates an Ada_2020
+--  conwtruct, in contrast with a subtype indication used in
+--  array aggregates.
 
-Assoc_Node :=
-  New_Node 

[Ada] Reimplementation of accessibility checking

2020-10-22 Thread Pierre-Marie de Rodat
This patch removes much of the logic relating to static and dynamic
accessibility level checks and replaces it with a simplified and
centralized implementation.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* checks.adb (Apply_Accessibility_Check): Modify condition to
avoid flawed optimization and use Get_Accessibility over
Extra_Accessibility.
* exp_attr.adb: Remove inclusion of Exp_Ch2.adb.
* exp_ch2.adb, exp_ch2.ads (Param_Entity): Moved to sem_util.
* exp_ch3.ads (Init_Proc_Level_Formal): New function.
* exp_ch3.adb (Build_Init_Procedure): Add extra accessibility
formal for init procs when the associated type is a limited
record.
(Build_Initialization_Call): Add condition to handle propagation
of the new extra accessibility paramter actual needed for init
procs.
(Init_Proc_Level_Formal): Created to fetch a the extra
accessibility parameter associated with init procs if one
exists.
* exp_ch4.adb (Build_Attribute_Reference): Modify static check
to be dynamic.
* exp_ch6.adb (Add_Cond_Expression_Extra_Actual): Move logic
used to expand conditional expressions used as actuals for
anonymous access formals.
(Expand_Call_Helper): Remove extranious accessibility
calculation logic.
* exp_util.adb: Remove inclusion of Exp_Ch2.adb.
* par-ch3.adb (P_Array_Type_Definition): Properly set
Aliased_Present on access definitions
* sem_attr.adb (Resolve_Attribute): Replace instances for
Object_Access_Level with Static_Accessibility_Level.
* sem_ch13.adb (Storage_Pool): Replace instances for
Object_Access_Level with Static_Accessibility_Level.
* sem_ch6.adb (Check_Return_Construct_Accessibility): Replace
instances for Object_Access_Level with
Static_Accessibility_Level.
* sem_ch9.adb (Analyze_Requeue): Replace instances for
Object_Access_Level with Static_Accessibility_Level.
* sem_res.adb (Check_Aliased_Parameter,
Check_Allocator_Discrim_Accessibility, Valid_Conversion):
Replace instances for Object_Access_Level with
Static_Accessibility_Level.
* sem_util.adb, sem_util.ads (Accessibility_Level_Helper):
Created to centralize calculation of accessibility levels.
(Build_Component_Subtype): Replace instances for
Object_Access_Level with Static_Accessibility_Level.
(Defining_Entity): Add extra parameter to dictate whether an
error is raised or empty is return in the case of an irrelevant
N.
(Dynamic_Accessibility_Level): Rewritten to use
Accessibility_Level_Helper.
(Is_View_Conversion): Check membership against Etype to capture
nodes like explicit dereferences which have types but are not
expanded names or identifers.
(Object_Access_LeveL): Removed.
(Param_Entity): Moved from sem_util.
(Static_Accessibility_Level): Created as a replacement to
Object_Access_Level, it also uses Accessibility_Level_Helper for
its implementation.
* snames.ads-tmpl: Added new name for extra accessibility
parameter in init procs.

patch.diff.gz
Description: application/gzip


[Ada] Get rid of useless if-then-else in Exp_Fixd.Fpt_Value

2020-10-22 Thread Pierre-Marie de Rodat
The two arms of the conditional construct have been the same for 25 years.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_fixd.adb (Fpt_Value): Fold if-then-else with identical arms.diff --git a/gcc/ada/exp_fixd.adb b/gcc/ada/exp_fixd.adb
--- a/gcc/ada/exp_fixd.adb
+++ b/gcc/ada/exp_fixd.adb
@@ -186,7 +186,7 @@ package body Exp_Fixd is
--  Given an operand of fixed-point operation, return an expression that
--  represents the corresponding Universal_Real value. The expression
--  can be of integer type, floating-point type, or fixed-point type.
-   --  The expression returned is neither analyzed and resolved. The Etype
+   --  The expression returned is neither analyzed nor resolved. The Etype
--  of the result is properly set (to Universal_Real).
 
function Integer_Literal
@@ -2351,19 +2351,8 @@ package body Exp_Fixd is
---
 
function Fpt_Value (N : Node_Id) return Node_Id is
-  Typ   : constant Entity_Id  := Etype (N);
-
begin
-  if Is_Integer_Type (Typ)
-or else Is_Floating_Point_Type (Typ)
-  then
- return Build_Conversion (N, Universal_Real, N);
-
-  --  Fixed-point case, must get integer value first
-
-  else
- return Build_Conversion (N, Universal_Real, N);
-  end if;
+  return Build_Conversion (N, Universal_Real, N);
end Fpt_Value;
 
-




[Ada] Fix parser not detecting casing issues in keywords

2020-10-22 Thread Pierre-Marie de Rodat
Casing issues are not detected when using `-gnaty` if the keyword does
not start with a capital letter. This is fixed by checking if any letter
in the keywoard is uppercase.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* scng.adb (Scan): Check if any letter of the token is
uppercase.diff --git a/gcc/ada/scng.adb b/gcc/ada/scng.adb
--- a/gcc/ada/scng.adb
+++ b/gcc/ada/scng.adb
@@ -1180,6 +1180,8 @@ package body Scng is
  end if;
   end Start_Of_Wide_Character;
 
+  Token_Contains_Uppercase : Boolean;
+
--  Start of processing for Scan
 
begin
@@ -1241,6 +1243,8 @@ package body Scng is
 
  Token_Ptr := Scan_Ptr;
 
+ Token_Contains_Uppercase := False;
+
  --  Here begins the main case statement which transfers control on the
  --  basis of the non-blank character we have encountered.
 
@@ -1999,6 +2003,7 @@ package body Scng is
  --  Upper case letters
 
  when 'A' .. 'Z' =>
+Token_Contains_Uppercase := True;
 Name_Len := 1;
 Underline_Found := False;
 Name_Buffer (1) :=
@@ -2347,6 +2352,8 @@ package body Scng is
Accumulate_Checksum (Source (Scan_Ptr));
 
 elsif Source (Scan_Ptr) in 'A' .. 'Z' then
+   Token_Contains_Uppercase := True;
+
Name_Buffer (Name_Len + 1) :=
  Character'Val (Character'Pos (Source (Scan_Ptr)) + 32);
Accumulate_Checksum (Name_Buffer (Name_Len + 1));
@@ -2601,7 +2608,7 @@ package body Scng is
--  Ada 2005 (AI-340): Do not apply the style check in case of
--  MOD attribute.
 
-   if Source (Token_Ptr) <= 'Z'
+   if Token_Contains_Uppercase
  and then (Prev_Token /= Tok_Apostrophe
or else
  (Token /= Tok_Access and then




[Ada] Adjust documentation for Has_Constrained_Partial_View flag

2020-10-22 Thread Pierre-Marie de Rodat
This documents that the Has_Constrained_Partial_View flag now explicitly
applies to the base type only.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* einfo.ads (Has_Constrained_Partial_View): Add "base type" marker.diff --git a/gcc/ada/einfo.ads b/gcc/ada/einfo.ads
--- a/gcc/ada/einfo.ads
+++ b/gcc/ada/einfo.ads
@@ -1576,7 +1576,7 @@ package Einfo is
 --   Defined for the given type. Note that this flag can be False even
 --   if Component_Size is non-zero (happens in the case of derived types).
 
---Has_Constrained_Partial_View (Flag187)
+--Has_Constrained_Partial_View (Flag187) [base type only]
 --   Defined in private type and their completions, when the private
 --   type has no discriminants and the full view has discriminants with
 --   defaults. In Ada 2005 heap-allocated objects of such types are not




[Ada] Implement AI12-0280's interactions with container aggregates

2020-10-22 Thread Pierre-Marie de Rodat
AI12-0280 has already been mostly implemented, but some interactions
with container aggregates were not initially implemented.  In
particular, RM 6.1.1's mention of "the expression of a
container_element_association" in the definition of the term "repeatedly
evaluated" needs to be reflected in the function Is_Repeatedly_Evaluated
in sem_util.adb .

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_util.adb (Is_Container_Aggregate): A new local predicates
which indicates whether a given expression is a container
aggregate. The implementation of this function is incomplete; in
the unusual case of a record aggregate (i.e., not a container
aggregate) of a type whose Aggregate aspect is specified, the
function will incorrectly return True.
(Immediate_Context_Implies_Is_Potentially_Unevaluated): Improve
handling of aggregate components.
(Is_Repeatedly_Evaluated): Test for container aggregate
components along with existing test for array aggregate
components.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -134,6 +134,9 @@ package body Sem_Util is
--  Determine whether arbitrary entity Id denotes an atomic object as per
--  RM C.6(7).
 
+   function Is_Container_Aggregate (Exp : Node_Id) return Boolean;
+   --  Is the given expression a container aggregate?
+
generic
   with function Is_Effectively_Volatile_Entity
 (Id : Entity_Id) return Boolean;
@@ -12360,6 +12363,27 @@ package body Sem_Util is
(Directly_Designated_Type (Etype (Formal))) = E;
end Is_Access_Subprogram_Wrapper;
 
+   
+   -- Is_Container_Aggregate --
+   
+
+   function Is_Container_Aggregate (Exp : Node_Id) return Boolean is
+
+  function Is_Record_Aggregate return Boolean is (False);
+  --  ??? Unimplemented. Given an aggregate whose type is a
+  --  record type with specified Aggregate aspect, how do we
+  --  determine whether it is a record aggregate or a container
+  --  aggregate? If the code where the aggregate occurs can see only
+  --  a partial view of the aggregate's type then the aggregate
+  --  cannot be a record type; an aggregate of a private type has to
+  --  be a container aggregate.
+
+   begin
+  return Nkind (Exp) = N_Aggregate
+and then Present (Find_Aspect (Etype (Exp), Aspect_Aggregate))
+and then not Is_Record_Aggregate;
+   end Is_Container_Aggregate;
+
-
-- Side_Effect_Free_Statements --
-
@@ -18406,6 +18430,7 @@ package body Sem_Util is
   is
  Par : constant Node_Id := Parent (Expr);
 
+ function Aggregate_Type return Node_Id is (Etype (Parent (Par)));
   begin
  if Nkind (Par) = N_If_Expression then
 return Is_Elsif (Par) or else Expr /= First (Expressions (Par));
@@ -18433,55 +18458,69 @@ package body Sem_Util is
  elsif Nkind (Par) = N_Quantified_Expression then
 return Expr = Condition (Par);
 
- elsif Nkind (Par) = N_Aggregate
-   and then Present (Etype (Par))
-   and then Etype (Par) /= Any_Composite
-   and then Is_Array_Type (Etype (Par))
-   and then Nkind (Expr) = N_Component_Association
+ elsif Nkind (Par) = N_Component_Association
+   and then Expr = Expression (Par)
+   and then Nkind (Parent (Par))
+  in N_Aggregate | N_Delta_Aggregate | N_Extension_Aggregate
+   and then Present (Aggregate_Type)
+   and then Aggregate_Type /= Any_Composite
  then
-declare
-   Choice   : Node_Id;
-   In_Others_Choice : Boolean := False;
-
-begin
-   --  The expression of an array_component_association is
-   --  potentially unevaluated if the associated choice is a
-   --  subtype_indication or range that defines a nonstatic or
-   --  null range.
+if Is_Array_Type (Aggregate_Type) then
+   if Ada_Version >= Ada_2020 then
+  --  For Ada_2020, this predicate returns True for
+  --  any "repeatedly evaluated" expression.
+  return True;
+   end if;
 
-   Choice := First (Choices (Expr));
-   while Present (Choice) loop
-  if Nkind (Choice) = N_Range
-and then Non_Static_Or_Null_Range (Choice)
-  then
- return True;
+   declare
+  Choice   : Node_Id;
+  In_Others_Choice : Boolean := False;
+  Array_Agg: constant Node_Id := Parent (Par);
+   begin
+  --  The expression of an 

[Ada] Implement AI12-0030: Stream attribute availability

2020-10-22 Thread Pierre-Marie de Rodat
An attempt to reference a streaming attribute of a type that has no
corresponding attribute definition is typically rejected at compile
time.  For example, if a task type T lacks a user-defined Read
attribute, then a reference to T'Read is illegal. However, obscure ways
to bypass these legality rules have been possible since the introduction
of formal derived types in Ada95. The dynamic semantics of such
constructs were not previously defined - this AI (which is a binding
interpretation) plugs this definitional hole by stating that
Program_Error is raised.

In addition, an example given in the AI includes a construct which has
been illegal since Ada95 but which the GNAT compiler accepts. This
bug is also fixed as part of these changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_util.ads, sem_util.adb: Declare and implement a new
predicate, Derivation_Too_Early_To_Inherit.  This function
indicates whether a given derived type fails to inherit a given
streaming-related attribute from its parent type because the
declaration of the derived type precedes the corresponding
attribute_definition_clause of the parent.
* exp_tss.adb (Find_Inherited_TSS): Call
Derivation_Too_Early_To_Inherit instead of unconditionally
assuming that a parent type's streaming attribute is available
for inheritance by an immediate descendant type.
* sem_attr.adb (Stream_Attribute_Available): Call
Derivation_Too_Early_To_Inherit instead of unconditionally
assuming that a parent type's streaming attribute is available
for inheritance by an immediate descendant type.
* exp_attr.adb (Default_Streaming_Unavailable): A new predicate;
given a type, indicates whether predefined (as opposed to
user-defined) streaming operations for the type should be
implemented by raising Program_Error.
(Expand_N_Attribute_Reference): For each of the 4
streaming-related attributes (i.e., Read, Write, Input, Output),
after determining that no user-defined implementation is
available (including a Stream_Convert pragma), call
Default_Streaming_Unavailable; if that call returns True, then
implement the streaming operation as "raise Program_Error;".diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -136,6 +136,12 @@ package body Exp_Attr is
--  special-case code that shuffles partial and full views in the middle
--  of semantic analysis and expansion.
 
+   function Default_Streaming_Unavailable (Typ : Entity_Id) return Boolean;
+   --
+   --  In most cases, references to unavailable streaming attributes
+   --  are rejected at compile time. In some obscure cases involving
+   --  generics and formal derived types, the problem is dealt with at runtime.
+
procedure Expand_Access_To_Protected_Op
  (N: Node_Id;
   Pref : Node_Id;
@@ -927,6 +933,24 @@ package body Exp_Attr is
end Compile_Stream_Body_In_Scope;
 
---
+   -- Default_Streaming_Unavailable --
+   ---
+
+   function Default_Streaming_Unavailable (Typ : Entity_Id) return Boolean is
+  Btyp : constant Entity_Id := Implementation_Base_Type (Typ);
+   begin
+  if Is_Immutably_Limited_Type (Btyp)
+and then not Is_Tagged_Type (Btyp)
+and then not (Ekind (Btyp) = E_Record_Type
+  and then Present (Corresponding_Concurrent_Type (Btyp)))
+  then
+ pragma Assert (In_Instance_Body);
+ return True;
+  end if;
+  return False;
+   end Default_Streaming_Unavailable;
+
+   ---
-- Expand_Access_To_Protected_Op --
---
 
@@ -3954,6 +3978,18 @@ package body Exp_Attr is
Analyze_And_Resolve (N, B_Type);
return;
 
+--  Limited types
+
+elsif Default_Streaming_Unavailable (U_Type) then
+   --  Do the same thing here as is done above in the
+   --  case where a No_Streams restriction is active.
+
+   Rewrite (N,
+ Make_Raise_Program_Error (Sloc (N),
+   Reason => PE_Stream_Operation_Not_Allowed));
+   Set_Etype (N, B_Type);
+   return;
+
 --  Elementary types
 
 elsif Is_Elementary_Type (U_Type) then
@@ -5074,6 +5110,18 @@ package body Exp_Attr is
Analyze (N);
return;
 
+--  Limited types
+
+elsif Default_Streaming_Unavailable (U_Type) then
+   --  Do the same thing here as is done above in the
+   --  case where a No_Streams restriction is active.
+
+   Rewrite (N,
+ Make_Raise_Program_Error (Sloc (N),
+   Reason => 

[Ada] Fix oversight in Eval_Attribute for Bit_Position

2020-10-22 Thread Pierre-Marie de Rodat
The code would correctly distinguish the entity from the selected
component case but not use the result of the analysis in the latter
case.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_attr.adb (Eval_Attribute): Fix oversight for Bit_Position.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -7914,7 +7914,7 @@ package body Sem_Attr is
 
if Known_Static_Component_Bit_Offset (CE) then
   Compile_Time_Known_Attribute
-(N, Component_Bit_Offset (Entity (P)));
+(N, Component_Bit_Offset (CE));
else
   Check_Expressions;
end if;




[Ada] AI12-0307: uniform resolution rules for aggregates

2020-10-22 Thread Pierre-Marie de Rodat
The resolution rules for container aggregates can lead to ambiguities
when homonym subprograms have a formal of a composite type, and the
actual in a call is an aggregate. This patch adds an indication that
this aggregate should be qualified to remove the ambiguity.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_util.ads, sem_util.adb (Check_Ambiguous_Aggregate): When a
subprogram call is found to be ambiguous, check whether
ambiguity is caused by an aggregate actual.  and indicate that
it should carry a type qualification.
* sem_ch4.adb (Traverse_Hoonyms, Try_Primitive_Operation): Call
it.
* sem_res.adb (Report_Ambiguous_Argument): Call it.diff --git a/gcc/ada/sem_ch4.adb b/gcc/ada/sem_ch4.adb
--- a/gcc/ada/sem_ch4.adb
+++ b/gcc/ada/sem_ch4.adb
@@ -9339,6 +9339,7 @@ package body Sem_Ch4 is
 Error_Msg_NE ("ambiguous call to&", N, Hom);
 Report_Ambiguity (Matching_Op);
 Report_Ambiguity (Hom);
+Check_Ambiguous_Aggregate (New_Call_Node);
 Error := True;
 return;
  end if;
@@ -9961,6 +9962,7 @@ package body Sem_Ch4 is
  Error_Msg_NE ("ambiguous call to&", N, Prim_Op);
  Report_Ambiguity (Matching_Op);
  Report_Ambiguity (Prim_Op);
+ Check_Ambiguous_Aggregate (Call_Node);
  return True;
   end if;
end if;


diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.adb
@@ -2097,7 +2097,8 @@ package body Sem_Res is
  then
 Error_Msg_NE ("ambiguous call to&", Arg, Name (Arg));
 
---  Could use comments on what is going on here???
+--  Examine possible interpretations, and adapt the message
+--  for inherited subprograms declared by a type derivation.
 
 Get_First_Interp (Name (Arg), I, It);
 while Present (It.Nam) loop
@@ -2112,6 +2113,11 @@ package body Sem_Res is
Get_Next_Interp (I, It);
 end loop;
  end if;
+
+ --  Additional message and hint if the ambiguity involves an Ada2020
+ --  container aggregate.
+
+ Check_Ambiguous_Aggregate (N);
   end Report_Ambiguous_Argument;
 
   ---


diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -2425,6 +2425,27 @@ package body Sem_Util is
   end if;
end Cannot_Raise_Constraint_Error;
 
+   ---
+   -- Check_Ambiguous_Aggregate --
+   ---
+
+   procedure Check_Ambiguous_Aggregate (Call : Node_Id) is
+  Actual : Node_Id;
+
+   begin
+  if Extensions_Allowed then
+ Actual := First_Actual (Call);
+ while Present (Actual) loop
+if Nkind (Actual) = N_Aggregate then
+   Error_Msg_N
+ ("\add type qualification to aggregate actual", Actual);
+   exit;
+end if;
+Next_Actual (Actual);
+ end loop;
+  end if;
+   end Check_Ambiguous_Aggregate;
+
-
-- Check_Dynamically_Tagged_Expression --
-


diff --git a/gcc/ada/sem_util.ads b/gcc/ada/sem_util.ads
--- a/gcc/ada/sem_util.ads
+++ b/gcc/ada/sem_util.ads
@@ -349,6 +349,13 @@ package Sem_Util is
--  not necessarily mean that CE could be raised, but a response of True
--  means that for sure CE cannot be raised.
 
+   procedure Check_Ambiguous_Aggregate (Call : Node_Id);
+   --  Additional information on an ambiguous call in Ada_2020 when a
+   --  subprogram call has an actual that is an aggregate, and the
+   --  presence of container aggregates (or types with the correwponding
+   --  aspect)  provides an additional interpretation. Message indicates
+   --  that an aggregate actual should carry a type qualification.
+
procedure Check_Dynamically_Tagged_Expression
  (Expr: Node_Id;
   Typ : Entity_Id;




[Ada] Reduce scope of local variables for detecting extra WITH clauses

2020-10-22 Thread Pierre-Marie de Rodat
Reduce visibility of variables in procedure Check_Unused_Withs by moving
them to a nested procedure Check_One_Unit. Code cleanup; semantics is
unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_warn.adb (Check_Unused_Withs): Move local variables from
to a nested procedure; Lunit is passed as a parameter to
Check_System_Aux and its type is refined from Node_Id to
Entity_Id; Cnode is now a constant.diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -2254,10 +2254,6 @@ package body Sem_Warn is

 
procedure Check_Unused_Withs (Spec_Unit : Unit_Number_Type := No_Unit) is
-  Cnode : Node_Id;
-  Item  : Node_Id;
-  Lunit : Node_Id;
-  Ent   : Entity_Id;
 
   Munite : constant Entity_Id := Cunit_Entity (Main_Unit);
   --  This is needed for checking the special renaming case
@@ -2270,8 +2266,9 @@ package body Sem_Warn is
   
 
   procedure Check_One_Unit (Unit : Unit_Number_Type) is
+ Cnode : constant Node_Id := Cunit (Unit);
+
  Is_Visible_Renaming : Boolean := False;
- Pack: Entity_Id;
 
  procedure Check_Inner_Package (Pack : Entity_Id);
  --  Pack is a package local to a unit in a with_clause. Both the unit
@@ -2279,7 +2276,7 @@ package body Sem_Warn is
  --  referenced, then the only occurrence of Pack is in a USE clause
  --  or a pragma, and a warning is worthwhile as well.
 
- function Check_System_Aux return Boolean;
+ function Check_System_Aux (Lunit : Entity_Id) return Boolean;
  --  Before giving a warning on a with_clause for System, check whether
  --  a system extension is present.
 
@@ -2358,7 +2355,7 @@ package body Sem_Warn is
  -- Check_System_Aux --
  --
 
- function Check_System_Aux return Boolean is
+ function Check_System_Aux (Lunit : Entity_Id) return Boolean is
 Ent : Entity_Id;
 
  begin
@@ -2453,11 +2450,16 @@ package body Sem_Warn is
 return False;
  end Has_Visible_Entities;
 
+ --  Local variables
+
+ Ent   : Entity_Id;
+ Item  : Node_Id;
+ Lunit : Entity_Id;
+ Pack  : Entity_Id;
+
   --  Start of processing for Check_One_Unit
 
   begin
- Cnode := Cunit (Unit);
-
  --  Only do check in units that are part of the extended main unit.
  --  This is actually a necessary restriction, because in the case of
  --  subprogram acting as its own specification, there can be with's in
@@ -2576,7 +2578,7 @@ package body Sem_Warn is
if Unit = Spec_Unit then
   Set_No_Entities_Ref_In_Spec (Item);
 
-   elsif Check_System_Aux then
+   elsif Check_System_Aux (Lunit) then
   null;
 
--  Else the warning may be needed




[Ada] Fix bogus error on conversion from Float to 128-bit unsigned

2020-10-22 Thread Pierre-Marie de Rodat
The compiler confuses itself because it generates a range check in Float
whose upper bound is 2 ** 128, but this number is larger than the largest
number representable in Float so it triggers an error when converted to
Float as part of the check.

The fix is to saturate the upper bound of the check to that of Float.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* checks.adb (Apply_Float_Conversion_Check): Saturate the bounds
of the check to those of the base type of the expression.diff --git a/gcc/ada/checks.adb b/gcc/ada/checks.adb
--- a/gcc/ada/checks.adb
+++ b/gcc/ada/checks.adb
@@ -2149,6 +2149,15 @@ package body Checks is
  Lo_OK := (Lo >= UR_From_Uint (Ifirst));
   end if;
 
+  --  Saturate the lower bound to that of the expression's type, because
+  --  we do not want to create an out-of-range value but we still need to
+  --  do a comparison to catch NaNs.
+
+  if Lo < Expr_Value_R (Type_Low_Bound (Expr_Type)) then
+ Lo := Expr_Value_R (Type_Low_Bound (Expr_Type));
+ Lo_OK := True;
+  end if;
+
   if Lo_OK then
 
  --  Lo_Chk := (X >= Lo)
@@ -2183,6 +2192,15 @@ package body Checks is
  Hi_OK := (Hi <= UR_From_Uint (Ilast));
   end if;
 
+  --  Saturate the higher bound to that of the expression's type, because
+  --  we do not want to create an out-of-range value but we still need to
+  --  do a comparison to catch NaNs.
+
+  if Hi > Expr_Value_R (Type_High_Bound (Expr_Type)) then
+ Hi := Expr_Value_R (Type_High_Bound (Expr_Type));
+ Hi_OK := True;
+  end if;
+
   if Hi_OK then
 
  --  Hi_Chk := (X <= Hi)




[Ada] Ada_2020: ongoing work for aggregates for bounded containers

2020-10-22 Thread Pierre-Marie de Rodat
This patch completes the handling of predefined bounded containers,
including indexed containers with iterated_component_associations.  The
size of the constructed object is taken from the size of the aggregate
if it can be determined statically, and otherwise uses the default value
for the given predefined constructor.  The patch also adds a static
semantic check that an aggregate for an indexed container is either
fully positional of fully named, unlike array aggregates.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_aggr.adb: (Resolve_Container_Aggregate): For an indexed
container, verify that expressions and component associations
are not both present.
* exp_aggr.adb: Code reorganization, additional comments.
(Expand_Container_Aggregate): Use Aggregate_Size for Iterated_
Component_Associations for indexed aggregates. If present, the
default value of the formal in the constructor function is used
when the size of the aggregate cannot be determined statically.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -6909,7 +6909,15 @@ package body Exp_Aggr is
 
   Comp  : Node_Id;
   Decl  : Node_Id;
+  Default   : Node_Id;
   Init_Stat : Node_Id;
+  Siz   : Int;
+
+  function Aggregate_Size return Int;
+  --  Compute number of entries in aggregate, including choices
+  --  that cover a range, as well as iterated constructs.
+  --  Return -1 if the size is not known statically, in which case
+  --  we allocate a default size for the aggregate.
 
   procedure Expand_Iterated_Component (Comp : Node_Id);
   --  Handle iterated_component_association and iterated_Element
@@ -6917,6 +6925,86 @@ package body Exp_Aggr is
   --  given either by a loop parameter specification or an iterator
   --  specification.
 
+  
+  -- Aggregate_Size --
+  
+
+  function Aggregate_Size return Int is
+ Comp   : Node_Id;
+ Choice : Node_Id;
+ Lo, Hi : Node_Id;
+ Siz : Int := 0;
+
+ procedure Add_Range_Size;
+ --  Compute size of component association given by
+ --  range or subtype name.
+
+ procedure Add_Range_Size is
+ begin
+if Nkind (Lo) = N_Integer_Literal then
+   Siz := Siz + UI_To_Int (Intval (Hi))
+ - UI_To_Int (Intval (Lo)) + 1;
+end if;
+ end Add_Range_Size;
+
+  begin
+ if Present (Expressions (N)) then
+Siz := List_Length (Expressions (N));
+ end if;
+
+ if Present (Component_Associations (N)) then
+Comp := First (Component_Associations (N));
+while Present (Comp) loop
+   Choice := First (Choice_List (Comp));
+
+   while Present (Choice) loop
+  Analyze (Choice);
+
+  if Nkind (Choice) = N_Range then
+ Lo := Low_Bound (Choice);
+ Hi := High_Bound (Choice);
+ if Nkind (Lo) /= N_Integer_Literal
+   or else Nkind (Hi) /= N_Integer_Literal
+ then
+return -1;
+ else
+Add_Range_Size;
+ end if;
+
+  elsif Is_Entity_Name (Choice)
+and then Is_Type (Entity (Choice))
+  then
+ Lo := Type_Low_Bound (Entity (Choice));
+ Hi := Type_High_Bound (Entity (Choice));
+ if Nkind (Lo) /= N_Integer_Literal
+   or else Nkind (Hi) /= N_Integer_Literal
+ then
+return -1;
+ else
+Add_Range_Size;
+ end if;
+
+ Rewrite (Choice,
+   Make_Range (Loc,
+ New_Copy_Tree (Lo),
+ New_Copy_Tree (Hi)));
+
+  else
+ --  Single choice (syntax excludes a subtype
+ --  indication).
+
+ Siz := Siz + 1;
+  end if;
+
+  Next (Choice);
+   end loop;
+   Next (Comp);
+end loop;
+ end if;
+
+ return Siz;
+  end Aggregate_Size;
+
   ---
   -- Expand_Iterated_Component --
   ---
@@ -7040,35 +7128,78 @@ package body Exp_Aggr is
 
   end Expand_Iterated_Component;
 
+  --  Start of processing for Expand_Container_Aggregate
+
begin
   Parse_Aspect_Aggregate (Asp,
 Empty_Subp, Add_Named_Subp, Add_Unnamed_Subp,
 New_Indexed_Subp, Assign_Indexed_Subp);
-  Decl :=
-

[Ada] Fix transformation of Suppress aspect into pragma

2020-10-22 Thread Pierre-Marie de Rodat
Using the Suppress aspect results in a crash. This is caused by the
incorrect transformation of the Suppress aspect into its pragma
equivalent: the entity and check name were inverted.  We use this change
as an excuse to turn Make_Aitem_Pragma into a function that returns a
new value instead of changing a variable out of its scope.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch13.adb (Make_Aitem_Pragma): Turn into function. This
removes a side-effect on the Aitem variable.
(Analyze_Aspect_Specifications): Handle Suppress and Unsuppress
aspects differently from the Linker_Section aspect.
(Ceck_Aspect_At_Freeze_Point): Don't expect Suppress/Unsuppress
to be delayed anymore.diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -1813,9 +1813,9 @@ package body Sem_Ch13 is
 procedure Analyze_Aspect_Static;
 --  Ada 202x (AI12-0075): Perform analysis of aspect Static
 
-procedure Make_Aitem_Pragma
+function Make_Aitem_Pragma
   (Pragma_Argument_Associations : List_Id;
-   Pragma_Name  : Name_Id);
+   Pragma_Name  : Name_Id) return Node_Id;
 --  This is a wrapper for Make_Pragma used for converting aspects
 --  to pragmas. It takes care of Sloc (set from Loc) and building
 --  the pragma identifier from the given name. In addition the
@@ -1874,7 +1874,7 @@ package body Sem_Ch13 is
   --  Generate:
   --pragma Convention (, );
 
-  Make_Aitem_Pragma
+  Aitem := Make_Aitem_Pragma
 (Pragma_Name => Name_Convention,
  Pragma_Argument_Associations => New_List (
Make_Pragma_Argument_Association (Loc,
@@ -2677,12 +2677,12 @@ package body Sem_Ch13 is
 -- Make_Aitem_Pragma --
 ---
 
-procedure Make_Aitem_Pragma
+function Make_Aitem_Pragma
   (Pragma_Argument_Associations : List_Id;
-   Pragma_Name  : Name_Id)
+   Pragma_Name  : Name_Id) return Node_Id
 is
-   Args : List_Id := Pragma_Argument_Associations;
-
+   Args  : List_Id := Pragma_Argument_Associations;
+   Aitem : Node_Id;
 begin
--  We should never get here if aspect was disabled
 
@@ -2715,6 +2715,8 @@ package body Sem_Ch13 is
 
Set_Corresponding_Aspect (Aitem, Aspect);
Set_From_Aspect_Specification (Aitem);
+
+   return Aitem;
 end Make_Aitem_Pragma;
 
  --  Start of processing for Analyze_One_Aspect
@@ -3048,13 +3050,10 @@ package body Sem_Ch13 is
--  referring to the entity, and the second argument is the
--  aspect definition expression.
 
-   --  Linker_Section/Suppress/Unsuppress
+   --  Linker_Section
 
-   when Aspect_Linker_Section
-  | Aspect_Suppress
-  | Aspect_Unsuppress
-   =>
-  Make_Aitem_Pragma
+   when Aspect_Linker_Section =>
+  Aitem := Make_Aitem_Pragma
 (Pragma_Argument_Associations => New_List (
Make_Pragma_Argument_Association (Loc,
  Expression => New_Occurrence_Of (E, Loc)),
@@ -3069,8 +3068,7 @@ package body Sem_Ch13 is
   --  code. (This is already done for types with implicit
   --  initialization, such as protected types.)
 
-  if A_Id = Aspect_Linker_Section
-and then Nkind (N) = N_Object_Declaration
+  if Nkind (N) = N_Object_Declaration
 and then Has_Init_Expression (N)
   then
  Delay_Required := False;
@@ -3081,7 +3079,7 @@ package body Sem_Ch13 is
--  Corresponds to pragma Implemented, construct the pragma
 
when Aspect_Synchronization =>
-  Make_Aitem_Pragma
+  Aitem := Make_Aitem_Pragma
 (Pragma_Argument_Associations => New_List (
Make_Pragma_Argument_Association (Loc,
  Expression => New_Occurrence_Of (E, Loc)),
@@ -3092,7 +3090,7 @@ package body Sem_Ch13 is
--  Attach_Handler
 
when Aspect_Attach_Handler =>
-  Make_Aitem_Pragma
+  Aitem := Make_Aitem_Pragma
 (Pragma_Argument_Associations => New_List (
Make_Pragma_Argument_Association (Sloc (Ent),
  Expression => Ent),
@@ -3134,7 +3132,7 @@ package body Sem_Ch13 is

[Ada] Refactor appending to possibly empty lists

2020-10-22 Thread Pierre-Marie de Rodat
Reuse Append_New_To when expanding pragmas and appending code to
possibly empty lists of statements. This is equivalent to checking it
the list exists, allocating a new list if necessary, and appending to
it.

Code cleanup only related to implementation of aspect
Subprogram_Variant, which is similarly expanded as many of the existing
pragmas. Semantics is unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_prag.adb (Expand_Pragma_Contract_Cases,
Expand_Pragma_Loop_Variant): Reuse Append_New_To.
* sem_prag.adb (Analyze_Contract_Cases_In_Decl_Part): Fix typo.
(Analyze_Pre_Post_Condition): Refactor repeated calls to
Defining_Entity.diff --git a/gcc/ada/exp_prag.adb b/gcc/ada/exp_prag.adb
--- a/gcc/ada/exp_prag.adb
+++ b/gcc/ada/exp_prag.adb
@@ -1831,11 +1831,7 @@ package body Exp_Prag is
   --  Raise Assertion_Error when the corresponding consequence of a case
   --  guard that evaluated to True fails.
 
-  if No (Stmts) then
- Stmts := New_List;
-  end if;
-
-  Append_To (Stmts, Conseq_Checks);
+  Append_New_To (Stmts, Conseq_Checks);
 
   In_Assertion_Expr := In_Assertion_Expr - 1;
end Expand_Pragma_Contract_Cases;
@@ -2451,28 +2447,20 @@ package body Exp_Prag is
 
  --  Step 3: Store value of the expression from the previous iteration
 
- if No (Old_Assign) then
-Old_Assign := New_List;
- end if;
-
  --  Generate:
  --Old := Curr;
 
- Append_To (Old_Assign,
+ Append_New_To (Old_Assign,
Make_Assignment_Statement (Loc,
  Name   => New_Occurrence_Of (Old_Id, Loc),
  Expression => New_Occurrence_Of (Curr_Id, Loc)));
 
  --  Step 4: Store the current value of the expression
 
- if No (Curr_Assign) then
-Curr_Assign := New_List;
- end if;
-
  --  Generate:
  --Curr := ;
 
- Append_To (Curr_Assign,
+ Append_New_To (Curr_Assign,
Make_Assignment_Statement (Loc,
  Name   => New_Occurrence_Of (Curr_Id, Loc),
  Expression => Relocate_Node (Expr)));


diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -544,7 +544,7 @@ package body Sem_Prag is
   Set_Ghost_Mode (N);
 
   --  Single and multiple contract cases must appear in aggregate form. If
-  --  this is not the case, then either the parser of the analysis of the
+  --  this is not the case, then either the parser or the analysis of the
   --  pragma failed to produce an aggregate.
 
   pragma Assert (Nkind (CCases) = N_Aggregate);
@@ -4798,7 +4798,7 @@ package body Sem_Prag is
  --  Chain the pragma on the contract for further processing by
  --  Analyze_Pre_Post_Condition_In_Decl_Part.
 
- Add_Contract_Item (N, Defining_Entity (Subp_Decl));
+ Add_Contract_Item (N, Subp_Id);
 
  --  Fully analyze the pragma when it appears inside an entry or
  --  subprogram body because it cannot benefit from forward references.




[Ada] Fix error message for import aspect

2020-10-22 Thread Pierre-Marie de Rodat
Confusing error messages are emitted about arguments when erroneously
using the import/convention aspect.  This is caused by GNAT turning
aspects into pragmas and then emitting error messages about pragmas.
This is fixed by checking if the pragma comes from an aspect
specification and emitting a different error message if it does.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_prag.adb (Process_Convention,
Process_Import_Or_Interface): Fix error message.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -8270,8 +8270,13 @@ package body Sem_Prag is
 --  Accept Intrinsic Export on types if Relaxed_RM_Semantics
 
 if not (Is_Type (E) and then Relaxed_RM_Semantics) then
-   Error_Pragma_Arg
- ("second argument of pragma% must be a subprogram", Arg2);
+   if From_Aspect_Specification (N) then
+  Error_Pragma_Arg
+ ("entity for aspect% must be a subprogram", Arg2);
+   else
+  Error_Pragma_Arg
+ ("second argument of pragma% must be a subprogram", Arg2);
+   end if;
 end if;
 
  --  Special checks for C_Variadic_n
@@ -9543,10 +9548,17 @@ package body Sem_Prag is
 Process_Import_Predefined_Type;
 
  else
-Error_Pragma_Arg
-  ("second argument of pragma% must be object, subprogram "
-   & "or incomplete type",
-   Arg2);
+if From_Aspect_Specification (N) then
+   Error_Pragma_Arg
+  ("entity for aspect% must be object, subprogram "
+ & "or incomplete type",
+   Arg2);
+else
+   Error_Pragma_Arg
+  ("second argument of pragma% must be object, subprogram "
+ & "or incomplete type",
+   Arg2);
+end if;
  end if;
 
  --  If this pragma applies to a compilation unit, then the unit, which




[Ada] Add No_Implicit_Task_Allocations and No_Implicit_PO_Allocations to Jorvik

2020-10-22 Thread Pierre-Marie de Rodat
Jorvik was meant to include the restrictions
No_Implicit_Task_Allocations and
No_Implicit_Protected_Object_Allocations but they accidentally got
overlooked during the standardisation of the GNAT_Extended_Ravenscar
profile. These restrictions are important as they allow us to statically
determine the number of tasks in the system, an important property for
Ravenscar and Jorvik systems.

With this change GNAT_Extended_Ravenscar effectively becomes an alias
for Jorvik, as originally intended. However, we keep them defined as
seperate profiles to enforce consistency in applications (i.e. only use
one or the other).

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/s-rident.ads (Profile_Info): Use a common profile
definition for Jorvik and GNAT Extended Ravenscar, using the
GNAT Extended Ravenscar definition.diff --git a/gcc/ada/libgnat/s-rident.ads b/gcc/ada/libgnat/s-rident.ads
--- a/gcc/ada/libgnat/s-rident.ads
+++ b/gcc/ada/libgnat/s-rident.ads
@@ -551,9 +551,10 @@ package System.Rident is
Max_Task_Entries=> 0,
others  => 0)),
 
- Jorvik  =>
+ Jorvik | GNAT_Extended_Ravenscar =>
 
- --  Restrictions for Jorvik profile ..
+ --  Restrictions for Jorvik profile, previously known
+ --  known as the GNAT_Extended_Ravenscar profile.
 
  --  Note: the table entries here only represent the
  --  required restriction profile for Jorvik. The
@@ -567,7 +568,12 @@ package System.Rident is
  --  as follows:
  -- 1) Ravenscar includes restriction Simple_Barriers;
  --Jorvik includes Pure_Barriers instead.
- -- 2) The following 6 restrictions are included in
+ -- 2) The No_Implicit_Heap_Allocations restriction is
+ --lifted and replaced with the following
+ --restrictions:
+ --  No_Implicit_Task_Allocations
+ --  No_Implicit_Protected_Object_Allocations
+ -- 3) The following 6 restrictions are included in
  --Ravenscar but not in Jorvik:
  --  No_Implicit_Heap_Allocations
  --  No_Relative_Delay
@@ -598,45 +604,6 @@ package System.Rident is
 
--  plus these additional restrictions:
 
-   No_Local_Timing_Events   => True,
-   No_Select_Statements => True,
-   No_Specific_Termination_Handlers => True,
-   No_Task_Termination  => True,
-   Pure_Barriers=> True,
-   others   => False),
-
---  Value settings for Ravenscar (same as Restricted)
-
-Value =>
-  (Max_Asynchronous_Select_Nesting => 0,
-   Max_Select_Alternatives => 0,
-   Max_Task_Entries=> 0,
-   others  => 0)),
-
- GNAT_Extended_Ravenscar  =>
-
- --  Restrictions for GNAT_Extended_Ravenscar =
- --Restricted profile ..
-
-   (Set   =>
-  (No_Abort_Statements => True,
-   No_Asynchronous_Control => True,
-   No_Dynamic_Attachment   => True,
-   No_Dynamic_CPU_Assignment   => True,
-   No_Dynamic_Priorities   => True,
-   No_Local_Protected_Objects  => True,
-   No_Protected_Type_Allocators=> True,
-   No_Requeue_Statements   => True,
-   No_Task_Allocators  => True,
-   No_Task_Attributes_Package  => True,
-   No_Task_Hierarchy   => True,
-   No_Terminate_Alternatives   => True,
-   Max_Asynchronous_Select_Nesting => True,
-   Max_Select_Alternatives => True,
-   Max_Task_Entries=> True,
-
-   --  plus these additional restrictions:
-
No_Implicit_Task_Allocations => True,
No_Implicit_Protected_Object_Allocations
 => True,




Re: [patch] libstdc++: Scope configuration for vxworks to all versions

2020-10-22 Thread Olivier Hainque



> On 22 Oct 2020, at 11:09, Jonathan Wakely  wrote:
> 
> (Please CC the libstdc++ list for all lisbtdc++ patches)

Oh, sure.

> Looks good, thanks.

Great, thanks for your prompt feedback :)

Olivier



Re: [Ada,FYI] revamp ada.numerics.aux

2020-10-22 Thread Alexandre Oliva
On Oct 22, 2020, Alexandre Oliva  wrote:

> (some regressions remain on x86 and x86_64,
> so further changes are expected

Here's the fix I'm installing.  I'd failed to add the __nolibm bit to
x86*-vxworks in the Ada.Numerics.Aux revamp patch.  Then, when I added
__wraplf for low-precision real types, I added them next to __nolibm,
since that was supposed to be present for all vxworks ports.  Oops.

I'm checking this in.  Tested with the affected platforms.  Approved by
Eric Botcazou.


use wraplf for low-precision elementary functions on x86*-vxworks too

From: Alexandre Oliva 

The earlier patch that introduced the wraplf variants missed the
x86*-vxworks* ports.  This fixes them.


for  gcc/ada/ChangeLog

* Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Select
nolibm and wraplf variants like other vxworks ports.
---
 gcc/ada/Makefile.rtl |3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
index efb73e5..e2a4f4e 100644
--- a/gcc/ada/Makefile.rtl
+++ b/gcc/ada/Makefile.rtl
@@ -1279,6 +1279,9 @@ ifeq ($(strip $(filter-out %86 x86_64 wrs vxworks 
vxworks7%,$(target_cpu) $(targ
   LIBGNAT_TARGET_PAIRS+= \
   a-intnam.adshttps://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer


Re: [PATCH] LTO: get_section: add new argument

2020-10-22 Thread Martin Jambor
Hi,

On Thu, Oct 22 2020, Martin Liška wrote:
> All right, there's a patch that works for me.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
> From 33c58cab6bc0d779b11e7ffb36bfb485d73d6816 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Wed, 21 Oct 2020 11:11:03 +0200
> Subject: [PATCH] LTO: get_section: add new argument
>
> gcc/ChangeLog:
>
>   PR lto/97508
>   * langhooks.c (lhd_begin_section): Call get_section with
>   not_existing = true.
>   * output.h (get_section): Add new argument.
>   * varasm.c (get_section): Fail when NOT_EXISTING is true
>   and a section already exists.
>   * ipa-cp.c (ipcp_write_summary): Remove.
>   (ipcp_read_summary): Likewise.
>   * ipa-fnsummary.c (ipa_fn_summary_read): Always read jump
>   functions summary.
>   (ipa_fn_summary_write): Always stream it.

the ipa bits are OK.  One nit...

[...]

> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index ea0b59cf44a..207c9b077d1 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -297,6 +299,12 @@ get_section (const char *name, unsigned int flags, tree 
> decl)
>  }
>else
>  {
> +  if (not_existing)
> + {
> +   error ("Section already exists: %qs", name);

...is that I think this should be internal_error.  I am not sure what
difference it makes in practice, if any, though.

Thanks,

Martin


> +   gcc_unreachable ();
> + }
> +
>sect = *slot;
>/* It is fine if one of the sections has SECTION_NOTYPE as long as
>   the other has none of the contrary flags (see the logic at the end
> -- 
> 2.28.0


Re: enable sincos optimization on cygming targets

2020-10-22 Thread Alexandre Oliva
On Oct 22, 2020, Jonathan Yong <10wa...@gmail.com> wrote:

> No objections for mingw-w64 since it has been tested, but I'm not
> certain if the original mingw.org version has it.

Prompted by you, I looked into the original mingw32, and found it does
NOT have sincos, so I withdraw the patch, in favor of this one.  Since
this one affects only mingw-w64, I haven't checked whether cygwin has
it.  Hopefully someone with easier access to the platform can do so and
duplicate the change in the Cygwin-specific compiler configuration
header.


enable sincos optimization on mingw-w64

From: Alexandre Oliva 

The sincos transformation does not take place on all platforms,
because the libc_has_function target hook disables it by default.

Current mingw-w64's math library supports sincos, sincosl and sincosf,
in 32- and 64-bit modes.  I suppose this has been this way for long.

This patch enables the sincos optimization on this platform.


for  gcc/ChangeLog

* config/i386/mingw-w64.h (TARGET_LIBC_HAS_FUNCTION): Enable
sincos optimization.
---
 gcc/config/i386/mingw-w64.h |6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h
index 408e57c..0d0aa93 100644
--- a/gcc/config/i386/mingw-w64.h
+++ b/gcc/config/i386/mingw-w64.h
@@ -98,3 +98,9 @@ along with GCC; see the file COPYING3.  If not see
   %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \
   " LINK_SPEC_LARGE_ADDR_AWARE "\
   %(shared_libgcc_undefs)"
+
+/* Enable sincos optimization, overriding cygming.h.  sincos, sincosf
+   and sincosl functions are available on mingw-w64, but not on the
+   original mingw32.  */
+#undef TARGET_LIBC_HAS_FUNCTION
+#define TARGET_LIBC_HAS_FUNCTION gnu_libc_has_function


-- 
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer


[PATCH] lto: LTO cgraph support for late declare variant resolution

2020-10-22 Thread Jakub Jelinek via Gcc-patches
On Thu, May 14, 2020 at 02:17:45PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > For LTO, the patch only saves/restores the two cgraph_node bits added in the
> > patch, but doesn't yet stream out and back in the on the side info for the
> > declare_variant_alt.  For the LTO partitioning, I believe those artificial
> > FUNCTION_DECLs with declare_variant_alt need to go into partition together
> > with anything that calls them (possibly duplicated), any way how to achieve
> > that?  Say if declare variant artificial fn foobar is directly
> > called from all of foo, bar and baz and not from qux and we want 4
> > partitions, one for each of foo, bar, baz, qux, then foobar is needed in the
> > first 3 partitions, and the IPA_REF_ADDRs recorded for foobar that right
> > after IPA the foobar call will be replaced with calls to foobar1, foobar2,
> > foobar3 or foobar (non-artificial) can of course stay in different
> > partitions if needed.
> 
> I've tried to add the saving/restoring next to ipa refs saving/restoring, as
> the declare variant alt stuff is kind of extension of those, unfortunately
> following doesn't compile, because I need to also write or read a tree there
> (ctx is a portion of DECL_ATTRIBUTES of the base function), but the ipa refs
> write/read back functions don't have arguments that can be used for that.

This patch adds the streaming out and in of those omp_declare_variant_alt
hash table on the side data for the declare_variant_alt cgraph_nodes and
treats for LTO purposes the declare_variant_alt nodes (which have no body)
as if they contained a body that calls all the possible variants.
After IPA all the calls to these magic declare_variant_alt calls are
replaced with call to one of the variant depending on which one has the
highest score in the context.

Honza, any comments/suggestions on this?

So far tested just on the new testcase.

2020-10-22  Jakub Jelinek  

gcc/
* lto-streamer.h (omp_lto_output_declare_variant_alt,
omp_lto_input_declare_variant_alt): Declare variant.
* symtab.c (symtab_node::get_partitioning_class): Return
SYMBOL_DUPLICATE for declare_variant_alt nodes.
* passes.c (ipa_write_summaries): Add declare_variant_alt to
partition.
* lto-cgraph.c (output_refs): Call omp_lto_output_declare_variant_alt
on declare_variant_alt nodes.
(input_refs): Call omp_lto_input_declare_variant_alt on
declare_variant_alt nodes.
* lto-streamer-out.c (output_function): Don't call
collect_block_tree_leafs if DECL_INITIAL is error_mark_node.
(lto_output): Call output_function even for declare_variant_alt
nodes.
* omp-general.c (omp_lto_output_declare_variant_alt,
omp_lto_input_declare_variant_alt): New functions.
gcc/lto/
* lto-common.c (lto_fixup_prevailing_decls): Don't use
LTO_NO_PREVAIL on TREE_LIST's TREE_PURPOSE.
* lto-partition.c (lto_balanced_map): Treat declare_variant_alt
nodes like definitions.
libgomp/
* testsuite/libgomp.c/declare-variant-1.c: New test.

--- gcc/lto-streamer.h.jj   2020-10-20 13:11:56.669053784 +0200
+++ gcc/lto-streamer.h  2020-10-22 11:17:37.806472939 +0200
@@ -927,6 +927,12 @@ bool reachable_from_this_partition_p (st
 lto_symtab_encoder_t compute_ltrans_boundary (lto_symtab_encoder_t encoder);
 void select_what_to_stream (void);
 
+/* In omp-general.c.  */
+void omp_lto_output_declare_variant_alt (lto_simple_output_block *,
+cgraph_node *, lto_symtab_encoder_t);
+void omp_lto_input_declare_variant_alt (lto_input_block *, cgraph_node *,
+   vec);
+
 /* In options-save.c.  */
 void cl_target_option_stream_out (struct output_block *, struct bitpack_d *,
  struct cl_target_option *);
--- gcc/symtab.c.jj 2020-10-20 13:11:56.670053770 +0200
+++ gcc/symtab.c2020-10-22 11:17:37.824472676 +0200
@@ -1998,7 +1998,7 @@ symtab_node::get_partitioning_class (voi
   if (DECL_ABSTRACT_P (decl))
 return SYMBOL_EXTERNAL;
 
-  if (cnode && cnode->inlined_to)
+  if (cnode && (cnode->inlined_to || cnode->declare_variant_alt))
 return SYMBOL_DUPLICATE;
 
   /* Transparent aliases are always duplicated.  */
--- gcc/passes.c.jj 2020-08-27 18:42:35.622711897 +0200
+++ gcc/passes.c2020-10-22 12:25:38.173798438 +0200
@@ -2722,7 +2722,8 @@ ipa_write_summaries (void)
 {
   struct cgraph_node *node = order[i];
 
-  if (node->definition && node->need_lto_streaming)
+  if ((node->definition || node->declare_variant_alt)
+ && node->need_lto_streaming)
{
  if (gimple_has_body_p (node->decl))
lto_prepare_function_for_streaming (node);
--- gcc/lto-cgraph.c.jj 2020-10-20 13:11:56.664053856 +0200
+++ gcc/lto-cgraph.c2020-10-22 11:17:37.806472939 +0200
@@ -766,6 +766,9 @@ output_refs (lto_symtab_encoder_t encode
  for (int i = 0; 

[r11-4203 Regression] FAIL: libgomp.fortran/examples-4/simd-2.f90 -Os (test for excess errors) on Linux/x86_64

2020-10-22 Thread sunil.k.pandey via Gcc-patches
On Linux/x86_64,

7026bb9504eb0f95e114f832cd6dd14302376861 is the first bad commit
commit 7026bb9504eb0f95e114f832cd6dd14302376861
Author: liuhongt 
Date:   Sat Sep 26 15:34:23 2020 +0800

Refactor implementation of *_bcst{_1,_2,_3} patterns.

caused

FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O2  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O2  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -g  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O3 -g  (test for excess errors)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -Os  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -Os  (test for excess errors)

with GCC configured with

Configured with: ../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-4203/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.fortran/examples-4/simd-2.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.fortran/examples-4/simd-2.f90 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)


Re: [PATCH] calls.c:can_implement_as_sibling_call_p REG_PARM_STACK_SPACE check

2020-10-22 Thread Alan Modra via Gcc-patches
On Mon, Oct 12, 2020 at 10:37:05PM +1030, Alan Modra wrote:
> Ping?
> 
> On Fri, Oct 02, 2020 at 05:03:50PM +0930, Alan Modra wrote:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555309.html

Ping^2

-- 
Alan Modra
Australia Development Lab, IBM


[PATCH] middle-end/97521 - fix VECTOR_CST expansion

2020-10-22 Thread Richard Biener
This fixes expansion of VECTOR_BOOLEAN_TYPE_P VECTOR_CSTs which
when using an integer mode are not always "mask-mode" but may
be using an integer mode when there's no supported vector mode.

The patch makes sure to only go the mask-mode expansion if
the elements do not line up to cover the full integer mode
(when they do and the mode was an actual mask-mode there's
no actual difference in both expansions).

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed
accidentially with another change ...

2020-10-22  Richard Biener  

PR middle-end/97521
* expr.c (expand_expr_real_1): Be more careful when
expanding a VECTOR_BOOLEAN_TYPE_P VECTOR_CSTs.

* gcc.target/i386/pr97521.c: New testcase.
---
 gcc/expr.c  |  5 -
 gcc/testsuite/gcc.target/i386/pr97521.c | 27 +
 2 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr97521.c

diff --git a/gcc/expr.c b/gcc/expr.c
index 9d951e82522..d87bda777d0 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -10356,7 +10356,10 @@ expand_expr_real_1 (tree exp, rtx target, machine_mode 
tmode,
scalar_int_mode int_mode;
if (is_int_mode (mode, _mode))
  {
-   if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp)))
+   if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (exp))
+   && maybe_ne (TYPE_PRECISION (TREE_TYPE (TREE_TYPE (exp)))
+* TYPE_VECTOR_SUBPARTS (TREE_TYPE (exp)),
+GET_MODE_PRECISION (int_mode)))
  return const_scalar_mask_from_tree (int_mode, exp);
else
  {
diff --git a/gcc/testsuite/gcc.target/i386/pr97521.c 
b/gcc/testsuite/gcc.target/i386/pr97521.c
new file mode 100644
index 000..804ffd61e13
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr97521.c
@@ -0,0 +1,27 @@
+/* { dg-do run } */
+/* { dg-options "-O -mno-sse2" } */
+
+typedef unsigned char __attribute__ ((__vector_size__ (8))) V;
+typedef unsigned long long __attribute__ ((__vector_size__ (16))) W;
+
+V c;
+W d, e;
+
+V
+foo (W f)
+{
+  W g = (W) { 0, 209 } <7 <= (0 < f);
+  W h = e + g + d;
+  V j = (V) (h[0]) + (V) c;
+  return j;
+}
+
+int
+main (void)
+{
+  V x = foo ((W) { 3 });
+  for (unsigned i = 0; i < sizeof (x); i++)
+if (x[i] != 0xff)
+  __builtin_abort ();
+  return 0;
+}
-- 
2.26.2


[PATCH] Refactor vect_analyze_slp_instance a bit

2020-10-22 Thread Richard Biener
In preparation for a larger change this refactors vect_analyze_slp_instance
so it doesn't need to know a vector type early.

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

2020-10-22  Richard Biener  

* tree-vect-slp.c (vect_analyze_slp_instance): Refactor so
computing a vector type early is not needed, for store group
splitting compute a new vector type based on the desired
group size.
---
 gcc/tree-vect-slp.c | 85 -
 1 file changed, 38 insertions(+), 47 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index e3f94cb8a2d..4544f0f84a8 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -2009,7 +2009,6 @@ vect_analyze_slp_instance (vec_info *vinfo,
   slp_instance new_instance;
   slp_tree node;
   unsigned int group_size;
-  tree vectype, scalar_type = NULL_TREE;
   unsigned int i;
   struct data_reference *dr = STMT_VINFO_DATA_REF (stmt_info);
   vec scalar_stmts;
@@ -2019,41 +2018,25 @@ vect_analyze_slp_instance (vec_info *vinfo,
 vect_location = stmt_info->stmt;
   if (STMT_VINFO_GROUPED_ACCESS (stmt_info))
 {
-  scalar_type = TREE_TYPE (DR_REF (dr));
   group_size = DR_GROUP_SIZE (stmt_info);
-  vectype = get_vectype_for_scalar_type (vinfo, scalar_type, group_size);
 }
   else if (!dr && REDUC_GROUP_FIRST_ELEMENT (stmt_info))
 {
   gcc_assert (is_a  (vinfo));
-  vectype = STMT_VINFO_VECTYPE (stmt_info);
   group_size = REDUC_GROUP_SIZE (stmt_info);
 }
   else if (is_gimple_assign (stmt_info->stmt)
&& gimple_assign_rhs_code (stmt_info->stmt) == CONSTRUCTOR)
 {
-  vectype = TREE_TYPE (gimple_assign_rhs1 (stmt_info->stmt));
   group_size = CONSTRUCTOR_NELTS (gimple_assign_rhs1 (stmt_info->stmt));
   constructor = true;
 }
   else
 {
   gcc_assert (is_a  (vinfo));
-  vectype = STMT_VINFO_VECTYPE (stmt_info);
   group_size = as_a  (vinfo)->reductions.length ();
 }
 
-  if (!vectype)
-{
-  if (dump_enabled_p ())
-   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
-"Build SLP failed: unsupported data-type %T\n",
-scalar_type);
-
-  return false;
-}
-  poly_uint64 nunits = TYPE_VECTOR_SUBPARTS (vectype);
-
   /* Create a node (a root of the SLP tree) for the packed grouped stores.  */
   scalar_stmts.create (group_size);
   stmt_vec_info next_info = stmt_info;
@@ -2127,7 +2110,7 @@ vect_analyze_slp_instance (vec_info *vinfo,
   /* Build the tree for the SLP instance.  */
   bool *matches = XALLOCAVEC (bool, group_size);
   unsigned npermutes = 0;
-  poly_uint64 max_nunits = nunits;
+  poly_uint64 max_nunits = 1;
   unsigned tree_size = 0;
   node = vect_build_slp_tree (vinfo, scalar_stmts, group_size,
  _nunits, matches, ,
@@ -2201,7 +2184,9 @@ vect_analyze_slp_instance (vec_info *vinfo,
 instructions do not generate this SLP instance.  */
  if (is_a  (vinfo)
  && loads_permuted
- && dr && vect_store_lanes_supported (vectype, group_size, false))
+ && dr
+ && vect_store_lanes_supported
+  (STMT_VINFO_VECTYPE (scalar_stmts[0]), group_size, false))
{
  slp_tree load_node;
  FOR_EACH_VEC_ELT (SLP_INSTANCE_LOADS (new_instance), i, load_node)
@@ -2284,51 +2269,57 @@ vect_analyze_slp_instance (vec_info *vinfo,
 }
 
   /* Try to break the group up into pieces.  */
-  unsigned HOST_WIDE_INT const_nunits;
   if (STMT_VINFO_GROUPED_ACCESS (stmt_info)
-  && DR_IS_WRITE (STMT_VINFO_DATA_REF (stmt_info))
-  && nunits.is_constant (_nunits))
+  && DR_IS_WRITE (STMT_VINFO_DATA_REF (stmt_info)))
 {
   for (i = 0; i < group_size; i++)
if (!matches[i])
  break;
 
-  /* For basic block SLP, try to break the group up into multiples of the
-vector size.  */
+  /* For basic block SLP, try to break the group up into multiples of
+a vector size.  */
   if (is_a  (vinfo)
- && (i >= const_nunits && i < group_size))
+ && (i > 1 && i < group_size))
{
- /* Split into two groups at the first vector boundary before i.  */
- gcc_assert ((const_nunits & (const_nunits - 1)) == 0);
- unsigned group1_size = i & ~(const_nunits - 1);
-
- if (dump_enabled_p ())
-   dump_printf_loc (MSG_NOTE, vect_location,
-"Splitting SLP group at stmt %u\n", i);
- stmt_vec_info rest = vect_split_slp_store_group (stmt_info,
-  group1_size);
- bool res = vect_analyze_slp_instance (vinfo, bst_map, stmt_info,
-   max_tree_size);
- /* If the first non-match was in the middle of a vector,
-skip the rest of that vector.  Do not bother to re-analyze

RE: [PATCH] SLP: Move load/store-lanes check till late

2020-10-22 Thread Richard Biener
On Thu, 22 Oct 2020, Tamar Christina wrote:

> Hi Richi,
> 
> > -Original Message-
> > From: rguent...@c653.arch.suse.de  On
> > Behalf Of Richard Biener
> > Sent: Thursday, October 22, 2020 9:44 AM
> > To: Tamar Christina 
> > Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> > Subject: Re: [PATCH] SLP: Move load/store-lanes check till late
> > 
> > On Wed, 21 Oct 2020, Tamar Christina wrote:
> > 
> > > Hi All,
> > >
> > > This moves the code that checks for load/store lanes further in the
> > > pipeline and places it after slp_optimize.  This would allow us to
> > > perform optimizations on the SLP tree and only bail out if we really have 
> > > a
> > permute.
> > >
> > > With this change it allows us to handle permutes such as {1,1,1,1}
> > > which should be handled by a load and replicate.
> > >
> > > This change however makes it all or nothing. Either all instances can
> > > be handled or none at all.  This is why some of the test cases have been
> > adjusted.
> > 
> > So this possibly leaves a loop unvectorized in case there's a ldN/stN
> > opportunity but another SLP instance with a permutation not handled by
> > interleaving is present.  What I was originally suggesting is to only 
> > cancel the
> > SLP build if _all_ instances can be handled with ldN/stN.
> 
> Ah I had somehow misunderstood this. I'll make that change.
> 
> > 
> > Of course I'm also happy with completely removing this heuristics.
> > 
> > Note some of the comments look off now, also the assignment to ok before
> > the goto is pointless and you should probably turn this into a dump print
> > instead.
> 
> Is it pointless? The first thing again does is assert:
> 
> again:
>   /* Ensure that "ok" is false (with an opt_problem if dumping is enabled).  
> */
>   gcc_assert (!ok);
> 
> and up to that point ok would still be it's default value of 
> opt_result::success ();
>
> So since I have to change it anyway I was using it to report the reason.

Ah, OK.  Though the opt_problem isn't ever reported when originating from
this piece.
 
> I can make it into a dump, but would still have to assign to `ok` unless I'm 
> missing
> something.

True.  I guess there should be some kind of hint why we decided to disable
SLP, so dumping sth would be appreciated.

Richard.

> 
> Regards,
> Tamar
> 
> > 
> > Thanks,
> > Richard.
> > 
> > > Bootstrapped Regtested on aarch64-none-linux-gnu, -x86_64-pc-linux-gnu
> > > and no issues.
> > >
> > > Ok for master?
> > 
> > 
> > 
> > > Thanks,
> > > Tamar
> > >
> > > gcc/ChangeLog:
> > >
> > >   * tree-vect-slp.c (vect_analyze_slp_instance): Moved load/store
> > lanes
> > >   check to ...
> > >   * tree-vect-loop.c (vect_analyze_loop_2): ..Here
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > >   * gcc.dg/vect/slp-11b.c: Update output scan.
> > >   * gcc.dg/vect/slp-perm-6.c: Likewise.
> > >
> > >
> > 
> > --
> > Richard Biener 
> > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409
> > Nuernberg, Germany; GF: Felix Imend
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend


[Committed] Fix PR97502

2020-10-22 Thread Andreas Krebbel via Gcc-patches
The S/390 backend does not define vec_cmp expanders so far. We relied
solely on expanding vcond.  With commit 502d63b6d various testcases
started to ICE now.

This patch just adds the missing expanders to prevent the ICE.
However, there are still a couple of performance-related testcase
regressions with the vcond lowering which have to be fixed
independently.

Bootstrapped and regression-tested on IBM Z.
Committed to mainline

gcc/ChangeLog:

PR target/97502
* config/s390/vector.md ("vec_cmp")
("vec_cmpu"): New expanders.

gcc/testsuite/ChangeLog:

* gcc.dg/pr97502.c: New test.
---
 gcc/config/s390/vector.md  | 24 +++-
 gcc/testsuite/gcc.dg/pr97502.c | 15 +++
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr97502.c

diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
index e9332bad0fd..3c01cd1b1e1 100644
--- a/gcc/config/s390/vector.md
+++ b/gcc/config/s390/vector.md
@@ -1441,7 +1441,29 @@ (define_expand "copysign3"
 ;; Integer compares
 ;;
 
-(define_insn "*vec_cmp_nocc"
+(define_expand "vec_cmp"
+  [(set (match_operand:VI_HW0 "register_operand" "")
+   (match_operator:VI_HW   1 ""
+ [(match_operand:VI_HW 2 "register_operand" "")
+  (match_operand:VI_HW 3 "register_operand" "")]))]
+  "TARGET_VX"
+{
+  s390_expand_vec_compare (operands[0], GET_CODE(operands[1]), operands[2], 
operands[3]);
+  DONE;
+})
+
+(define_expand "vec_cmpu"
+  [(set (match_operand:VI_HW0 "register_operand" "")
+   (match_operator:VI_HW   1 ""
+ [(match_operand:VI_HW 2 "register_operand" "")
+  (match_operand:VI_HW 3 "register_operand" "")]))]
+  "TARGET_VX"
+{
+  s390_expand_vec_compare (operands[0], GET_CODE(operands[1]), operands[2], 
operands[3]);
+  DONE;
+})
+
+(define_insn "*vec_cmp_nocc"
   [(set (match_operand:VI 2 "register_operand" "=v")
(VICMP_HW_OP:VI (match_operand:VI 0 "register_operand"  "v")
(match_operand:VI 1 "register_operand"  "v")))]
diff --git a/gcc/testsuite/gcc.dg/pr97502.c b/gcc/testsuite/gcc.dg/pr97502.c
new file mode 100644
index 000..d87af9c1838
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97502.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+extern char v[54];
+void bar (char *);
+void
+foo (void)
+{
+  int i;
+  char c[32];
+  bar (c);
+  for (i = 0; i < 32; i++)
+c[i] = c[i] && !v[i];
+  bar (c);
+}
-- 
2.25.1



[Committed] Fix PR97439

2020-10-22 Thread Andreas Krebbel via Gcc-patches
decimal_real_maxval misses to set the sign flag in the REAL_VALUE_TYPE.

Bootstrapped and regression tested on IBM Z.

Committed to head, gcc-10, gcc-9, and gcc-8 branches.

gcc/ChangeLog:

PR rtl-optimization/97439
* dfp.c (decimal_real_maxval): Set the sign flag in the
generated number.

gcc/testsuite/ChangeLog:

* gcc.dg/dfp/pr97439.c: New test.
---
 gcc/dfp.c  |  2 ++
 gcc/testsuite/gcc.dg/dfp/pr97439.c | 27 +++
 2 files changed, 29 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/dfp/pr97439.c

diff --git a/gcc/dfp.c b/gcc/dfp.c
index fef39a5ce39..4a0f68e5d83 100644
--- a/gcc/dfp.c
+++ b/gcc/dfp.c
@@ -740,4 +740,6 @@ decimal_real_maxval (REAL_VALUE_TYPE *r, int sign, 
machine_mode mode)
   decimal_real_from_string (r, max);
   if (sign)
 decimal128SetSign ((decimal128 *) r->sig, 1);
+
+  r->sign = sign;
 }
diff --git a/gcc/testsuite/gcc.dg/dfp/pr97439.c 
b/gcc/testsuite/gcc.dg/dfp/pr97439.c
new file mode 100644
index 000..7fcf834043c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/dfp/pr97439.c
@@ -0,0 +1,27 @@
+// { dg-do run }
+// { dg-options "-O1" }
+
+static int
+foo(_Decimal128 x, _Decimal128 y)
+{
+  if (x > y)
+return 1;
+
+  return 0;
+}
+
+int __attribute__((noinline))
+bar(_Decimal128 x)
+{
+  return foo (x, -1.0DL * __builtin_infd32());
+}
+
+int
+main (void)
+{
+  int res = bar (0.0DL);
+  if (res != 1)
+__builtin_abort ();
+
+  return 0;
+}
-- 
2.25.1



RE: [PATCH] SLP: Move load/store-lanes check till late

2020-10-22 Thread Tamar Christina via Gcc-patches
Hi Richi,

> -Original Message-
> From: rguent...@c653.arch.suse.de  On
> Behalf Of Richard Biener
> Sent: Thursday, October 22, 2020 9:44 AM
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> Subject: Re: [PATCH] SLP: Move load/store-lanes check till late
> 
> On Wed, 21 Oct 2020, Tamar Christina wrote:
> 
> > Hi All,
> >
> > This moves the code that checks for load/store lanes further in the
> > pipeline and places it after slp_optimize.  This would allow us to
> > perform optimizations on the SLP tree and only bail out if we really have a
> permute.
> >
> > With this change it allows us to handle permutes such as {1,1,1,1}
> > which should be handled by a load and replicate.
> >
> > This change however makes it all or nothing. Either all instances can
> > be handled or none at all.  This is why some of the test cases have been
> adjusted.
> 
> So this possibly leaves a loop unvectorized in case there's a ldN/stN
> opportunity but another SLP instance with a permutation not handled by
> interleaving is present.  What I was originally suggesting is to only cancel 
> the
> SLP build if _all_ instances can be handled with ldN/stN.

Ah I had somehow misunderstood this. I'll make that change.

> 
> Of course I'm also happy with completely removing this heuristics.
> 
> Note some of the comments look off now, also the assignment to ok before
> the goto is pointless and you should probably turn this into a dump print
> instead.

Is it pointless? The first thing again does is assert:

again:
  /* Ensure that "ok" is false (with an opt_problem if dumping is enabled).  */
  gcc_assert (!ok);

and up to that point ok would still be it's default value of 
opt_result::success ();

So since I have to change it anyway I was using it to report the reason.

I can make it into a dump, but would still have to assign to `ok` unless I'm 
missing
something.

Regards,
Tamar

> 
> Thanks,
> Richard.
> 
> > Bootstrapped Regtested on aarch64-none-linux-gnu, -x86_64-pc-linux-gnu
> > and no issues.
> >
> > Ok for master?
> 
> 
> 
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * tree-vect-slp.c (vect_analyze_slp_instance): Moved load/store
> lanes
> > check to ...
> > * tree-vect-loop.c (vect_analyze_loop_2): ..Here
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/vect/slp-11b.c: Update output scan.
> > * gcc.dg/vect/slp-perm-6.c: Likewise.
> >
> >
> 
> --
> Richard Biener 
> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409
> Nuernberg, Germany; GF: Felix Imend


Re: [PATCH] phiopt: Optimize x ? __builtin_clz (x) : 32 in GIMPLE [PR97503]

2020-10-22 Thread Rainer Orth
Hi Jakub,

> On Wed, Oct 21, 2020 at 07:30:46PM +0200, Rainer Orth wrote:
>> this broke sparc-sun-solaris2.11 bootstrap
>> 
>> /vol/gcc/src/hg/master/local/gcc/tree-ssa-phiopt.c: In function 'bool 
>> cond_removal_in_popcount_clz_ctz_pattern(basic_block, basic_block, edge, 
>> edge, gimple*, tree, tree)':
>> /vol/gcc/src/hg/master/local/gcc/tree-ssa-phiopt.c:1858:27: error: variable 
>> 'mode' set but not used [-Werror=unused-but-set-variable]
>>  1858 |   scalar_int_mode mode = SCALAR_INT_TYPE_MODE (TREE_TYPE 
>> (arg));
>>   |   ^~~~
>> 
>> 
>> and doubtlessly several other targets that use the defaults.h definition of
>> 
>> #define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE)  0
>
> Ugh, seems many of those macros do not evaluate the first argument.
> This got broken by the change to direct_internal_fn_supported_p, previously
> it used mode also in the optab test.
>
> Anyway, I think this should fix it, I'll bootstrap/regtest it tonight:
>
> 2020-10-21  Jakub Jelinek  
>
>   * tree-ssa-phiopt.c (cond_removal_in_popcount_clz_ctz_pattern):
>   For CLZ and CTZ tests, use type temporary instead of mode.

this worked for me just fine, both sparc-sun-solaris2.11 and (for good
measure) i386-pc-solaris2.11.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PATCH] openmp: Implement support for OMP_TARGET_OFFLOAD

2020-10-22 Thread Rainer Orth
Hi Jakub,

>> the patch also breaks bootstrap on both i386-pc-solaris2.11 and
>> sparc-sun-solaris2.11:
>> 
>> /vol/gcc/src/hg/master/local/libgomp/env.c: In function 'initialize_env':
>> /vol/gcc/src/hg/master/local/libgomp/env.c:414:16: error: 'new_offload'
>> may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>   414 |   *offload = new_offload;
>>   |   ~^
>> /vol/gcc/src/hg/master/local/libgomp/env.c:384:30: note: 'new_offload'
>> was declared here
>>   384 |   enum gomp_target_offload_t new_offload;
>>   |  ^~~
>
> I can't reproduce that, but I fail to see why we need two separate
> variables, one with actual value and one tracking if the value is valid.

I'd also tried i686-pc-linux-gnu, but didn't get the failure there either.

> So I'd go with:
>
> 2020-10-20  Jakub Jelinek  
>
>   * env.c (parse_target_offload): Change new_offload var type to int,
>   preinitialize to -1, remove found var and test new_offload != -1
>   instead of found.

That worked just fine.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PATCH] ipa-modref-tree.c: fix selftest leaks

2020-10-22 Thread Jan Hubicka
> "make selftest-valgrind" was reporting:
> 
> 40 bytes in 1 blocks are definitely lost in loss record 25 of 735
>at 0x483AE7D: operator new(unsigned long) (vg_replace_malloc.c:344)
>by 0xFA0CEA: selftest::test_insert_search_collapse() (ipa-modref-tree.c:40)
>by 0xFA2F9B: selftest::ipa_modref_tree_c_tests() (ipa-modref-tree.c:164)
>by 0x256E3AB: selftest::run_tests() (selftest-run-tests.c:93)
>by 0x1366A8B: toplev::run_self_tests() (toplev.c:2385)
>by 0x1366C47: toplev::main(int, char**) (toplev.c:2467)
>by 0x263203F: main (main.c:39)
> 
> 40 bytes in 1 blocks are definitely lost in loss record 26 of 735
>at 0x483AE7D: operator new(unsigned long) (vg_replace_malloc.c:344)
>by 0xFA264A: selftest::test_merge() (ipa-modref-tree.c:123)
>by 0xFA2FA0: selftest::ipa_modref_tree_c_tests() (ipa-modref-tree.c:165)
>by 0x256E3AB: selftest::run_tests() (selftest-run-tests.c:93)
>by 0x1366A8B: toplev::run_self_tests() (toplev.c:2385)
>by 0x1366C47: toplev::main(int, char**) (toplev.c:2467)
>by 0x263203F: main (main.c:39)
> 
> 40 bytes in 1 blocks are definitely lost in loss record 27 of 735
>at 0x483AE7D: operator new(unsigned long) (vg_replace_malloc.c:344)
>by 0xFA279E: selftest::test_merge() (ipa-modref-tree.c:130)
>by 0xFA2FA0: selftest::ipa_modref_tree_c_tests() (ipa-modref-tree.c:165)
>by 0x256E3AB: selftest::run_tests() (selftest-run-tests.c:93)
>by 0x1366A8B: toplev::run_self_tests() (toplev.c:2385)
>by 0x1366C47: toplev::main(int, char**) (toplev.c:2467)
>by 0x263203F: main (main.c:39)
> 
> With this patch, the output is clean.
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> 
> OK for master?
> 
> gcc/ChangeLog:
>   * ipa-modref-tree.c (selftest::test_insert_search_collapse): Fix
>   leak.
>   (selftest::test_merge): Fix leaks.
OK,
thanks!
Honza


Re: [PATCH] ipa-modref-tree.c: fix selftest leaks

2020-10-22 Thread Richard Biener via Gcc-patches
On Thu, Oct 22, 2020 at 12:26 PM David Malcolm via Gcc-patches
 wrote:
>
> "make selftest-valgrind" was reporting:
>
> 40 bytes in 1 blocks are definitely lost in loss record 25 of 735
>at 0x483AE7D: operator new(unsigned long) (vg_replace_malloc.c:344)
>by 0xFA0CEA: selftest::test_insert_search_collapse() (ipa-modref-tree.c:40)
>by 0xFA2F9B: selftest::ipa_modref_tree_c_tests() (ipa-modref-tree.c:164)
>by 0x256E3AB: selftest::run_tests() (selftest-run-tests.c:93)
>by 0x1366A8B: toplev::run_self_tests() (toplev.c:2385)
>by 0x1366C47: toplev::main(int, char**) (toplev.c:2467)
>by 0x263203F: main (main.c:39)
>
> 40 bytes in 1 blocks are definitely lost in loss record 26 of 735
>at 0x483AE7D: operator new(unsigned long) (vg_replace_malloc.c:344)
>by 0xFA264A: selftest::test_merge() (ipa-modref-tree.c:123)
>by 0xFA2FA0: selftest::ipa_modref_tree_c_tests() (ipa-modref-tree.c:165)
>by 0x256E3AB: selftest::run_tests() (selftest-run-tests.c:93)
>by 0x1366A8B: toplev::run_self_tests() (toplev.c:2385)
>by 0x1366C47: toplev::main(int, char**) (toplev.c:2467)
>by 0x263203F: main (main.c:39)
>
> 40 bytes in 1 blocks are definitely lost in loss record 27 of 735
>at 0x483AE7D: operator new(unsigned long) (vg_replace_malloc.c:344)
>by 0xFA279E: selftest::test_merge() (ipa-modref-tree.c:130)
>by 0xFA2FA0: selftest::ipa_modref_tree_c_tests() (ipa-modref-tree.c:165)
>by 0x256E3AB: selftest::run_tests() (selftest-run-tests.c:93)
>by 0x1366A8B: toplev::run_self_tests() (toplev.c:2385)
>by 0x1366C47: toplev::main(int, char**) (toplev.c:2467)
>by 0x263203F: main (main.c:39)
>
> With this patch, the output is clean.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> OK for master?

OK.

> gcc/ChangeLog:
> * ipa-modref-tree.c (selftest::test_insert_search_collapse): Fix
> leak.
> (selftest::test_merge): Fix leaks.
> ---
>  gcc/ipa-modref-tree.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/gcc/ipa-modref-tree.c b/gcc/ipa-modref-tree.c
> index 1a595090b6c..94c68cc4969 100644
> --- a/gcc/ipa-modref-tree.c
> +++ b/gcc/ipa-modref-tree.c
> @@ -111,6 +111,8 @@ test_insert_search_collapse ()
>ASSERT_TRUE (t->every_base);
>ASSERT_EQ (t->bases, NULL);
>ASSERT_EQ (t->search (1), NULL);
> +
> +  delete t;
>  }
>
>  static void
> @@ -155,6 +157,9 @@ test_merge ()
>base_node = t1->search (3);
>ASSERT_EQ (base_node->refs, NULL);
>ASSERT_TRUE (base_node->every_ref);
> +
> +  delete t1;
> +  delete t2;
>  }
>
>
> --
> 2.26.2
>


[committed] analyzer: fix ICE when handling callback exceeds enode limit [PR97514]

2020-10-22 Thread David Malcolm via Gcc-patches
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-4222-gf7decfaebbcb8522fcb39b03a391a5c2cb64f460.

gcc/analyzer/ChangeLog:
PR analyzer/97514
* engine.cc (exploded_graph::add_function_entry): Handle failure
to create an enode, rather than asserting.

gcc/testsuite/ChangeLog:
PR analyzer/97514
* gcc.dg/analyzer/pr97514.c: New test.
---
 gcc/analyzer/engine.cc  |  5 +++--
 gcc/testsuite/gcc.dg/analyzer/pr97514.c | 18 ++
 2 files changed, 21 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr97514.c

diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index b1c877e5231..d4c654a3497 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -1956,8 +1956,9 @@ exploded_graph::add_function_entry (function *fun)
 return NULL;
 
   exploded_node *enode = get_or_create_node (point, state, NULL);
-  /* We should never fail to add such a node.  */
-  gcc_assert (enode);
+  if (!enode)
+return NULL;
+
   add_edge (m_origin, enode, NULL);
 
   m_functions_with_enodes.add (fun);
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr97514.c 
b/gcc/testsuite/gcc.dg/analyzer/pr97514.c
new file mode 100644
index 000..27245f442bc
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr97514.c
@@ -0,0 +1,18 @@
+/* { dg-additional-options "--param analyzer-max-enodes-per-program-point=0 
-Wno-analyzer-too-complex" } */
+
+typedef void (*sighandler_t) (int);
+
+void
+signal (int, sighandler_t);
+
+static void
+kw (int signum)
+{
+  (void) signum;
+}
+
+void
+gk (int ot)
+{
+  signal (ot, kw);
+}
-- 
2.26.2



  1   2   >