Re: [PATCH] attribs: Don't diagnose attribute exclusions during error recovery [PR94705]

[Richard Biener]

On Wed, 22 Apr 2020, Jakub Jelinek wrote:

> Hi!
> 
> On the following testcase GCC ICEs, because last_decl is error_mark_node,
> and diag_attr_exclusions assumes that if it is not NULL, it must be a decl.
> 
> The following patch just doesn't diagnose attribute exclusions if the
> other decl is erroneous (and thus we've already reported errors for it).
> 
> Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?

OK.

> 2020-04-22  Jakub Jelinek  
> 
>   PR c/94705
>   * attribs.c (decl_attribute): Don't diagnose attribute exclusions
>   if last_decl is error_mark_node or has such a TREE_TYPE.
> 
>   * gcc.dg/pr94705.c: New test.
> 
> --- gcc/attribs.c.jj  2020-01-15 00:26:26.444529132 +0100
> +++ gcc/attribs.c 2020-04-22 10:12:49.071442463 +0200
> @@ -677,7 +677,8 @@ decl_attributes (tree *node, tree attrib
>reject incompatible attributes.  */
>bool built_in = flags & ATTR_FLAG_BUILT_IN;
>if (spec->exclude
> -   && (flag_checking || !built_in))
> +   && (flag_checking || !built_in)
> +   && !error_operand_p (last_decl))
>   {
> /* Always check attributes on user-defined functions.
>Check them on built-ins only when -fchecking is set.
> --- gcc/testsuite/gcc.dg/pr94705.c.jj 2020-04-22 10:18:13.491485751 +0200
> +++ gcc/testsuite/gcc.dg/pr94705.c2020-04-22 10:19:06.077682332 +0200
> @@ -0,0 +1,13 @@
> +/* PR c/94705 */
> +/* { dg-do compile } */
> +/* { dg-options "" } */
> +
> +void foo ();
> +
> +int
> +bar (void)
> +{
> +  foo (baz); /* { dg-error "'baz' undeclared" } */
> + /* { dg-message "only once" "" { target *-*-* } .-1 } */
> +  void __attribute__ ((noinline)) baz (void);
> +}
> 
>   Jakub
> 
> 

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

Re: [PATCH] Do not remove ifunc_resolver in LTO.

[Martin Liška]

On 4/22/20 8:11 PM, Jan Hubicka wrote:

On Mon, 2020-04-20 at 11:34 +0200, Martin Liška wrote:

Hi.

The patch prevents a ifunc alias from removal in remove unreachable nodes.
Note that ifunc alias lives in a COMDAT section and so that
cgraph_node::can_remove_if_no_direct_calls_and_refs_p returned true for it.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I was unable to create a lto test-case where a linked binary could be
scanned for assembly.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-04-20  Martin Liska  

PR lto/94659
* cgraph.h (cgraph_node::can_remove_if_no_direct_calls_and_refs_p):
Do not remove ifunc_resolvers in remove unreachable nodes in LTO.

OK

Is it intended to keep the comdat group alive even when the function is
not used by the current translation unit?


Yes, if you take a look at the mentioned PR, the function is exported and used
by a different TU.

Or do you have a particular test-case which you're talking about?

Martin



Honza

jeff

Re: [PATCH] libstdc++: don't use #include_next in c_global headers

[Helmut Grohne]

Hi,

On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote:
> > Now you are probably going to say that "-isystem /usr/include" is a bad
> > idea and that you shouldn't do that.
> 
> Right.
> 
> > I'm inclined to agree. This isn't a
> > problem just yet. Debian wants to move /usr/include/stdlib.h to
> > /usr/include//stdlib.h. After that move, the problematic flag
> > becomes "-isystem /usr/include/". Unfortunately, around 30
> > Debian packages[1] do pass exactly that flag. Regardless whether doing
> > so is a bad idea, I guess we will have to support that.
> 
> Or Debian should fix what they're going to break.

This is not quite precise. The offending -isystem
/usr/include/ flag is already being passed. According to what
you write later, doing so is broken today. It just happens to work by
accident. So all we do is making the present breakage visible.

> > I am proposing to replace those two #include_next with plain #include.
> > That'll solve the problem described above, but it is not entirely
> > obvious that doing so doesn't break something else.
> > 
> > After switching those #include_next to #include,
> > libstdc++-v3/include/c_global/cstdlib will continue to temporarily
> > will #include . Now, it'll search all include directories. It
> > may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's
> > version. We cannot tell which. If it finds the one from libstdc++-v3,
> > the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and
> > immediately #include_next  skipping the rest of the header.
> > That in turn will find the libc version. So in both cases, it ends up
> > using the right one. Precisely what we wanted.
> 
> As Marc said, this doesn't work.

That is not very precise either. Marc said that it won't fix all cases.
In practice, it would make those work that don't #include  but
use #include  instead.

Marc also indicated that using include_next for a header of a different
name is wrong. So this is a bug in libstdc++ regardless of whether it
breaks or unbreaks other pieces of software.

> If a program tries to include  it needs to get the libstdc++
> version, otherwise only the libc versions of certain functions are
> defined. That means the additional C++ overloads such as ::abs(long)
> and ::abs(long long) won't be defined. That is the reason why
> libstdc++ provides its own .
> 
> And if you do -isystem /usr/include (or any other option that causes
> libstdc++'s  to be skipped) that doesn't work. Only
> ::abs(int) gets defined.
> 
> So -isystem /usr/include breaks code, with or without your patch.

It is very difficult to disagree with -isystem /usr/include or -isystem
/usr/include/ being broken and unsupported. Having you state it
that clearly does help with communicating to other upstreams. For this
reason, I've looked into the remaining cases. It turns out that there
aren't that many left. In particular chromium, opencv and vtk got fixed
in the mean time. Basically all remaining failures could be attributed
to qmake, which passes all directories below /usr/include (including
/usr/include and /usr/include/ if a .pc file mentions them)
using -isystem. I've sent a patch https://bugs.debian.org/958479 to make
qmake stop doing that.

I therefore agree with you that the patch I sent for libstdc++ is not
necessary to make packages build on Debian. Removing the offending
-isystem flags from the respective builds is a manageable option and has
already happened to a large extend.

We can conclude that the motivation for my patch is not a good one,
because it embraces broken behaviour. However, the use of include_next
remains a bug, because the name of the including and the name of the
included header differ, and it should be fixed on that ground.

Helmut

[PATCH] c++: Explicit constructor called in copy-initialization [PR90320]

[Marek Polacek via Gcc-patches]

This test is rejected with a bogus "use of deleted function" error
starting with r225705 whereby convert_like_real/ck_base no longer
sets LOOKUP_ONLYCONVERTING for user_conv_p conversions.  This does
not seem to be always correct.  To recap, when we have something like
T t = x where T is a class type and the type of x is not T or derived
from T, we perform copy-initialization, something like:
  1. choose a user-defined conversion to convert x to T, the result is
 a prvalue,
  2. use this prvalue to direct-initialize t.

In the second step, explicit constructors should be considered, since
we're direct-initializing.  This is what r225705 fixed.

In this PR we are dealing with the first step, I think, where explicit
constructors should be skipped.  [over.match.copy] says "The converting
constructors of T are candidate functions" which clearly eliminates
explicit constructors.  But we also have to copy-initialize the argument
we are passing to such a converting constructor, and here we should
disregard explicit constructors too.

In this testcase we have

  V v = m;

and we choose V::V(M) to convert m to V.  But we wrongly choose
the explicit M::M(M&) to copy-initialize the argument; it's
a better match for a non-const lvalue than the implicit M::M(const M&)
but because it's explicit, we shouldn't use it.

When convert_like is processing the ck_user conversion -- the convfn is
V::V(M) -- it can see that cand->flags contains LOOKUP_ONLYCONVERTING,
but then when we're in build_over_call for this convfn, we have no way
to pass the flag to convert_like for the argument 'm', because convert_like
doesn't take flags.  So I've resorted to setting need_temporary_p in
a ck_rvalue, thus far unused, to signal that we're only interested in
non-explicit constructors.

LOOKUP_COPY_PARM looks relevant, but again, it's a LOOKUP_* flag, so
can't pass it to convert_like.  DR 899 also seemed related, but that
deals with direct-init contexts only.

Does this make sense?

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

PR c++/90320
* call.c (standard_conversion): Set need_temporary_p if FLAGS demands
LOOKUP_ONLYCONVERTING.
(convert_like_real) : If a ck_rvalue has
need_temporary_p set, or LOOKUP_ONLYCONVERTING into FLAGS.

* g++.dg/cpp0x/explicit13.C: New test.
---
 gcc/cp/call.c   | 24 +---
 gcc/testsuite/g++.dg/cpp0x/explicit13.C | 14 ++
 2 files changed, 31 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit13.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c58231601c9..d802f1a0c2f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -92,10 +92,10 @@ struct conversion {
  language standards, e.g. disregarding pointer qualifiers or
  converting integers to pointers.  */
   BOOL_BITFIELD bad_p : 1;
-  /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
+  /* If KIND is ck_ref_bind or ck_base, true to indicate that a
  temporary should be created to hold the result of the
- conversion.  If KIND is ck_ambig or ck_user, true means force
- copy-initialization.  */
+ conversion.  If KIND is ck_ambig, ck_rvalue, or ck_user, true means
+ force copy-initialization.  */
   BOOL_BITFIELD need_temporary_p : 1;
   /* If KIND is ck_ptr or ck_pmem, true to indicate that a conversion
  from a pointer-to-derived to pointer-to-base is being performed.  */
@@ -1252,6 +1252,8 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
   if (flags & LOOKUP_PREFER_RVALUE)
/* Tell convert_like_real to set LOOKUP_PREFER_RVALUE.  */
conv->rvaluedness_matches_p = true;
+  if (flags & LOOKUP_ONLYCONVERTING)
+   conv->need_temporary_p = true;
 }
 
/* Allow conversion between `__complex__' data types.  */
@@ -7654,10 +7656,18 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
 destination [is treated as direct-initialization].  [dcl.init] */
   flags = LOOKUP_NORMAL;
   if (convs->user_conv_p)
-   /* This conversion is being done in the context of a user-defined
-  conversion (i.e. the second step of copy-initialization), so
-  don't allow any more.  */
-   flags |= LOOKUP_NO_CONVERSION;
+   {
+ /* This conversion is being done in the context of a user-defined
+conversion (i.e. the second step of copy-initialization), so
+don't allow any more.  */
+ flags |= LOOKUP_NO_CONVERSION;
+ /* But we might also be performing a conversion of the argument
+to the user-defined conversion, i.e., not a conversion of the
+result of the user-defined conversion.  In which case we skip
+explicit constructors.  */
+ if (convs->kind == ck_rvalue && convs->need_temporary_p)
+   flags |= LOOKUP_ONLYCONVERTING;
+   }
   else
flags |= LOOKUP_ONLYCONVERTING;

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Jeff Law via Gcc-patches]

On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote:
> 
> > > In some ways it feels like it would be easier to resurrect RTL SSA :-)
> 
> Why was RTL SSA abandoned?
> 
> It might well work to keep everything in SSA form all the way to RA.
> Hrm, that doesn't sound bad at all :-)
> 
> (The PHIs need to be made explicit to something that resembles the
> machine code we will end up with, very early in the pipeline, but it
> could still also be some valid SSA form; and we can of course also
> have hard registers in all RTL, so that needs to be dealt with sanely
> some way as well  Lots of details, I don't see a crucial problem though,
> probably means I need to look harder ;-) )
Lack of time mostly.  There's some complications like subregs, argument 
registers
and the like.  But you can restrict ssa based analysis & optimizations to just
the set of pseudos that are in SSA form and do something more conservative on 
the
rest.

Jeff

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

[Jonathan Wakely via Gcc-patches]

On 22/04/20 20:43 +0100, Jonathan Wakely wrote:

On 22/04/20 15:33 -0400, Jason Merrill wrote:

On Wed, Apr 22, 2020 at 3:31 PM Jonathan Wakely  wrote:


On 22/04/20 15:19 -0400, Jason Merrill wrote:

On 4/22/20 2:37 AM, Jonathan Wakely wrote:

These warnings have nothing to do with virtual functions, so "override"
is inappropriate. The warnings are just talking about defining special
members, so let's say that.

 PR translation/94698
 * class.c (check_field_decls): Change "override" to "define" in
 -Weffc++ diagnostics.

Tested powerpc64le-linux, OK for master?


It is overriding the default(ed) definition, but I agree that
"override" now suggests virtual functions.

"define" is also wrong, though; it should be "declare".  OK with that
change.


I did consider that, but decided that it has to be user-provided (i.e.
defined by the user) to avoid the problem, because a user-declared but
defaulted function would still not clean up pointer members.



True, but we don't warn in that case, and I think that's reasonable, as the
user is being explicit about their intent.  Adding a defaulted declaration
seems like a good way to silence the warning without changing ABI.


Ah good point.


Fixed with this patch, committed to master.



commit cf88e25a2274f929d4789ca498fa3834836629c9
Author: Jonathan Wakely 
Date:   Wed Apr 22 23:18:06 2020 +0100

c++: Change -Weffc++ diagnostic to use "declare" (PR 94698)

Change the wording again, for the reasons given by Jason in
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544362.html

PR translation/94698
* class.c (check_field_decls): Change "define" to "declare" in
-Weffc++ diagnostics.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 6e14cd37aa4..e211db32377 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -3838,13 +3838,13 @@ check_field_decls (tree t, tree *access_decls,
 	  if (! TYPE_HAS_COPY_CTOR (t))
 	{
 	  warning (OPT_Weffc__,
-		   "  but does not define %<%T(const %T&)%>", t, t);
+		   "  but does not declare %<%T(const %T&)%>", t, t);
 	  if (!TYPE_HAS_COPY_ASSIGN (t))
 		warning (OPT_Weffc__, "  or %", t);
 	}
 	  else if (! TYPE_HAS_COPY_ASSIGN (t))
 	warning (OPT_Weffc__,
-		 "  but does not define %", t);
+		 "  but does not declare %", t);
 	  inform (DECL_SOURCE_LOCATION (pointer_member),
 		  "pointer member %q+D declared here", pointer_member);
 	}

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

[Segher Boessenkool]

Hi!

On Wed, Apr 22, 2020 at 03:11:48PM +0200, Jakub Jelinek wrote:
> The problem is that the presence or absence of the C++17
> artificial empty base fields, which have non-zero TYPE_SIZE, but zero
> DECL_SIZE, change the ABI decisions, if it is present (-std=c++17), the type
> might not be considered homogeneous, while if it is absent (-std=c++14), it
> can be.
> 
> The following patch fixes that and emits a -Wpsabi inform; perhaps more
> often than it could, because the fact that 
> rs6000_discover_homogeneous_aggregate
> returns true when it didn't in in GCC 7/8/9 with -std=c++17 doesn't still
> mean it will make a different ABI decision, but the warning triggered only
> on the test I've changed (the struct-layout-1.exp tests use -w -Wno-psabi
> already).

>   PR target/94707
>   * config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Add
>   CXX17_EMPTY_BASE_SEEN argument.  Pass it to recursive calls.
>   Ignore cxx17_empty_base_field_p fields after setting
>   *CXX17_EMPTY_BASE_SEEN to true.

Please use the literal capitalisation of symbol names?  So that grep and
other search works (the ALL CAPS thing is for the function introductory
comment (and other function comments) only).

> + if (cxx17_empty_base_field_p (field))
> +   {
> + *cxx17_empty_base_seen = true;
> + continue;
> +   }

Is there no way to describe this without referring to "c++17" (or even
"base field")?  It's a pretty gross abstraction violation.

> +   inform (input_location,
> +   "prior to GCC 10, parameters of type "
> +   "%qT were passed incorrectly for C++17", type);

This could more explicitly say that makes the compiled code incompatible
between GCC 10 and older, which is the point of the warning?  It's not
really necessary to say the old one was bad -- let's hope it was :-)

Looks fine otherwise.  Okay for trunk whatever you decide to do (or not
do) with my comments.  Thank you!


Segher

[PATCH] PR preprocessor/94657: use $AR, not 'ar',

[Sergei Trofimovich]

From: Sergei Trofimovich 

On system with 'ar' and '${CHOST}-ar' the latter is preferred.
as it might not match default 'ar'.

Bug is initially reported downstream as https://bugs.gentoo.org/718004.

libcpp/ChangeLog:

PR libcpp/94657
* Makefile.in: use @AR@ placeholder
* configure.ac: use AC_CHECK_TOOL to find 'ar'
* configure: regenerate
---
 libcpp/ChangeLog|  7 
 libcpp/Makefile.in  |  2 +-
 libcpp/configure| 94 +
 libcpp/configure.ac |  1 +
 4 files changed, 103 insertions(+), 1 deletion(-)

diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index 307cf3add94..77145768a3d 100644
--- a/libcpp/ChangeLog
+++ b/libcpp/ChangeLog
@@ -1,3 +1,10 @@
+2020-04-22  Sergei Trofimovich  
+
+   PR preprocessor/94657: use $AR, not 'ar'
+   * Makefile.in: use @AR@ placeholder
+   * configure.ac: use AC_CHECK_TOOL to find 'ar'
+   * configure: regenerate
+
 2020-02-14  Jakub Jelinek  
 
Partially implement P1042R1: __VA_OPT__ wording clarifications
diff --git a/libcpp/Makefile.in b/libcpp/Makefile.in
index 8f8c8f65eb3..af7a0c6f73e 100644
--- a/libcpp/Makefile.in
+++ b/libcpp/Makefile.in
@@ -25,7 +25,7 @@ srcdir = @srcdir@
 top_builddir = .
 VPATH = @srcdir@
 INSTALL = @INSTALL@
-AR = ar
+AR = @AR@
 ARFLAGS = cru
 ACLOCAL = @ACLOCAL@
 AUTOCONF = @AUTOCONF@
diff --git a/libcpp/configure b/libcpp/configure
index 11da199083b..a6dcf5dcb61 100755
--- a/libcpp/configure
+++ b/libcpp/configure
@@ -657,6 +657,7 @@ ACLOCAL
 EGREP
 GREP
 CPP
+AR
 RANLIB
 ac_ct_CXX
 CXXFLAGS
@@ -1039,6 +1040,7 @@ do
   | -silent | --silent | --silen | --sile | --sil)
 silent=yes ;;
 
+
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
 ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -4008,6 +4010,98 @@ else
   RANLIB="$ac_cv_prog_RANLIB"
 fi
 
+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
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_AR+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test -n "$AR"; then
+  ac_cv_prog_AR="$AR" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+for ac_exec_ext in '' $ac_executable_extensions; do
+  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ac_cv_prog_AR="${ac_tool_prefix}ar"
+$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" 
>&5
+break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+fi
+fi
+AR=$ac_cv_prog_AR
+if test -n "$AR"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AR" >&5
+$as_echo "$AR" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+
+fi
+if test -z "$ac_cv_prog_AR"; then
+  ac_ct_AR=$AR
+  # Extract the first word of "ar", so it can be a program name with args.
+set dummy ar; ac_word=$2
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
+$as_echo_n "checking for $ac_word... " >&6; }
+if ${ac_cv_prog_ac_ct_AR+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test -n "$ac_ct_AR"; then
+  ac_cv_prog_ac_ct_AR="$ac_ct_AR" # Let the user override the test.
+else
+as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+for ac_exec_ext in '' $ac_executable_extensions; do
+  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
+ac_cv_prog_ac_ct_AR="ar"
+$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" 
>&5
+break 2
+  fi
+done
+  done
+IFS=$as_save_IFS
+
+fi
+fi
+ac_ct_AR=$ac_cv_prog_ac_ct_AR
+if test -n "$ac_ct_AR"; then
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_AR" >&5
+$as_echo "$ac_ct_AR" >&6; }
+else
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
+$as_echo "no" >&6; }
+fi
+
+  if test "x$ac_ct_AR" = x; then
+AR=""
+  else
+case $cross_compiling:$ac_tool_warned in
+yes:)
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not 
prefixed with host triplet" >&5
+$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" 
>&2;}
+ac_tool_warned=yes ;;
+esac
+AR=$ac_ct_AR
+  fi
+else
+  AR="$ac_cv_prog_AR"
+fi
+
 
 
 ac_ext=c
diff --git a/libcpp/configure.ac b/libcpp/configure.ac
index 1779562a3a7..9ccfb02aa13 100644
--- a/libcpp/configure.ac
+++ b/libcpp/configure.ac
@@ -12,6 +12,7 @@ AC_PROG_INSTALL
 AC_PROG_CC
 AC_PROG_CXX
 AC_PROG_RANLIB
+AC_CHECK_TOOL(AR, ar)
 
 AC_USE_SYSTEM_EXTENSIONS
 AC_SYS_LARGEFILE
-- 
2.26.2

[committed 8/8] libstdc++: Define __cpp_lib_execution feature test macro

[Jonathan Wakely via Gcc-patches]

This macro has never been defined by libstdc++, despite supporting the
parallel algorithms. It should have a different value for C++17 and
C++20, because P1001R2 should not be supported in C++17, but
unsequenced_policy is defined for C++17 (see PR p4702).

* include/std/execution (__cpp_lib_execution): Define to indicate
support for P0024R2 and P1001R2.
* include/std/version (__cpp_lib_execution): Define.
* testsuite/25_algorithms/pstl/feature_test.cc: Only test macro
defined by , move other tests to new tests ...
* testsuite/25_algorithms/pstl/feature_test-2.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-3.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-4.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-5.cc: New test.
---
 libstdc++-v3/ChangeLog| 10 ++
 libstdc++-v3/include/std/execution|  1 +
 libstdc++-v3/include/std/version  |  2 ++
 .../25_algorithms/pstl/feature_test-2.cc  | 27 +++
 .../25_algorithms/pstl/feature_test-3.cc  | 34 +++
 .../25_algorithms/pstl/feature_test-4.cc  | 33 ++
 .../25_algorithms/pstl/feature_test-5.cc  | 28 +++
 .../25_algorithms/pstl/feature_test.cc| 27 ++-
 8 files changed, 137 insertions(+), 25 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-2.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-3.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-4.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-5.cc

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index cce254968fb..fb0c1acd268 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,15 @@
 2020-04-22  Jonathan Wakely  
 
+   * include/std/execution (__cpp_lib_execution): Define to indicate
+   support for P0024R2 and P1001R2.
+   * include/std/version (__cpp_lib_execution): Define.
+   * testsuite/25_algorithms/pstl/feature_test.cc: Only test macro
+   defined by , move other tests to new tests ...
+   * testsuite/25_algorithms/pstl/feature_test-2.cc: New test.
+   * testsuite/25_algorithms/pstl/feature_test-3.cc: New test.
+   * testsuite/25_algorithms/pstl/feature_test-4.cc: New test.
+   * testsuite/25_algorithms/pstl/feature_test-5.cc: New test.
+
* include/bits/stl_iterator.h (__cpp_lib_array_constexpr): Define
different values for C++17 and C++20, to indicate different feature
sets. Update value for C++20 to indicate P1032R1 support.
diff --git a/libstdc++-v3/include/std/execution 
b/libstdc++-v3/include/std/execution
index ac78af8eac3..cdd852deb14 100644
--- a/libstdc++-v3/include/std/execution
+++ b/libstdc++-v3/include/std/execution
@@ -50,6 +50,7 @@
 
 // Feature test macro for parallel algorithms
 # define __cpp_lib_parallel_algorithm 201603L
+# define __cpp_lib_execution 201902L
 
 #endif // C++17
 
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 57a05259d98..3024f1caf8b 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -127,6 +127,7 @@
 #define __cpp_lib_clamp 201603
 #define __cpp_lib_constexpr_char_traits 201611
 #define __cpp_lib_enable_shared_from_this 201603
+#define __cpp_lib_execution 201902L // FIXME: should be 201603L
 #define __cpp_lib_filesystem 201703
 #define __cpp_lib_gcd 201606
 #define __cpp_lib_gcd_lcm 201606
@@ -188,6 +189,7 @@
 #define __cpp_lib_array_constexpr 201811L
 #define __cpp_lib_assume_aligned 201811L
 #define __cpp_lib_bind_front 201907L
+// FIXME: #define __cpp_lib_execution 201902L
 #define __cpp_lib_integer_comparison_functions 202002L
 #define __cpp_lib_constexpr_algorithms 201806L
 #define __cpp_lib_constexpr_complex 201711L
diff --git a/libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-2.cc 
b/libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-2.cc
new file mode 100644
index 000..3e74f89bc41
--- /dev/null
+++ b/libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-2.cc
@@ -0,0 +1,27 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// 

[committed 7/8] libstdc++: Update (and revert) value of __cpp_lib_array_constexpr

[Jonathan Wakely via Gcc-patches]

This macro should have been updated to 201811 when the last C++20
changes were implemented. However those changes are not enabled for
C++17 mode, so the macro should only have the new value in C++20 mode.

This change ensures that the macro is defined to 201603 for C++17 and
201811 for C++20.

* include/bits/stl_iterator.h (__cpp_lib_array_constexpr): Define
different values for C++17 and C++20, to indicate different feature
sets. Update value for C++20 to indicate P1032R1 support.
* include/std/version (__cpp_lib_array_constexpr): Likewise.
* testsuite/23_containers/array/comparison_operators/constexpr.cc:
Check feature test macro.
* testsuite/23_containers/array/element_access/constexpr_c++17.cc:
New test.
* testsuite/23_containers/array/requirements/constexpr_fill.cc: Check
feature test macro.
* testsuite/23_containers/array/requirements/constexpr_iter.cc: Test
in C++17 mode and check feature test macro.
---
 libstdc++-v3/ChangeLog| 13 +
 libstdc++-v3/include/bits/stl_iterator.h  |  6 +-
 libstdc++-v3/include/std/version  |  4 +-
 .../array/comparison_operators/constexpr.cc   |  6 ++
 .../array/element_access/constexpr_c++17.cc   | 57 +++
 .../array/requirements/constexpr_fill.cc  |  6 ++
 .../array/requirements/constexpr_iter.cc  | 12 +++-
 7 files changed, 99 insertions(+), 5 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/23_containers/array/element_access/constexpr_c++17.cc

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 4fec7b21029..cce254968fb 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,18 @@
 2020-04-22  Jonathan Wakely  
 
+   * include/bits/stl_iterator.h (__cpp_lib_array_constexpr): Define
+   different values for C++17 and C++20, to indicate different feature
+   sets. Update value for C++20 to indicate P1032R1 support.
+   * include/std/version (__cpp_lib_array_constexpr): Likewise.
+   * testsuite/23_containers/array/comparison_operators/constexpr.cc:
+   Check feature test macro.
+   * testsuite/23_containers/array/element_access/constexpr_c++17.cc:
+   New test.
+   * testsuite/23_containers/array/requirements/constexpr_fill.cc: Check
+   feature test macro.
+   * testsuite/23_containers/array/requirements/constexpr_iter.cc: Test
+   in C++17 mode and check feature test macro.
+
* include/std/utility (__cpp_lib_constexpr_algorithms): Do not define
here.
* testsuite/20_util/exchange/constexpr.cc: Do not expect macro to be
diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index 652f51c6e7f..d7e85b84041 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -69,8 +69,10 @@
 # include 
 #endif
 
-#if __cplusplus > 201402L
-# define __cpp_lib_array_constexpr 201803
+#if __cplusplus > 201703L
+# define __cpp_lib_array_constexpr 201811L
+#elif __cplusplus == 201703L
+# define __cpp_lib_array_constexpr 201603L
 #endif
 
 #if __cplusplus > 201703L
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 85bc142bc38..57a05259d98 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -120,7 +120,7 @@
 #if _GLIBCXX_HOSTED
 #define __cpp_lib_any 201606L
 #define __cpp_lib_apply 201603
-#define __cpp_lib_array_constexpr 201803
+#define __cpp_lib_array_constexpr 201603L
 #define __cpp_lib_as_const 201510
 #define __cpp_lib_boyer_moore_searcher 201603
 #define __cpp_lib_chrono 201611
@@ -184,6 +184,8 @@
 #define __cpp_lib_unwrap_ref 201811L
 
 #if _GLIBCXX_HOSTED
+#undef __cpp_lib_array_constexpr
+#define __cpp_lib_array_constexpr 201811L
 #define __cpp_lib_assume_aligned 201811L
 #define __cpp_lib_bind_front 201907L
 #define __cpp_lib_integer_comparison_functions 202002L
diff --git 
a/libstdc++-v3/testsuite/23_containers/array/comparison_operators/constexpr.cc 
b/libstdc++-v3/testsuite/23_containers/array/comparison_operators/constexpr.cc
index fd6029b159e..0f3a4159dea 100644
--- 
a/libstdc++-v3/testsuite/23_containers/array/comparison_operators/constexpr.cc
+++ 
b/libstdc++-v3/testsuite/23_containers/array/comparison_operators/constexpr.cc
@@ -20,6 +20,12 @@
 
 #include 
 
+#ifndef __cpp_lib_array_constexpr
+# error "Feature test macro for array constexpr is missing in "
+#elif __cpp_lib_array_constexpr < 201806L
+# error "Feature test macro for array constexpr has wrong value in "
+#endif
+
 constexpr std::array a1{{1, 2, 3}};
 constexpr std::array a2{{4, 5, 6}};
 constexpr std::array a3{{1, 2, 4}};
diff --git 
a/libstdc++-v3/testsuite/23_containers/array/element_access/constexpr_c++17.cc 
b/libstdc++-v3/testsuite/23_containers/array/element_access/constexpr_c++17.cc
new file mode 100644
index 000..56d1cf256be
--- /dev/null
+++ 

[committed 4/8] libstdc++: Rename __cpp_lib_constexpr_invoke macro

[Jonathan Wakely via Gcc-patches]

This macro was renamed after it was added to the working draft, but we
never renamed it  in libstdc++. We haven't made a release with the old
macro name, so I see no need to keep it around.

* include/std/functional (__cpp_lib_constexpr_invoke): Rename to
__cpp_lib_constexpr_functional.
* include/std/version (__cpp_lib_constexpr_invoke): Likewise.
* testsuite/20_util/function_objects/invoke/constexpr.cc: Adjust.
---
 libstdc++-v3/ChangeLog   | 5 +
 libstdc++-v3/include/std/functional  | 2 +-
 libstdc++-v3/include/std/version | 2 +-
 .../testsuite/20_util/function_objects/invoke/constexpr.cc   | 4 ++--
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 182f5dc4b7e..7053a63ee91 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,10 @@
 2020-04-22  Jonathan Wakely  
 
+   * include/std/functional (__cpp_lib_constexpr_invoke): Rename to
+   __cpp_lib_constexpr_functional.
+   * include/std/version (__cpp_lib_constexpr_invoke): Likewise.
+   * testsuite/20_util/function_objects/invoke/constexpr.cc: Adjust.
+
* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory): Define to
indicate P1006R1 support.
(__cpp_lib_to_address): Define to indicate P0653R2 support.
diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index faa7e85c114..2a9b2a003db 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -76,7 +76,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #if __cplusplus >= 201703L
 # define __cpp_lib_invoke 201411L
 # if __cplusplus > 201703L
-#  define __cpp_lib_constexpr_invoke 201907L
+#  define __cpp_lib_constexpr_functional 201907L
 # endif
 
   /// Invoke a callable object.
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 3b1fd700069..77255915c4d 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -190,7 +190,7 @@
 #define __cpp_lib_constexpr_algorithms 201806L
 #define __cpp_lib_constexpr_complex 201711L
 #define __cpp_lib_constexpr_dynamic_alloc 201907L
-#define __cpp_lib_constexpr_invoke 201907L
+#define __cpp_lib_constexpr_functional 201907L
 #define __cpp_lib_constexpr_memory 201811L
 #define __cpp_lib_constexpr_numeric 201911L
 #define __cpp_lib_erase_if 202002L
diff --git 
a/libstdc++-v3/testsuite/20_util/function_objects/invoke/constexpr.cc 
b/libstdc++-v3/testsuite/20_util/function_objects/invoke/constexpr.cc
index 89cb9ca0fcc..3df48d44f49 100644
--- a/libstdc++-v3/testsuite/20_util/function_objects/invoke/constexpr.cc
+++ b/libstdc++-v3/testsuite/20_util/function_objects/invoke/constexpr.cc
@@ -20,9 +20,9 @@
 
 #include 
 
-#ifndef __cpp_lib_constexpr_invoke
+#ifndef __cpp_lib_constexpr_functional
 # error "Feature test macro for constexpr invoke is missing"
-#elif __cpp_lib_constexpr_invoke < 201907L
+#elif __cpp_lib_constexpr_functional < 201907L
 # error "Feature test macro for constexpr invoke has wrong value"
 #endif
 
-- 
2.25.3

[committed 6/8] libstdc++: Do not define __cpp_lib_constexpr_algorithms in

[Jonathan Wakely via Gcc-patches]

The C++20 draft and SD-6 both say this should only be in  and
, not in .

* include/std/utility (__cpp_lib_constexpr_algorithms): Do not define
here.
* testsuite/20_util/exchange/constexpr.cc: Do not expect macro to be
defined by .
---
 libstdc++-v3/ChangeLog   | 5 +
 libstdc++-v3/include/std/utility | 8 ++--
 libstdc++-v3/testsuite/20_util/exchange/constexpr.cc | 6 --
 3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 4e86ec188a5..4fec7b21029 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,10 @@
 2020-04-22  Jonathan Wakely  
 
+   * include/std/utility (__cpp_lib_constexpr_algorithms): Do not define
+   here.
+   * testsuite/20_util/exchange/constexpr.cc: Do not expect macro to be
+   defined by .
+
* include/std/functional (__cpp_lib_concepts): Update macro value to
indicate P1964R2 support.
* include/std/version (__cpp_lib_concepts): Likewise.
diff --git a/libstdc++-v3/include/std/utility b/libstdc++-v3/include/std/utility
index dc6e8468af5..5f1675a7679 100644
--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -238,7 +238,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 get(const std::pair<_Tp1, _Tp2>&& __in) noexcept
 { return __pair_get<_Int>::__const_move_get(std::move(__in)); }
 
-#if __cplusplus > 201103L
+#if __cplusplus >= 201402L
 
 #define __cpp_lib_tuples_by_type 201304
 
@@ -284,10 +284,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #define __cpp_lib_exchange_function 201304
 
-#if __cplusplus > 201703L
-#  define __cpp_lib_constexpr_algorithms 201806L
-#endif
-
   /// Assign @p __new_val to @p __obj and return its previous value.
   template 
 _GLIBCXX20_CONSTEXPR
@@ -295,7 +291,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 exchange(_Tp& __obj, _Up&& __new_val)
 { return std::__exchange(__obj, std::forward<_Up>(__new_val)); }
 
-#endif
+#endif // C++14
 
   // Stores a tuple of indices.  Used by tuple and pair, and by bind() to
   // extract the elements in a tuple.
diff --git a/libstdc++-v3/testsuite/20_util/exchange/constexpr.cc 
b/libstdc++-v3/testsuite/20_util/exchange/constexpr.cc
index 3673772ea4b..ee6cbaebdee 100644
--- a/libstdc++-v3/testsuite/20_util/exchange/constexpr.cc
+++ b/libstdc++-v3/testsuite/20_util/exchange/constexpr.cc
@@ -20,12 +20,6 @@
 
 #include 
 
-#ifndef __cpp_lib_constexpr_algorithms
-# error "Feature-test macro for constexpr algorithms missing"
-#elif __cpp_lib_constexpr_algorithms < 201806L
-# error "Feature-test macro for constexpr algorithms has wrong value"
-#endif
-
 constexpr bool
 test()
 {
-- 
2.25.3

[committed 3/8] libstdc++: Add missing feature test macros

[Jonathan Wakely via Gcc-patches]

These macros all correspond to features that are already supported, but
the macro was not defined when the feature was implemented.

* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory): Define to
indicate P1006R1 support.
(__cpp_lib_to_address): Define to indicate P0653R2 support.
* include/bits/range_access.h (__cpp_lib_ssize): Define to indicate
P1227R2 support.
* include/bits/ranges_algo.h (__cpp_lib_shift): Define to indicate
P0769R2 support.
* include/std/atomic (__cpp_lib_atomic_float): Define to indicate
P0020R6 support.
* include/std/memory (__cpp_lib_assume_aligned): Define to indicate
P1007R3 support.
* include/std/memory_resource (__cpp_lib_polymorphic_allocator):
Define to indicate P0339R6 support.
* include/std/string_view (__cpp_lib_starts_ends_with): Define to
indicate P0457R2 support.
* include/std/type_traits (__cpp_lib_is_nothrow_convertible): Define
to indicate P0758R1 support.
(__cpp_lib_remove_cvref): Define to indicate P0550R2 support.
(__cpp_lib_type_identity): Define to indicate P0887R1 support.
* include/std/version (__cpp_lib_atomic_float)
(__cpp_lib_is_nothrow_convertible, __cpp_lib_remove_cvref)
(__cpp_lib_type_identity, __cpp_lib_assume_aligned)
(__cpp_lib_constexpr_memory, __cpp_lib_polymorphic_allocator)
(__cpp_lib_shift, __cpp_lib_ssize, __cpp_lib_starts_ends_with)
(__cpp_lib_to_address): Define.
* testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line number.
---
 libstdc++-v3/ChangeLog| 27 +++
 libstdc++-v3/include/bits/ptr_traits.h|  3 +++
 libstdc++-v3/include/bits/range_access.h  |  1 +
 libstdc++-v3/include/bits/ranges_algo.h   |  1 +
 libstdc++-v3/include/std/atomic   |  1 +
 libstdc++-v3/include/std/memory   |  1 +
 libstdc++-v3/include/std/memory_resource  |  1 +
 libstdc++-v3/include/std/string_view  |  1 +
 libstdc++-v3/include/std/type_traits  |  4 +++
 libstdc++-v3/include/std/version  | 12 +
 .../testsuite/20_util/to_address/1_neg.cc |  2 +-
 11 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 4fd72daa942..182f5dc4b7e 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,32 @@
 2020-04-22  Jonathan Wakely  
 
+   * include/bits/ptr_traits.h (__cpp_lib_constexpr_memory): Define to
+   indicate P1006R1 support.
+   (__cpp_lib_to_address): Define to indicate P0653R2 support.
+   * include/bits/range_access.h (__cpp_lib_ssize): Define to indicate
+   P1227R2 support.
+   * include/bits/ranges_algo.h (__cpp_lib_shift): Define to indicate
+   P0769R2 support.
+   * include/std/atomic (__cpp_lib_atomic_float): Define to indicate
+   P0020R6 support.
+   * include/std/memory (__cpp_lib_assume_aligned): Define to indicate
+   P1007R3 support.
+   * include/std/memory_resource (__cpp_lib_polymorphic_allocator):
+   Define to indicate P0339R6 support.
+   * include/std/string_view (__cpp_lib_starts_ends_with): Define to
+   indicate P0457R2 support.
+   * include/std/type_traits (__cpp_lib_is_nothrow_convertible): Define
+   to indicate P0758R1 support.
+   (__cpp_lib_remove_cvref): Define to indicate P0550R2 support.
+   (__cpp_lib_type_identity): Define to indicate P0887R1 support.
+   * include/std/version (__cpp_lib_atomic_float)
+   (__cpp_lib_is_nothrow_convertible, __cpp_lib_remove_cvref)
+   (__cpp_lib_type_identity, __cpp_lib_assume_aligned)
+   (__cpp_lib_constexpr_memory, __cpp_lib_polymorphic_allocator)
+   (__cpp_lib_shift, __cpp_lib_ssize, __cpp_lib_starts_ends_with)
+   (__cpp_lib_to_address): Define.
+   * testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line number.
+
* include/bits/stl_map.h (__cpp_lib_map_insertion): Remove old
macro.
* include/bits/unordered_map.h (__cpp_lib_unordered_map_insertion):
diff --git a/libstdc++-v3/include/bits/ptr_traits.h 
b/libstdc++-v3/include/bits/ptr_traits.h
index 8fd91bf7bf2..541abab29e1 100644
--- a/libstdc++-v3/include/bits/ptr_traits.h
+++ b/libstdc++-v3/include/bits/ptr_traits.h
@@ -35,6 +35,7 @@
 #include 
 
 #if __cplusplus > 201703L
+#define __cpp_lib_constexpr_memory 201811L
 namespace __gnu_debug { struct _Safe_iterator_base; }
 #endif
 
@@ -180,6 +181,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return std::__to_address(__ptr.operator->());
 }
 
+#define __cpp_lib_to_address 201711L
+
   /**
* @brief Obtain address referenced by a pointer to an object
* @param __ptr A pointer to an object
diff --git a/libstdc++-v3/include/bits/range_access.h 
b/libstdc++-v3/include/bits/range_access.h
index acd701e1385..82d9e2180c5 100644
--- 

[committed 5/8] libstdc++: Update __cpp_lib_concepts value

[Jonathan Wakely via Gcc-patches]

* include/std/functional (__cpp_lib_concepts): Update macro value to
indicate P1964R2 support.
* include/std/version (__cpp_lib_concepts): Likewise.
* testsuite/std/concepts/1.cc: Adjust expected value.
* testsuite/std/concepts/2.cc: Likewise.
---
 libstdc++-v3/ChangeLog   | 6 ++
 libstdc++-v3/include/std/concepts| 2 +-
 libstdc++-v3/include/std/version | 2 +-
 libstdc++-v3/testsuite/std/concepts/1.cc | 2 +-
 libstdc++-v3/testsuite/std/concepts/2.cc | 2 +-
 5 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 7053a63ee91..4e86ec188a5 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,11 @@
 2020-04-22  Jonathan Wakely  
 
+   * include/std/functional (__cpp_lib_concepts): Update macro value to
+   indicate P1964R2 support.
+   * include/std/version (__cpp_lib_concepts): Likewise.
+   * testsuite/std/concepts/1.cc: Adjust expected value.
+   * testsuite/std/concepts/2.cc: Likewise.
+
* include/std/functional (__cpp_lib_constexpr_invoke): Rename to
__cpp_lib_constexpr_functional.
* include/std/version (__cpp_lib_constexpr_invoke): Likewise.
diff --git a/libstdc++-v3/include/std/concepts 
b/libstdc++-v3/include/std/concepts
index e8ce1adc93a..9ffed7007d9 100644
--- a/libstdc++-v3/include/std/concepts
+++ b/libstdc++-v3/include/std/concepts
@@ -47,7 +47,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-#define __cpp_lib_concepts 201806L
+#define __cpp_lib_concepts 202002L
 
   // [concepts.lang], language-related concepts
 
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 77255915c4d..85bc142bc38 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -168,7 +168,7 @@
 #define __cpp_lib_bounded_array_traits 201902L
 // __cpp_lib_char8_t is defined in 
 #if __cpp_concepts >= 201907L
-# define __cpp_lib_concepts 201806L
+# define __cpp_lib_concepts 202002L
 #endif
 #if __cpp_impl_destroying_delete
 # define __cpp_lib_destroying_delete 201806L
diff --git a/libstdc++-v3/testsuite/std/concepts/1.cc 
b/libstdc++-v3/testsuite/std/concepts/1.cc
index 41726faa731..4f5812ce121 100644
--- a/libstdc++-v3/testsuite/std/concepts/1.cc
+++ b/libstdc++-v3/testsuite/std/concepts/1.cc
@@ -22,6 +22,6 @@
 
 #ifndef __cpp_lib_concepts
 # error "Feature test macro for concepts is missing in "
-#elif __cpp_lib_concepts < 201806L
+#elif __cpp_lib_concepts < 202002L
 # error "Feature test macro for concepts has wrong value in "
 #endif
diff --git a/libstdc++-v3/testsuite/std/concepts/2.cc 
b/libstdc++-v3/testsuite/std/concepts/2.cc
index 706de7dd913..6967c8454a9 100644
--- a/libstdc++-v3/testsuite/std/concepts/2.cc
+++ b/libstdc++-v3/testsuite/std/concepts/2.cc
@@ -22,6 +22,6 @@
 
 #ifndef __cpp_lib_concepts
 # error "Feature test macro for concepts is missing in "
-#elif __cpp_lib_concepts < 201806L
+#elif __cpp_lib_concepts < 202002L
 # error "Feature test macro for concepts has wrong value in "
 #endif
-- 
2.25.3

[committed 2/8] libstdc++: Remove non-standard feature test macros

[Jonathan Wakely via Gcc-patches]

These macros were replaced by __cpp_lib_map_try_emplace and
__cpp_lib_unordered_map_try_emplace, because those names are more
descriptive. We've kept both old and new names so far, but I think we
can remove the old ones now.

* include/bits/stl_map.h (__cpp_lib_map_insertion): Remove old
macro.
* include/bits/unordered_map.h (__cpp_lib_unordered_map_insertion):
Likewise.
* include/std/version (__cpp_lib_map_insertion)
(__cpp_lib_unordered_map_insertion): Remove.
---
 libstdc++-v3/ChangeLog| 7 +++
 libstdc++-v3/include/bits/stl_map.h   | 1 -
 libstdc++-v3/include/bits/unordered_map.h | 1 -
 libstdc++-v3/include/std/version  | 2 --
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index dc0b1eecfb0..4fd72daa942 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,12 @@
 2020-04-22  Jonathan Wakely  
 
+   * include/bits/stl_map.h (__cpp_lib_map_insertion): Remove old
+   macro.
+   * include/bits/unordered_map.h (__cpp_lib_unordered_map_insertion):
+   Likewise.
+   * include/std/version (__cpp_lib_map_insertion)
+   (__cpp_lib_unordered_map_insertion): Remove.
+
* include/std/condition_variable (__cpp_lib_jthread): Remove
redundant definition.
* include/std/stop_token (__cpp_lib_jthread): Update macro value to
diff --git a/libstdc++-v3/include/bits/stl_map.h 
b/libstdc++-v3/include/bits/stl_map.h
index 5039efd86b7..2772d11462e 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -894,7 +894,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{ _M_t._M_insert_range_unique(__first, __last); }
 
 #if __cplusplus > 201402L
-#define __cpp_lib_map_insertion 201411
   /**
*  @brief Attempts to insert or assign a std::pair into the %map.
*  @param __kKey to use for finding a possibly existing pair in
diff --git a/libstdc++-v3/include/bits/unordered_map.h 
b/libstdc++-v3/include/bits/unordered_map.h
index ab1b1d52442..0071d62e462 100644
--- a/libstdc++-v3/include/bits/unordered_map.h
+++ b/libstdc++-v3/include/bits/unordered_map.h
@@ -657,7 +657,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
 
 #if __cplusplus > 201402L
-#define __cpp_lib_unordered_map_insertion 201411
   /**
*  @brief Attempts to insert a std::pair into the %unordered_map.
*  @param __kKey to use for finding a possibly existing pair in
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index dafb09f982a..48547c63014 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -134,7 +134,6 @@
 #define __cpp_lib_invoke 201411L
 #define __cpp_lib_lcm 201606
 #define __cpp_lib_make_from_tuple 201606
-#define __cpp_lib_map_insertion 201411
 #define __cpp_lib_map_try_emplace 201411
 #define __cpp_lib_math_special_functions 201603L
 #ifdef _GLIBCXX_HAS_GTHREADS
@@ -156,7 +155,6 @@
 #define __cpp_lib_shared_ptr_weak_type 201606
 #define __cpp_lib_string_view 201803
 // #define __cpp_lib_to_chars 201611L
-#define __cpp_lib_unordered_map_insertion 201411
 #define __cpp_lib_unordered_map_try_emplace 201411
 #define __cpp_lib_variant 201606L
 #endif
-- 
2.25.3

[committed 1/8] libstdc++: Update value of __cpp_lib_jthread macro

[Jonathan Wakely via Gcc-patches]

* include/std/condition_variable (__cpp_lib_jthread): Remove
redundant definition.
* include/std/stop_token (__cpp_lib_jthread): Update macro value to
indicate P1869R1 support.
* include/std/version (__cpp_lib_jthread): Update value.
* testsuite/30_threads/condition_variable_any/stop_token/1.cc: Check
for updated macro value.
* testsuite/30_threads/condition_variable_any/stop_token/2.cc:
Likewise.
* testsuite/30_threads/jthread/1.cc: Likewise.
* testsuite/30_threads/jthread/2.cc: Likewise.
* testsuite/30_threads/stop_token/1.cc: Likewise.
* testsuite/30_threads/stop_token/2.cc: Likewise.
---
 libstdc++-v3/ChangeLog | 14 ++
 libstdc++-v3/include/std/condition_variable|  3 +--
 libstdc++-v3/include/std/stop_token|  2 +-
 libstdc++-v3/include/std/version   |  2 +-
 .../condition_variable_any/stop_token/1.cc |  2 +-
 .../condition_variable_any/stop_token/2.cc |  2 +-
 libstdc++-v3/testsuite/30_threads/jthread/1.cc |  2 +-
 libstdc++-v3/testsuite/30_threads/jthread/2.cc |  2 +-
 libstdc++-v3/testsuite/30_threads/stop_token/1.cc  |  2 +-
 libstdc++-v3/testsuite/30_threads/stop_token/2.cc  |  2 +-
 10 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 2e1484fefb5..dc0b1eecfb0 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5 +1,19 @@
 2020-04-22  Jonathan Wakely  
 
+   * include/std/condition_variable (__cpp_lib_jthread): Remove
+   redundant definition.
+   * include/std/stop_token (__cpp_lib_jthread): Update macro value to
+   indicate P1869R1 support.
+   * include/std/version (__cpp_lib_jthread): Update value.
+   * testsuite/30_threads/condition_variable_any/stop_token/1.cc: Check
+   for updated macro value.
+   * testsuite/30_threads/condition_variable_any/stop_token/2.cc:
+   Likewise.
+   * testsuite/30_threads/jthread/1.cc: Likewise.
+   * testsuite/30_threads/jthread/2.cc: Likewise.
+   * testsuite/30_threads/stop_token/1.cc: Likewise.
+   * testsuite/30_threads/stop_token/2.cc: Likewise.
+
* testsuite/21_strings/basic_string/erasure.cc: Check for
__cpp_lib_erase_if macro.
* testsuite/23_containers/deque/erasure.cc: Add header name to #error
diff --git a/libstdc++-v3/include/std/condition_variable 
b/libstdc++-v3/include/std/condition_variable
index cc7f99f6921..2db9dff6c31 100644
--- a/libstdc++-v3/include/std/condition_variable
+++ b/libstdc++-v3/include/std/condition_variable
@@ -47,8 +47,7 @@
 #include 
 
 #if __cplusplus > 201703L
-#define __cpp_lib_jthread 201907L
-#include 
+# include 
 #endif
 
 #if defined(_GLIBCXX_HAS_GTHREADS)
diff --git a/libstdc++-v3/include/std/stop_token 
b/libstdc++-v3/include/std/stop_token
index 87beb08c71d..847d12f7454 100644
--- a/libstdc++-v3/include/std/stop_token
+++ b/libstdc++-v3/include/std/stop_token
@@ -34,7 +34,7 @@
 #include 
 
 #ifdef _GLIBCXX_HAS_GTHREADS
-# define __cpp_lib_jthread 201907L
+# define __cpp_lib_jthread 201911L
 # include 
 # if __has_include()
 #  include 
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 6d7dcc46023..dafb09f982a 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -191,7 +191,7 @@
 #define __cpp_lib_erase_if 202002L
 #define __cpp_lib_interpolate 201902L
 #ifdef _GLIBCXX_HAS_GTHREADS
-# define __cpp_lib_jthread 201907L
+# define __cpp_lib_jthread 201911L
 #endif
 #define __cpp_lib_list_remove_return_type 201806L
 #define __cpp_lib_math_constants 201907L
diff --git 
a/libstdc++-v3/testsuite/30_threads/condition_variable_any/stop_token/1.cc 
b/libstdc++-v3/testsuite/30_threads/condition_variable_any/stop_token/1.cc
index 59dafeb2d86..5b71cfb979f 100644
--- a/libstdc++-v3/testsuite/30_threads/condition_variable_any/stop_token/1.cc
+++ b/libstdc++-v3/testsuite/30_threads/condition_variable_any/stop_token/1.cc
@@ -22,6 +22,6 @@
 
 #ifndef __cpp_lib_jthread
 # error "Feature-test macro for jthread missing in "
-#elif __cpp_lib_jthread != 201907L
+#elif __cpp_lib_jthread != 201911L
 # error "Feature-test macro for jthread has wrong value in 
"
 #endif
diff --git 
a/libstdc++-v3/testsuite/30_threads/condition_variable_any/stop_token/2.cc 
b/libstdc++-v3/testsuite/30_threads/condition_variable_any/stop_token/2.cc
index 7254024bbb3..0f017e43996 100644
--- a/libstdc++-v3/testsuite/30_threads/condition_variable_any/stop_token/2.cc
+++ b/libstdc++-v3/testsuite/30_threads/condition_variable_any/stop_token/2.cc
@@ -22,6 +22,6 @@
 
 #ifndef __cpp_lib_jthread
 # error "Feature-test macro for jthread missing in "
-#elif __cpp_lib_jthread != 201907L
+#elif __cpp_lib_jthread != 201911L
 # error "Feature-test macro for jthread has wrong value in "
 #endif
diff --git 

[committed 0/8] libstdc++: Add/update/fix feature test macros

[Jonathan Wakely via Gcc-patches]

This series of patches fixes a number of omissions and errors in the
feature test macros we define.

Tested powerpc64le-linux, committed to master.

Jonathan Wakely (8):
  libstdc++: Update value of __cpp_lib_jthread macro
  libstdc++: Remove non-standard feature test macros
  libstdc++: Add missing feature test macros
  libstdc++: Rename __cpp_lib_constexpr_invoke macro
  libstdc++: Update __cpp_lib_concepts value
  libstdc++: Do not define __cpp_lib_constexpr_algorithms in 
  libstdc++: Update (and revert) value of __cpp_lib_array_constexpr
  libstdc++: Define __cpp_lib_execution feature test macro

 libstdc++-v3/ChangeLog| 87 +++
 libstdc++-v3/include/bits/ptr_traits.h|  3 +
 libstdc++-v3/include/bits/range_access.h  |  1 +
 libstdc++-v3/include/bits/ranges_algo.h   |  1 +
 libstdc++-v3/include/bits/stl_iterator.h  |  6 +-
 libstdc++-v3/include/bits/stl_map.h   |  1 -
 libstdc++-v3/include/bits/unordered_map.h |  1 -
 libstdc++-v3/include/std/atomic   |  1 +
 libstdc++-v3/include/std/concepts |  2 +-
 libstdc++-v3/include/std/condition_variable   |  3 +-
 libstdc++-v3/include/std/execution|  1 +
 libstdc++-v3/include/std/functional   |  2 +-
 libstdc++-v3/include/std/memory   |  1 +
 libstdc++-v3/include/std/memory_resource  |  1 +
 libstdc++-v3/include/std/stop_token   |  2 +-
 libstdc++-v3/include/std/string_view  |  1 +
 libstdc++-v3/include/std/type_traits  |  4 +
 libstdc++-v3/include/std/utility  |  8 +-
 libstdc++-v3/include/std/version  | 26 --
 .../testsuite/20_util/exchange/constexpr.cc   |  6 --
 .../function_objects/invoke/constexpr.cc  |  4 +-
 .../testsuite/20_util/to_address/1_neg.cc |  2 +-
 .../array/comparison_operators/constexpr.cc   |  6 ++
 .../array/element_access/constexpr_c++17.cc   | 57 
 .../array/requirements/constexpr_fill.cc  |  6 ++
 .../array/requirements/constexpr_iter.cc  | 12 ++-
 .../25_algorithms/pstl/feature_test-2.cc  | 27 ++
 .../25_algorithms/pstl/feature_test-3.cc  | 34 
 .../25_algorithms/pstl/feature_test-4.cc  | 33 +++
 .../25_algorithms/pstl/feature_test-5.cc  | 28 ++
 .../25_algorithms/pstl/feature_test.cc| 27 +-
 .../condition_variable_any/stop_token/1.cc|  2 +-
 .../condition_variable_any/stop_token/2.cc|  2 +-
 .../testsuite/30_threads/jthread/1.cc |  2 +-
 .../testsuite/30_threads/jthread/2.cc |  2 +-
 .../testsuite/30_threads/stop_token/1.cc  |  2 +-
 .../testsuite/30_threads/stop_token/2.cc  |  2 +-
 libstdc++-v3/testsuite/std/concepts/1.cc  |  2 +-
 libstdc++-v3/testsuite/std/concepts/2.cc  |  2 +-
 39 files changed, 345 insertions(+), 65 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/23_containers/array/element_access/constexpr_c++17.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-2.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-3.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-4.cc
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-5.cc

-- 
2.25.3

[PATCH] handle initialized flexible array members in __builtin_object_size [PR92815]

[Martin Sebor via Gcc-patches]

When computing the size of an object with a flexible array member
the object size pass doesn't consider that the initializer of such
an object can result in its size being in excess of the size of
the enclosing type.  As a result, stores into such objects by
string functions causes false positive warnings and can abort
at runtime.

The warnings are an old regression but as more of them make use
of the object size results more of them are affected by the bug.
The abort goes back to when support for _FORTIFY_SOURCE was added.

The same problem has already been independently fixed in GCC 10
for -Warray-bounds which doesn't use the object size checking pass,
but the object size bug still remains.  The attached patch corrects
it as well.

Tested on x86_64-linux.

Martin
PR middle-end/92815 - spurious -Wstringop-overflow writing into a flexible array of an extern struct

gcc/ChangeLog:

	PR middle-end/92815
	* tree-object-size.c (decl_init_size): New function.
	(addr_object_size): Call it.
	* tree.h (last_field): Declare.
	(first_field): Add attribute nonnull.

gcc/testsuite/ChangeLog:

	PR middle-end/92815
	* gcc.dg/Warray-bounds-56.c: Remove xfails.
	* gcc.dg/builtin-object-size-20.c: New test.

diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-56.c b/gcc/testsuite/gcc.dg/Warray-bounds-56.c
index 399c9b263b3..04c26a659ad 100644
--- a/gcc/testsuite/gcc.dg/Warray-bounds-56.c
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-56.c
@@ -42,8 +42,8 @@ struct Flex f3 = { 3, { 1, 2, 3 } };
 
 NOIPA void test_strcpy_flexarray (void)
 {
-  T (S (0), fx);// { dg-bogus "\\\[-Warray-bounds" "pr92815" { xfail *-*-*} }
-  T (S (9), fx);// { dg-bogus "\\\[-Warray-bounds" "pr92815" { xfail *-*-*} }
+  T (S (0), fx);// { dg-bogus "\\\[-Warray-bounds" "pr92815" }
+  T (S (9), fx);// { dg-bogus "\\\[-Warray-bounds" "pr92815" }
 
   T (S (0), f1);
   T (S (1), f1);// { dg-warning "\\\[-Warray-bounds" }
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-20.c b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
new file mode 100644
index 000..47821c06d76
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
@@ -0,0 +1,315 @@
+/* PR middle-end/92815 - spurious -Wstringop-overflow writing into
+   a flexible array of an extern struct
+   { dg-do compile }
+   { dg-options "-Wall -fdump-tree-optimized" } */
+
+#define ASSERT(expr) ((expr) ? (void)0 : fail (__LINE__))
+#define bos0(expr) __builtin_object_size (expr, 1)
+#define bos1(expr) __builtin_object_size (expr, 1)
+#define bos2(expr) __builtin_object_size (expr, 2)
+#define bos3(expr) __builtin_object_size (expr, 3)
+
+typedef __INT16_TYPE__ int16_t;
+typedef __INT32_TYPE__ int32_t;
+typedef __INT64_TYPE__ int64_t;
+typedef __SIZE_TYPE__  size_t;
+
+
+extern void fail (int);
+
+
+/* Verify sizes of a struct with a flexible array member and no padding.  */
+
+struct ACX { char n, a[]; };
+
+struct ACX ac0 = { };
+struct ACX ac1 = { 1, { 1 } };
+struct ACX ac2 = { 2, { 1, 2 } };
+struct ACX ac3 = { 3, { 1, 2, 3 } };
+
+extern struct ACX eacx;
+
+void facx (void)
+{
+  ASSERT (bos0 () == sizeof ac0);
+  ASSERT (bos0 () == 2);
+  ASSERT (bos0 () == 3);
+  ASSERT (bos0 () == 4);
+  ASSERT (bos0 () == (size_t)-1);
+
+  ASSERT (bos1 () == sizeof ac0);
+  ASSERT (bos1 () == 2);
+  ASSERT (bos1 () == 3);
+  ASSERT (bos1 () == 4);
+  ASSERT (bos1 () == (size_t)-1);
+
+  ASSERT (bos2 () == sizeof ac0);
+  ASSERT (bos2 () == 2);
+  ASSERT (bos2 () == 3);
+  ASSERT (bos2 () == 4);
+  ASSERT (bos2 () == sizeof eacx);
+
+  ASSERT (bos3 () == sizeof ac0);
+  ASSERT (bos3 () == 2);
+  ASSERT (bos3 () == 3);
+  ASSERT (bos3 () == 4);
+  ASSERT (bos3 () == sizeof eacx);
+}
+
+
+
+/* Verify sizes of a struct with a flexible array member and 1 byte
+   of tail padding.  */
+
+struct AI16CX { int16_t i; char n, a[]; };
+
+struct AI16CX ai16c0 = { 0 };
+struct AI16CX ai16c1 = { 0, 1, { 1 } };
+struct AI16CX ai16c2 = { 0, 2, { 1, 2 } };
+struct AI16CX ai16c3 = { 0, 3, { 1, 2, 3 } };
+struct AI16CX ai16c4 = { 0, 4, { 1, 2, 3, 4 } };
+struct AI16CX ai16c5 = { 0, 5, { 1, 2, 3, 4, 5 } };
+struct AI16CX ai16c6 = { 0, 6, { 1, 2, 3, 4, 5, 6 } };
+struct AI16CX ai16c7 = { 0, 7, { 1, 2, 3, 4, 5, 6, 7 } };
+struct AI16CX ai16c8 = { 0, 8, { 1, 2, 3, 4, 5, 6, 7, 8 } };
+
+extern struct AI16CX eai16cx;
+
+void fai16cx (void)
+{
+  ASSERT (bos0 () == sizeof ai16c0);
+  ASSERT (bos0 () == sizeof ai16c1);
+  ASSERT (bos0 () == sizeof ai16c2 + 1);
+  ASSERT (bos0 () == sizeof ai16c3 + 2);
+
+  ASSERT (bos0 () == sizeof ai16c4 + 3);
+  ASSERT (bos0 () == sizeof ai16c5 + 4);
+  ASSERT (bos0 () == sizeof ai16c6 + 5);
+  ASSERT (bos0 () == sizeof ai16c6 + 6);
+  ASSERT (bos0 () == sizeof ai16c6 + 7);
+
+  ASSERT (bos0 () == (size_t)-1);
+
+
+  ASSERT (bos1 () == sizeof ai16c0);
+  ASSERT (bos1 () == sizeof ai16c1);
+  ASSERT (bos1 () == sizeof ai16c2 + 1);
+  ASSERT (bos1 () == sizeof ai16c3 + 2);
+
+  ASSERT (bos1 () == sizeof ai16c4 + 

[PATCH] amdgcn: Add stub personality function

[Kwok Cheung Yeung]

Hello

This patch adds a stub implementation of __gxx_personality_v0, which is used in 
C++ exception handling. AMD GCN currently does not actually support exception 
handling (the unwind functions are all stubs too), so adding an extra stub 
function does not regress the current level of functionality any. This allows 
the following tests in the libgomp testsuite that were previously failing with a 
linker error to compile and run, provided that they do not throw any exceptions:


libgomp.c-c++-common/function-not-offloaded.c
libgomp.c++/for-15.C
libgomp.c++/for-24.C
libgomp.oacc-c-c++-common/routine-1.c
libgomp.oacc-c++/pr71959.C
libgomp.oacc-c++/routine-1-auto.C
libgomp.oacc-c++/routine-1-template-auto.C
libgomp.oacc-c++/routine-1-template-trailing-return-type.C
libgomp.oacc-c++/routine-1-template.C
libgomp.oacc-c++/routine-1-trailing-return-type.C

Tested with offloaded and standalone builds of GCC for AMD GCN. Okay for trunk?

Kwok

2020-04-22  Kwok Cheung Yeung  

libgcc/
* config/gcn/unwind-gcn.c (__gxx_personality_v0): New.

diff --git a/libgcc/config/gcn/unwind-gcn.c b/libgcc/config/gcn/unwind-gcn.c
index 813f03f..6508b45 100644
--- a/libgcc/config/gcn/unwind-gcn.c
+++ b/libgcc/config/gcn/unwind-gcn.c
@@ -35,3 +35,13 @@ _Unwind_GetIPInfo (struct _Unwind_Context *c, int 
*ip_before_insn)

 {
   return 0;
 }
+
+_Unwind_Reason_Code
+__gxx_personality_v0 (int version,
+ _Unwind_Action actions,
+ _Unwind_Exception_Class exception_class,
+ struct _Unwind_Exception *ue_header,
+ struct _Unwind_Context *context)
+{
+  return 0;
+}

[PATCH] attribs: Don't diagnose attribute exclusions during error recovery [PR94705]

[Jakub Jelinek via Gcc-patches]

Hi!

On the following testcase GCC ICEs, because last_decl is error_mark_node,
and diag_attr_exclusions assumes that if it is not NULL, it must be a decl.

The following patch just doesn't diagnose attribute exclusions if the
other decl is erroneous (and thus we've already reported errors for it).

Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?

2020-04-22  Jakub Jelinek  

PR c/94705
* attribs.c (decl_attribute): Don't diagnose attribute exclusions
if last_decl is error_mark_node or has such a TREE_TYPE.

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

--- gcc/attribs.c.jj2020-01-15 00:26:26.444529132 +0100
+++ gcc/attribs.c   2020-04-22 10:12:49.071442463 +0200
@@ -677,7 +677,8 @@ decl_attributes (tree *node, tree attrib
 reject incompatible attributes.  */
   bool built_in = flags & ATTR_FLAG_BUILT_IN;
   if (spec->exclude
- && (flag_checking || !built_in))
+ && (flag_checking || !built_in)
+ && !error_operand_p (last_decl))
{
  /* Always check attributes on user-defined functions.
 Check them on built-ins only when -fchecking is set.
--- gcc/testsuite/gcc.dg/pr94705.c.jj   2020-04-22 10:18:13.491485751 +0200
+++ gcc/testsuite/gcc.dg/pr94705.c  2020-04-22 10:19:06.077682332 +0200
@@ -0,0 +1,13 @@
+/* PR c/94705 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void foo ();
+
+int
+bar (void)
+{
+  foo (baz);   /* { dg-error "'baz' undeclared" } */
+   /* { dg-message "only once" "" { target *-*-* } .-1 } */
+  void __attribute__ ((noinline)) baz (void);
+}

Jakub

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Segher Boessenkool]

On Wed, Apr 22, 2020 at 11:58:38AM +0200, Richard Biener wrote:
> On Wed, Apr 22, 2020 at 11:26 AM Richard Sandiford
>  wrote:
> > Richard Biener via Gcc-patches  writes:
> > > On Mon, Apr 20, 2020 at 3:38 PM Segher Boessenkool
> > >  wrote:
> > >> On Mon, Apr 20, 2020 at 09:56:34AM +0200, Richard Biener wrote:
> > >> > On Fri, Apr 17, 2020 at 10:51 PM Segher Boessenkool
> > >> >  wrote:
> > >> > > > Yeah well, but RTL is not in SSA form
> > >> > >
> > >> > > "Webs" are not the *same* as SSA, in a few crucial ways; but they 
> > >> > > serve
> > >> > > similar purposes: they both make code transformations easier to do.
> > >> > > Both do this by having more different (independent) names.
> > >> > >
> > >> > > > and there's no RTL IL verification
> > >> > > > in place to track degradation.
> > >> > >
> > >> > > Adding this isn't hard in principle.  But currently it is violated 
> > >> > > all
> > >> > > over the place, including in backend code.
> > >> >
> > >> > It's a cheap excuse and clearly a lot of work.  But we've done it for 
> > >> > GIMPLE
> > >> > and it was clearly worth it.  If only for documentation purposes.
> > >>
> > >> Yes, I very much agree :-)  But how will we do this?  Make it warnings
> > >> only, and have those opt-in (for a port) even?
> > >
> > > Add -fcheck-rtl, when you're ready (per port?) make it default for
> > > bootstrap.  When you're even more "ready", turn it on with -fchecking
> > > (or --enable-checking=xyz).
> >
> > What kind of condition would we be checking?  That no register has two
> > definitions in the same block?  Or something stronger?
> 
> For the particular discussion no idea.  But we generally lack
> verification of what is "valid" RTL and what is not.

There is RTL checking, and it works very well...  But "valid" just means
"structurally valid", and other very local things.  If we want to check
some extra properties, we actually have to make the rules for those
first!  :-)

> > In some ways it feels like it would be easier to resurrect RTL SSA :-)

Why was RTL SSA abandoned?

It might well work to keep everything in SSA form all the way to RA.
Hrm, that doesn't sound bad at all :-)

(The PHIs need to be made explicit to something that resembles the
machine code we will end up with, very early in the pipeline, but it
could still also be some valid SSA form; and we can of course also
have hard registers in all RTL, so that needs to be dealt with sanely
some way as well  Lots of details, I don't see a crucial problem though,
probably means I need to look harder ;-) )


Segher

[PATCH] aarch64: eliminate redundant zero extend after bitwise negation

[Alex Coplan]

Hello,

The attached patch eliminates a redundant zero extend from the AArch64 backend. 
Given the following C code:

unsigned long long foo(unsigned a)
{
return ~a;
}

prior to this patch, AArch64 GCC at -O2 generates:

foo:
mvn w0, w0
uxtwx0, w0
ret

but the uxtw is redundant, since the mvn clears the upper half of the x0 
register. After applying this patch, GCC at -O2 gives:

foo:
mvn w0, w0
ret

Testing:
Added regression test which passes after applying the change to aarch64.md.
Full bootstrap and regression on aarch64-linux with no additional failures.

Thanks,
Alex

---

gcc/ChangeLog:

2020-04-22  Alex Coplan  

* config/aarch64/aarch64.md (*one_cmpl_zero_extend): New.

gcc/testsuite/ChangeLog:

2020-04-22  Alex Coplan  

* gcc.target/aarch64/mvn_zero_ext.c: New test.


patch.patch
Description: patch.patch

Re: [PATCH] coroutines, libstdc++-v3: Update headers to n4861 C++20 DIS.

[Jonathan Wakely via Gcc-patches]

On 22/04/20 19:44 +0100, Iain Sandoe wrote:

Hi,

this is a bit of ‘housekeeping’ bringing the coroutines library header into
line with the C++20 DIS.

Note that we allow coroutines on C++14+ (probably they would work on
C++11 too, but that’s untested).  So the  header reflects this by
exporting the __cpp_lib_coroutine define from then,

Tested on x86_64-darwin16 so far,
OK for master after regstrap on x86_64-Linux?
thanks
Iain

=

Add '__cpp_lib_coroutine' defined to 201902L per n4861 to 
Likewise to 

Update the inline namespace to __n4861.

libstdc++-v3/ChangeLog:

2020-04-22  Iain Sandoe  

* include/std/coroutine: Update the inline namespace to __n4861.
Add the __cpp_lib_coroutine define, set to 201902L.
* include/std/version: Add __cpp_lib_coroutine, set to 201902L.


The libstdc++ parts are OK, and I suppose the testsuite changes don't
really need approval because they follow from the libstdc++ parts and
so are "obvious".

Thanks.

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

[Jonathan Wakely via Gcc-patches]

On 22/04/20 15:33 -0400, Jason Merrill wrote:

On Wed, Apr 22, 2020 at 3:31 PM Jonathan Wakely  wrote:


On 22/04/20 15:19 -0400, Jason Merrill wrote:
>On 4/22/20 2:37 AM, Jonathan Wakely wrote:
>>These warnings have nothing to do with virtual functions, so "override"
>>is inappropriate. The warnings are just talking about defining special
>>members, so let's say that.
>>
>>  PR translation/94698
>>  * class.c (check_field_decls): Change "override" to "define" in
>>  -Weffc++ diagnostics.
>>
>>Tested powerpc64le-linux, OK for master?
>
>It is overriding the default(ed) definition, but I agree that
>"override" now suggests virtual functions.
>
>"define" is also wrong, though; it should be "declare".  OK with that
>change.

I did consider that, but decided that it has to be user-provided (i.e.
defined by the user) to avoid the problem, because a user-declared but
defaulted function would still not clean up pointer members.



True, but we don't warn in that case, and I think that's reasonable, as the
user is being explicit about their intent.  Adding a defaulted declaration
seems like a good way to silence the warning without changing ABI.


Ah good point.

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

[Jason Merrill via Gcc-patches]

On Wed, Apr 22, 2020 at 3:31 PM Jonathan Wakely  wrote:

> On 22/04/20 15:19 -0400, Jason Merrill wrote:
> >On 4/22/20 2:37 AM, Jonathan Wakely wrote:
> >>These warnings have nothing to do with virtual functions, so "override"
> >>is inappropriate. The warnings are just talking about defining special
> >>members, so let's say that.
> >>
> >>  PR translation/94698
> >>  * class.c (check_field_decls): Change "override" to "define" in
> >>  -Weffc++ diagnostics.
> >>
> >>Tested powerpc64le-linux, OK for master?
> >
> >It is overriding the default(ed) definition, but I agree that
> >"override" now suggests virtual functions.
> >
> >"define" is also wrong, though; it should be "declare".  OK with that
> >change.
>
> I did consider that, but decided that it has to be user-provided (i.e.
> defined by the user) to avoid the problem, because a user-declared but
> defaulted function would still not clean up pointer members.
>

True, but we don't warn in that case, and I think that's reasonable, as the
user is being explicit about their intent.  Adding a defaulted declaration
seems like a good way to silence the warning without changing ABI.

Jason

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

[Jonathan Wakely via Gcc-patches]

On 22/04/20 15:19 -0400, Jason Merrill wrote:

On 4/22/20 2:37 AM, Jonathan Wakely wrote:

These warnings have nothing to do with virtual functions, so "override"
is inappropriate. The warnings are just talking about defining special
members, so let's say that.

PR translation/94698
* class.c (check_field_decls): Change "override" to "define" in
-Weffc++ diagnostics.

Tested powerpc64le-linux, OK for master?


It is overriding the default(ed) definition, but I agree that 
"override" now suggests virtual functions.


"define" is also wrong, though; it should be "declare".  OK with that 
change.


I did consider that, but decided that it has to be user-provided (i.e.
defined by the user) to avoid the problem, because a user-declared but
defaulted function would still not clean up pointer members.

But either seems better than "override". I'll change it to declared (I
already committed the original version).

Re: [PATCH] c++: Add test for c++/93807

[Jason Merrill via Gcc-patches]

On 4/21/20 6:29 PM, Marek Polacek wrote:

This PR was initially accepts-invalid, but I think it's actually valid
C++20 code.  My reasoning is that in C++20 we no longer require the
declaration of operator== (#if-defed in the test), because C++20's
[temp.names]/2 says "A name is also considered to refer to a template
if it is an unqualified-id followed by a < and name lookup either finds
one or more functions or finds nothing." so when we're parsing

   constexpr friend bool operator==(T lhs, const Foo& rhs);

we treat "operator==" as a template name, because name lookup of
"operator==" found nothing and we have an operator-function-id, which is
an unqualified-id, and it's followed by a <.  So the declaration isn't
needed to treat "operator==" as a template-id.

Tested x86_64-pc-linux-gnu, ok for trunk?


OK.


PR c++/93807
* g++.dg/cpp2a/fn-template20.C: New test.
---
  gcc/testsuite/g++.dg/cpp2a/fn-template20.C | 34 ++
  1 file changed, 34 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/fn-template20.C

diff --git a/gcc/testsuite/g++.dg/cpp2a/fn-template20.C 
b/gcc/testsuite/g++.dg/cpp2a/fn-template20.C
new file mode 100644
index 000..c558ad1f2b6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/fn-template20.C
@@ -0,0 +1,34 @@
+// PR c++/93807
+// { dg-do compile { target c++11 } }
+
+// In C++17, we need the following declaration to treat operator== as
+// a template name.  In C++20, this is handled by [temp.names]/2.
+#if __cplusplus <= 201703L
+template 
+class Foo;
+template 
+constexpr bool operator==(T lhs, const Foo& rhs);
+#endif
+
+template 
+class Foo {
+public:
+  constexpr Foo(T k) : mK(k) {}
+
+  constexpr friend bool operator==(T lhs, const Foo& rhs);
+private:
+  T mK;
+};
+
+template 
+constexpr bool
+operator==(T lhs, const Foo& rhs)
+{
+  return lhs == rhs.mK;
+}
+
+int
+main ()
+{
+  return 1 == Foo(1) ? 0 : 1;
+}

base-commit: e76100ced607218a3bf26344fd57d7384a7c18b5

[PATCH v2] aarch64: Add TX3 machine model

[Joel Jones via Gcc-patches]

Yes, Bellsoft's contribution is to be covered under the Marvell copyright
assignment, as this is a work for hire.

Joel

>Yes, Bellsoft's contribution is to be covered under the Marvell copyright
>assignment, as this is a work for hire.
>
>Joel
>
>>>Hi Anton,
>>>
 -Original Message-
 From: Gcc-patches  On Behalf Of Anton
 Youdkevitch
 Sent: 20 April 2020 19:29
 To: gcc-patches@gcc.gnu.org
 Cc: jo...@marvell.com
 Subject: [PATCH v2] aarch64: Add TX3 machine model

 Here is the patch introducing thunderxt311 maching model
 for the scheduler. A name for the new chip was added to the
 list of the names to be recognized as a valid parameter for mcpu
 and mtune flags. The TX2 cost model was reused for TX3.

 The previously used "cryptic" name for the command line
 parameter is replaced with the same "thunderxt311" name.

 Bootstrapped on AArch64.
>>>
>>>Thanks for the patch. I had meant to ask, do you have a copyright assignment 
>>>in place?
>>>We'd need one to accept a contribution of this size.
>>>Thanks,
>>>Kyrill
>>>

 2020-04-20 Anton Youdkevitch 

 * config/aarch64/aarch64-cores.def: Add the chip name.
 * config/aarch64/aarch64-tune.md: Regenerated.
 * gcc/config/aarch64/aarch64.c: Add the cost tables for the chip.
 * gcc/config/aarch64/thunderx3t11.md: New file: add the new
 machine model for the scheduler
 * gcc/config/aarch64/aarch64.md: Include the new model.

 ---
  gcc/config/aarch64/aarch64-cores.def |   3 +
  gcc/config/aarch64/aarch64-tune.md   |   2 +-
  gcc/config/aarch64/aarch64.c |  27 +
  gcc/config/aarch64/aarch64.md|   1 +
  gcc/config/aarch64/thunderx3t11.md   | 686 +++
  5 files changed, 718 insertions(+), 1 deletion(-)
>>>
>>>
>>>
>>>
>

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

[Jason Merrill via Gcc-patches]

On 4/22/20 2:37 AM, Jonathan Wakely wrote:

These warnings have nothing to do with virtual functions, so "override"
is inappropriate. The warnings are just talking about defining special
members, so let's say that.

PR translation/94698
* class.c (check_field_decls): Change "override" to "define" in
-Weffc++ diagnostics.

Tested powerpc64le-linux, OK for master?


It is overriding the default(ed) definition, but I agree that "override" 
now suggests virtual functions.


"define" is also wrong, though; it should be "declare".  OK with that 
change.


Jason

Re: [PATCH] c++: Inherited constructor template arguments [PR94719]

[Jason Merrill via Gcc-patches]

On 4/22/20 2:55 PM, Patrick Palka wrote:

My fix for PR94549 broke constraints_satisfied_p in the case where the inherited
constructor decl points to an instantiation of a constructor template coming
from an instantiation of a class template.

This is because the DECL_TI_ARGS of the inherited constructor decl in this case
contains only the innermost level of template arguments (those for the
constructor template), but constraint satisfaction expects to have the full set
of template arguments.  This causes template argument substitution to fail in
various ways.

On the the hand, the DECL_TI_ARGS of the DECL_INHERITED_CTOR is a full set of
template arguments, but with the innermost level still in its dependent form,
which is the source of PR94549.  So if we could combine these two sets of
template arguments then we'd be golden.

This patch does just that, by effectively reverting the fix for PR94549 and
instead using add_outermost_template_args to combine the template arguments of
the inherited constructor with those of its DECL_INHERITED_CTOR.

Bootstrapped and regtested successfully on x86_64-pc-linux-gnu, and also
verified that the cmcstl2 testsuite now compiles successfully again.  Does this
look OK to commit?


OK.


(The fact that the DECL_TI_ARGS of the inherited constructor decl doesn't
contain the full set of template arguments seems to be inconsistent with the
documentation for DECL_TI_ARGS, which says it is "always the full set of
arguments required to instantiate this declaration from the most general
template specialized here." But the full set of arguments for foo::bar<5>
in the testcase below should be {{int},{5}}, not just {5}, I think?)
That is strange, yes.  The situation with template arguments and 
inherited constructors seems pretty confused.



gcc/cp/ChangeLog:

PR c++/94719
PR c++/94549
* constraint.cc (satisfy_declaration_constraints): If an inherited
constructor points to an instantiation of a constructor template,
remember and use the attached template arguments.

gcc/testsuite/ChangeLog:

PR c++/94719
PR c++/94549
* g++.dg/cpp2a/concepts-inherit-ctor9.C: New test.
---
  gcc/cp/constraint.cc  | 17 +++-
  .../g++.dg/cpp2a/concepts-inherit-ctor9.C | 20 +++
  2 files changed, 32 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor9.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c05fafe5da1..06161b8c8c4 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2736,12 +2736,17 @@ static tree
  satisfy_declaration_constraints (tree t, subst_info info)
  {
gcc_assert (DECL_P (t));
+  const tree saved_t = t;
  
-  if (!DECL_TEMPLATE_INFO (t))

-/* For inherited constructors without template information, consider
-   the original declaration; it has the correct template information
-   attached.  */
-t = strip_inheriting_ctors (t);
+  /* For inherited constructors, consider the original declaration;
+ it has the correct template information attached. */
+  t = strip_inheriting_ctors (t);
+  tree inh_ctor_targs = NULL_TREE;
+  if (t != saved_t)
+if (tree ti = DECL_TEMPLATE_INFO (saved_t))
+  /* The inherited constructor points to an instantiation of a constructor
+template; remember its template arguments.  */
+  inh_ctor_targs = TI_ARGS (ti);
  
/* Update the declaration for diagnostics.  */

info.in_decl = t;
@@ -2761,6 +2766,8 @@ satisfy_declaration_constraints (tree t, subst_info info)
/* The initial parameter mapping is the complete set of
 template arguments substituted into the declaration.  */
args = TI_ARGS (ti);
+  if (inh_ctor_targs)
+   args = add_outermost_template_args (args, inh_ctor_targs);
  }
else
  {
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor9.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor9.C
new file mode 100644
index 000..7d3201bff9f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor9.C
@@ -0,0 +1,20 @@
+// PR c++/94719
+// { dg-do compile { target concepts } }
+
+template
+struct bar
+{
+  template requires (N == 5)
+  bar() { }
+};
+
+template
+struct foo : bar
+{
+  using foo::bar::bar;
+};
+
+void baz()
+{
+  foo{};
+}

[PATCH] c++: Inherited constructor template arguments [PR94719]

[Patrick Palka via Gcc-patches]

My fix for PR94549 broke constraints_satisfied_p in the case where the inherited
constructor decl points to an instantiation of a constructor template coming
from an instantiation of a class template.

This is because the DECL_TI_ARGS of the inherited constructor decl in this case
contains only the innermost level of template arguments (those for the
constructor template), but constraint satisfaction expects to have the full set
of template arguments.  This causes template argument substitution to fail in
various ways.

On the the hand, the DECL_TI_ARGS of the DECL_INHERITED_CTOR is a full set of
template arguments, but with the innermost level still in its dependent form,
which is the source of PR94549.  So if we could combine these two sets of
template arguments then we'd be golden.

This patch does just that, by effectively reverting the fix for PR94549 and
instead using add_outermost_template_args to combine the template arguments of
the inherited constructor with those of its DECL_INHERITED_CTOR.

Bootstrapped and regtested successfully on x86_64-pc-linux-gnu, and also
verified that the cmcstl2 testsuite now compiles successfully again.  Does this
look OK to commit?

(The fact that the DECL_TI_ARGS of the inherited constructor decl doesn't
contain the full set of template arguments seems to be inconsistent with the
documentation for DECL_TI_ARGS, which says it is "always the full set of
arguments required to instantiate this declaration from the most general
template specialized here." But the full set of arguments for foo::bar<5>
in the testcase below should be {{int},{5}}, not just {5}, I think?)

gcc/cp/ChangeLog:

PR c++/94719
PR c++/94549
* constraint.cc (satisfy_declaration_constraints): If an inherited
constructor points to an instantiation of a constructor template,
remember and use the attached template arguments.

gcc/testsuite/ChangeLog:

PR c++/94719
PR c++/94549
* g++.dg/cpp2a/concepts-inherit-ctor9.C: New test.
---
 gcc/cp/constraint.cc  | 17 +++-
 .../g++.dg/cpp2a/concepts-inherit-ctor9.C | 20 +++
 2 files changed, 32 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor9.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c05fafe5da1..06161b8c8c4 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2736,12 +2736,17 @@ static tree
 satisfy_declaration_constraints (tree t, subst_info info)
 {
   gcc_assert (DECL_P (t));
+  const tree saved_t = t;
 
-  if (!DECL_TEMPLATE_INFO (t))
-/* For inherited constructors without template information, consider
-   the original declaration; it has the correct template information
-   attached.  */
-t = strip_inheriting_ctors (t);
+  /* For inherited constructors, consider the original declaration;
+ it has the correct template information attached. */
+  t = strip_inheriting_ctors (t);
+  tree inh_ctor_targs = NULL_TREE;
+  if (t != saved_t)
+if (tree ti = DECL_TEMPLATE_INFO (saved_t))
+  /* The inherited constructor points to an instantiation of a constructor
+template; remember its template arguments.  */
+  inh_ctor_targs = TI_ARGS (ti);
 
   /* Update the declaration for diagnostics.  */
   info.in_decl = t;
@@ -2761,6 +2766,8 @@ satisfy_declaration_constraints (tree t, subst_info info)
   /* The initial parameter mapping is the complete set of
 template arguments substituted into the declaration.  */
   args = TI_ARGS (ti);
+  if (inh_ctor_targs)
+   args = add_outermost_template_args (args, inh_ctor_targs);
 }
   else
 {
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor9.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor9.C
new file mode 100644
index 000..7d3201bff9f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor9.C
@@ -0,0 +1,20 @@
+// PR c++/94719
+// { dg-do compile { target concepts } }
+
+template
+struct bar
+{
+  template requires (N == 5)
+  bar() { }
+};
+
+template
+struct foo : bar
+{
+  using foo::bar::bar;
+};
+
+void baz()
+{
+  foo{};
+}
-- 
2.26.2.108.g048abe1751

[PATCH] coroutines, libstdc++-v3: Update headers to n4861 C++20 DIS.

[Iain Sandoe]

Hi,

this is a bit of ‘housekeeping’ bringing the coroutines library header into
line with the C++20 DIS.

Note that we allow coroutines on C++14+ (probably they would work on
C++11 too, but that’s untested).  So the  header reflects this by
exporting the __cpp_lib_coroutine define from then,

Tested on x86_64-darwin16 so far,
OK for master after regstrap on x86_64-Linux?
thanks
Iain

=

Add '__cpp_lib_coroutine' defined to 201902L per n4861 to 
Likewise to 

Update the inline namespace to __n4861.

libstdc++-v3/ChangeLog:

2020-04-22  Iain Sandoe  

* include/std/coroutine: Update the inline namespace to __n4861.
Add the __cpp_lib_coroutine define, set to 201902L.
* include/std/version: Add __cpp_lib_coroutine, set to 201902L.

gcc/testsuite/ChangeLog:

2020-04-22  Iain Sandoe  

* g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Adjust for
changed inline namespace.
* g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C: Likewise.
* g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C: Likewise
* g++.dg/coroutines/coro.h: Likewise
---
 .../g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C | 2 +-
 .../g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C | 2 +-
 .../g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C   | 2 +-
 gcc/testsuite/g++.dg/coroutines/coro.h   | 4 ++--
 libstdc++-v3/include/std/coroutine   | 9 ++---
 libstdc++-v3/include/std/version | 3 +++
 6 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C 
b/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C
index 1fdce1dad1d..06543a98824 100644
--- a/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C
+++ b/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C
@@ -6,7 +6,7 @@
 #include "coro1-allocators.h"
 
 struct coro1
-f ()  /* { dg-error {'operator new' is provided by 
'std::__n4835::coroutine_traits::promise_type' \{aka 
'coro1::promise_type'\} but is not usable with the function signature 'coro1 
f\(\)'} } */
+f ()  /* { dg-error {'operator new' is provided by 
'std::__n4861::coroutine_traits::promise_type' \{aka 
'coro1::promise_type'\} but is not usable with the function signature 'coro1 
f\(\)'} } */
 {
   co_return;
 }
diff --git a/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C 
b/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C
index be804796835..9a4ec34cdf3 100644
--- a/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C
+++ b/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C
@@ -6,7 +6,7 @@
 #include "coro1-allocators.h"
 
 struct coro1
-f ()  /* { dg-error {'operator delete' is provided by 
'std::__n4835::coroutine_traits::promise_type' \{aka 
'coro1::promise_type'\} but is not usable with the function signature 'coro1 
f\(\)'} } */
+f ()  /* { dg-error {'operator delete' is provided by 
'std::__n4861::coroutine_traits::promise_type' \{aka 
'coro1::promise_type'\} but is not usable with the function signature 'coro1 
f\(\)'} } */
 {
   co_return;
 }
diff --git a/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C 
b/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C
index eae2dada911..c0c0792d31d 100644
--- a/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C
+++ b/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C
@@ -9,7 +9,7 @@
 #include "coro1-allocators.h"
 
 struct coro1
-f () /* { dg-error 
{'coro1::promise_type::get_return_object_on_allocation_failure\(\)\(\)' is 
provided by 'std::__n4835::coroutine_traits::promise_type' \{aka 
'coro1::promise_type'\} but 'operator new' is not marked 'throw\(\)' or 
'noexcept'} } */
+f () /* { dg-error 
{'coro1::promise_type::get_return_object_on_allocation_failure\(\)\(\)' is 
provided by 'std::__n4861::coroutine_traits::promise_type' \{aka 
'coro1::promise_type'\} but 'operator new' is not marked 'throw\(\)' or 
'noexcept'} } */
 {
   co_return;
 }
diff --git a/gcc/testsuite/g++.dg/coroutines/coro.h 
b/gcc/testsuite/g++.dg/coroutines/coro.h
index a1bd38b8d12..fccfe418616 100644
--- a/gcc/testsuite/g++.dg/coroutines/coro.h
+++ b/gcc/testsuite/g++.dg/coroutines/coro.h
@@ -32,7 +32,7 @@ namespace coro = std::experimental;
 #  if __cpp_impl_coroutine
 
 namespace std {
-inline namespace __n4835 {
+inline namespace __n4861 {
 
 // 21.11.1 coroutine traits
 template struct coroutine_traits {
@@ -125,7 +125,7 @@ struct suspend_never {
   void await_resume() {}
 };
 
-} // namespace __n4835
+} // namespace __n4861
 } // namespace std
 
 namespace coro = std;
diff --git a/libstdc++-v3/include/std/coroutine 
b/libstdc++-v3/include/std/coroutine
index 2e45c451450..4fa1355c0ca 100644
--- a/libstdc++-v3/include/std/coroutine
+++ b/libstdc++-v3/include/std/coroutine
@@ -52,10 +52,13 @@
 
 namespace std _GLIBCXX_VISIBILITY (default)
 {
-  

[PATCH] [Stage1] Refactor tree-ssa-operands.c

[Giuliano Belinassi via Gcc-patches]

This patch refactors tree-ssa-operands.c by wrapping the global
variables into a class, and also removes unused code.

Just sending this for when Stage1 is back again.

I ran the testsuite and bootstraped in a x86_64 linux machine and
found no issues.

gcc/ChangeLog:
2020-04-22  Giuliano Belinassi  

* tree-ssa-operands.c (build_virtual_operands): New class.
(operands_bitmap_obstack): Remove.
(n_initialized): Remove.
(build_uses): Move to build_virtual_operands class.
(build_vuse): Same as above.
(build_vdef): Same as above.
(verify_ssa_operands): Same as above.
(finalize_ssa_uses): Same as above.
(cleanup_build_arrays): Same as above.
(finalize_ssa_stmt_operands): Same as above.
(start_ssa_stmt_operands): Same as above.
(append_use): Same as above.
(append_vdef): Same as above.
(add_virtual_operand): Same as above.
(add_stmt_operand): Same as above.
(get_mem_ref_operands): Same as above.
(get_tmr_operands): Same as above.
(maybe_add_call_vops): Same as above.
(get_asm_stmt_operands): Same as above.
(get_expr_operands): Same as above.
(parse_ssa_operands): Same as above.
(finalize_ssa_defs): Same as above.
(build_ssa_operands): Same as above, plus create a C-like wrapper.
(update_stmt_operands): Create an instance of build_virtual_operands.
>From b860b39045e1b90319caa7c75ad189514e4a5641 Mon Sep 17 00:00:00 2001
From: Giuliano Belinassi 
Date: Tue, 21 Apr 2020 19:38:37 -0300
Subject: [PATCH] [Stage1] Refactor tree-ssa-operands.c

Refactor tree-ssa-operands.c by wrapping the global
variables into a class, and also removes unused code.

gcc/ChangeLog:
2020-04-22  Giuliano Belinassi  

	* tree-ssa-operands.c (build_virtual_operands): New class.
	(operands_bitmap_obstack): Remove.
	(n_initialized): Remove.
	(build_uses): Move to build_virtual_operands class.
	(build_vuse): Same as above.
	(build_vdef): Same as above.
	(verify_ssa_operands): Same as above.
	(finalize_ssa_uses): Same as above.
	(cleanup_build_arrays): Same as above.
	(finalize_ssa_stmt_operands): Same as above.
	(start_ssa_stmt_operands): Same as above.
	(append_use): Same as above.
	(append_vdef): Same as above.
	(add_virtual_operand): Same as above.
	(add_stmt_operand): Same as above.
	(get_mem_ref_operands): Same as above.
	(get_tmr_operands): Same as above.
	(maybe_add_call_vops): Same as above.
	(get_asm_stmt_operands): Same as above.
	(get_expr_operands): Same as above.
	(parse_ssa_operands): Same as above.
	(finalize_ssa_defs): Same as above.
	(build_ssa_operands): Same as above, plus create a C-like wrapper.
	(update_stmt_operands): Create an instance of build_virtual_operands.
---
 gcc/tree-ssa-operands.c | 218 +++-
 1 file changed, 150 insertions(+), 68 deletions(-)

diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
index b525ee318a4..ae8734d17e2 100644
--- a/gcc/tree-ssa-operands.c
+++ b/gcc/tree-ssa-operands.c
@@ -99,23 +99,111 @@ along with GCC; see the file COPYING3.  If not see
 /* Operand is having its address taken.  */
 #define opf_address_taken (1 << 5)
 
-/* Array for building all the use operands.  */
-static vec build_uses;
+/* Class containing temporary per-stmt state.  */
 
-/* The built VDEF operand.  */
-static tree build_vdef;
+class build_virtual_operands
+{
+  public:
+build_virtual_operands ()
+  {
+	build_uses.create (10);
+	build_vuse = NULL_TREE;
+	build_vdef = NULL_TREE;
+  }
+
+~build_virtual_operands ()
+  {
+	cleanup_build_arrays ();
+	build_uses.release ();
+  }
+
+/* Create an operands cache for STMT.  */
+void build_ssa_operands (struct function *fn, gimple *stmt);
+
+/* Verifies SSA statement operands.  */
+DEBUG_FUNCTION bool verify_ssa_operands (struct function *fn, gimple *stmt);
+
+  private:
+/* Array for building all the use operands.  */
+vec build_uses;
+
+/* The built VDEF operand.  */
+tree build_vdef;
+
+/* The built VUSE operand.  */
+tree build_vuse;
+
+/* Takes elements from build_uses and turns them into use operands of STMT.  */
+inline void finalize_ssa_uses (struct function *fn, gimple *stmt);
+
+/* Clear the in_list bits and empty the build array for VDEFs and
+   VUSEs.  */
+inline void cleanup_build_arrays (void);
+
+/* Finalize all the build vectors, fill the new ones into INFO.  */
+inline void finalize_ssa_stmt_operands (struct function *fn, gimple *stmt);
+
+/* Start the process of building up operands vectors in INFO.  */
+inline void start_ssa_stmt_operands (void);
+
+/* Add USE_P to the list of pointers to operands.  */
+inline void append_use (tree *use_p);
 
-/* The built VUSE operand.  */
-static tree build_vuse;
+/* Add VAR to the set of variables that require a VDEF operator.  */
+inline void append_vdef (tree var);
 
-/* 

Re: [RFC][PR target PR90000] (rs6000) Compile time hog w/impossible asm constraint lra loop

[Jeff Law via Gcc-patches]

On Fri, 2020-04-10 at 16:40 -0500, will schmidt via Gcc-patches wrote:
> [RFC][PR target/9] Compile time hog w/impossible asm constraint lra loop
> 
> Hi,
>   RFC for a bandaid/patch to partially address target PR/9.
> 
> This adds an escape condition from the forever loop where 
> LRA gets stuck while attempting to handle constraints from an 
> instruction that has previously suffered an impossible constraint error.
> 
> This is somewhat inspired by MAX_RELOAD_INSNS_NUMBER as
> seen in lra-constraints.c lra_constraints().   This utilizes the
> existing counter variable lra_constraint_iter.
> 
> More needs to be done here, as this does replace a spin-forever
> situation with an ICE.
> 
> Thanks
> -Will
> 
> 
> gcc/
> 2020-04-10  Will Schmidt  
> 
>   * lra.c: Add include of rtl-error.h.
> (MAX_LRA_CONSTRAINT_PASSES): New define.
> (lra): Add check of lra_constraint_iter value.
Doesn't this argue that there's some other datastructure that needs to be 
updated
when we removed the impossible asm?

Jeff
> 

Re: [PING] [PATCH] [ARM] Adjust test expectations of unaligned-memcpy-2/3.c (PR 91614)

[Jeff Law via Gcc-patches]

On Thu, 2020-03-26 at 04:23 +0100, Bernd Edlinger wrote:
> Hi,
> 
> I am pinging this because PR 91614 has been raised to P2 now:
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html
It's been nearly a month since the ping and many since the patch was posted
originally.

I interpret Richard E's comments from Sept as a reject of the patch as-is.

I tend to agree with Richard in that testing assembly code for this is going to
be quite fragile and an execution test would be better.

Jeff

[PATCH] rs6000, Fix header comment for intrinsic function

[Carl Love via Gcc-patches]

GCC maintainers:

The following is a trivial patch to fix a comment describing the
intrinsic function _mm_movemask_epi8.  The comment was expanded to
clarify the layout of the returned result. 

The patch does not make any functional changes.

Please let me know if the patch is OK for mainline and backporting as
appropriate.

Thanks.

 Carl Love
---
rs6000, Fix header comment for intrinsic function _mm_movemask_epi8

gcc/ChangeLog

2020-04-22  Carl Love  

* config/rs6000/emmintrin.h (_mm_movemask_epi8): Fix comment for the
function.

Signed-off-by: Carl Love 
---
 gcc/config/rs6000/emmintrin.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/emmintrin.h b/gcc/config/rs6000/emmintrin.h
index 2462cf5bdac..0872a75c0de 100644
--- a/gcc/config/rs6000/emmintrin.h
+++ b/gcc/config/rs6000/emmintrin.h
@@ -2033,7 +2033,9 @@ _mm_min_epu8 (__m128i __A, __m128i __B)
 #ifdef _ARCH_PWR8
 /* Intrinsic functions that require PowerISA 2.07 minimum.  */
 
-/* Creates a 4-bit mask from the most significant bits of the SPFP values.  */
+/* Creates a 16-bit mask from the most significant bits of the sixteen 8-bit
+   values.  The 16-bit result is placed in bits[48:63], bits [0:47] and
+   bits [64:127] are  set to zero.  */
 extern __inline int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_movemask_epi8 (__m128i __A)
 {
-- 
2.17.1

Re: introduce target tmpnam and require it in tests relying on it

[Jeff Law via Gcc-patches]

On Fri, 2020-04-17 at 14:48 -0300, Alexandre Oliva wrote:
> On Apr  9, 2020, Alexandre Oliva  wrote:
> 
> > Some target C libraries that aren't recognized as freestanding don't
> > have filesystem support, so calling tmpnam, fopen/open and
> > remove/unlink fails to link.
> > This patch introduces a tmpnam effective target to the testsuite, and
> > requires it in the tests that call tmpnam.
> > Tested on x86_64-linux-gnu, and with a cross to arm-eabi.
> > Ok to install?
> > for  gcc/testsuite/ChangeLog
> > * lib/target-supports.exp (check_effective_target_tmpnam): New.
> > * gcc.c-torture/execute/fprintf-2.c: Require it.
> > * gcc.c-torture/execute/printf-2.c: Likewise.
> > * gcc.c-torture/execute/user-printf.c: Likewise.
> 
> Ping?
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543672.html
OK.
jeff

Re: [PATCH] Do not remove ifunc_resolver in LTO.

[Jan Hubicka]

> On Mon, 2020-04-20 at 11:34 +0200, Martin Liška wrote:
> > Hi.
> > 
> > The patch prevents a ifunc alias from removal in remove unreachable nodes.
> > Note that ifunc alias lives in a COMDAT section and so that
> > cgraph_node::can_remove_if_no_direct_calls_and_refs_p returned true for it.
> > 
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > I was unable to create a lto test-case where a linked binary could be
> > scanned for assembly.
> > 
> > Ready to be installed?
> > Thanks,
> > Martin
> > 
> > gcc/ChangeLog:
> > 
> > 2020-04-20  Martin Liska  
> > 
> > PR lto/94659
> > * cgraph.h (cgraph_node::can_remove_if_no_direct_calls_and_refs_p):
> > Do not remove ifunc_resolvers in remove unreachable nodes in LTO.
> OK
Is it intended to keep the comdat group alive even when the function is
not used by the current translation unit?

Honza
> jeff
> 

Re: [PATCH] Do not remove ifunc_resolver in LTO.

[Jeff Law via Gcc-patches]

On Mon, 2020-04-20 at 11:34 +0200, Martin Liška wrote:
> Hi.
> 
> The patch prevents a ifunc alias from removal in remove unreachable nodes.
> Note that ifunc alias lives in a COMDAT section and so that
> cgraph_node::can_remove_if_no_direct_calls_and_refs_p returned true for it.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> I was unable to create a lto test-case where a linked binary could be
> scanned for assembly.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-04-20  Martin Liska  
> 
>   PR lto/94659
>   * cgraph.h (cgraph_node::can_remove_if_no_direct_calls_and_refs_p):
>   Do not remove ifunc_resolvers in remove unreachable nodes in LTO.
OK
jeff

Re: [PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

[Jeff Law via Gcc-patches]

On Mon, 2020-04-20 at 14:18 +0100, Maciej W. Rozycki wrote:
> Fix a problem with the libffi testsuite using a method to determine the 
> compiler to use resulting in the tool being different from one the 
> library has been built with, and causing a catastrophic failure from the 
> inability to actually choose any compiler at all in a cross-compilation 
> configuration.
> 
> Address this problem by providing a DejaGNU configuration file defining 
> the compiler to use, via the CC_FOR_TARGET TCL variable, set from $CC by 
> autoconf, which will have all the required options set for the target 
> compiler to build executables in the environment configured, removing 
> failures like:
> 
> FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess
> errors)
> Excess errors:
> default_target_compile: No compiler to compile with
> UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 compilation
> failed to produce executable
> 
> and bringing overall test results for the `riscv64-linux-gnu' target 
> (here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
> emulation mode as the target board) from:
> 
>   === libffi Summary ===
> 
> # of unexpected failures  708
> # of unresolved testcases 708
> # of unsupported tests30
> 
> to:
> 
>   === libffi Summary ===
> 
> # of expected passes  1934
> # of unsupported tests28
> 
> This is a combined backport of the relevant parts of upstream libffi 
> changes as follows:
> 
> - commit 8308984e479e ("[PATCH] Make sure we're running dejagnu tests 
>   with the right compiler."),
> 
> - commit 2d9b3939751b ("[PATCH] Fix for closures with sunpro compiler"),
> 
> - commit 0c3824702d3d ("[PATCH] Always set CC_FOR_TARGET for dejagnu, to
>   make the testsuite respect $CC"),
> 
> - commit 7d698125b1f0 ("[PATCH] Use the proper C++ compiler to run C++
>   tests"),
> 
> - commit 6b6df1a7bb37 ("[PATCH] Adds `local.exp` to CLEANFILES"),
> 
> - commit 6cf0dea78a5a ("[PATCH] Change CLEANFILES to DISTCLEANFILES")
> 
>   libffi/
>   * Makefile.am (DISTCLEANFILES): New variable.
>   * configure.ac: Produce `local.exp'.
>   * Makefile.in: Regenerate.
>   * configure: Regenerate.
>   * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
>   variable.
>   * testsuite/Makefile.in: Regenerate.
OK
jeff
> 

Re: [PATCH] csa, postreload: Improve csa after recent cselib changes [PR94516]

[Jeff Law via Gcc-patches]

On Tue, 2020-04-21 at 01:00 +0200, Jakub Jelinek wrote:
> Hi!
> 
> This patch addresses a missed optimization caused by the cselib changes.
> Already in the past postreload could replace sp = sp + const_int with
> sp = regxy if regxy already has the right value, but with the cselib
> changes it happens several times more often.  It can result in smaller
> code, so it seems undesirable to prevent such optimizations, but
> unfortunately it can get into the way of stack adjustment coalescing,
> where e.g. if we used to have sp = sp + 32; sp = sp - 8;, previously
> we'd turn that into sp = sp + 24;, but now postreload optimizes
> into sp = r12; sp = sp - 8; and csa gives up.
> 
> The patch just adds a REG_EQUAL note when changing sp = sp + const into
> sp = reg, where we remember it was actually a stack adjustment by certain
> constant, and the combine-stack-adj changes than make use of those REG_EQUAL
> notes, together with LR tracking (csa did enable the note problem, just
> didn't simulate each insn) so that we can add the needed clobbers etc.
> (taken from the other stack adjustment insn).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2020-04-20  Jakub Jelinek  
> 
>   PR rtl-optimization/94516
>   * postreload.c (reload_cse_simplify): When replacing sp = sp + const
>   with sp = reg, add REG_EQUAL note with sp + const.
>   * combine-stack-adj.c (try_apply_stack_adjustment): Change return
>   type from int to bool.  Add LIVE and OTHER_INSN arguments.  Undo
>   postreload sp = sp + const to sp = reg optimization if needed and
>   possible.
>   (combine_stack_adjustments_for_block): Add LIVE argument.  Handle
>   reg = sp insn with sp + const REG_EQUAL note.  Adjust
>   try_apply_stack_adjustment caller, call
>   df_simulate_initialize_forwards and df_simulate_one_insn_forwards.
>   (combine_stack_adjustments): Allocate and free LIVE bitmap,
>   adjust combine_stack_adjustments_for_block caller.
I'd probably defer to gcc-11 since this is "just" a missed optimization and 
we're
getting real close to cutting an RC and I'd hate to introduce new instability at
this point.

Jeff
> 

Re: [PATCH] add missing -Wno-stack-usage etc. options [PR90983]

[Jeff Law via Gcc-patches]

On Tue, 2020-04-21 at 13:37 -0600, Martin Sebor via Gcc-patches wrote:
> In addition to accepting argument values in excess of INT_MAX in
> options like -Walloca-larger-than=byte-size, GCC 9 has changed
> the behavior of such options with byte-size of zero.  While in prior
> versions zero disables the warning for any size, in GCC 9 it enables
> it for all non-zero sizes.  Since all these byte-size options are
> enabled by default for sizes in excess of PTRDIFF_MAX, users who
> want to disable them need to use the newly added -Wno-xxx options
> (such as -Wno-alloca-larger-than).
> 
> However, although I documented all of the new options, I only
> remembered to add the negative options for the C/C++ family and
> forgot about all the common ones, including -Wframe-larger-than=,
> -Wlarger-than=, and -Wstack-usage=.  As a result, users who want
> to disable the default, say -Wstack-usage, cannot use
> the -Wno-stack-usage as the manual leads them to do but have to
> use the less than intuitive workaround of specifying a very large
> argument to the positive option, e.g., something like
> -Wstack-usage=999EiB (denoting 999 etabytes).
> 
> To avoid this hassle the attached patch provides the three missing
> negative options.
> 
> Tested on x86_64-linux.
OK
jeff

Re: [PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

[Richard Sandiford]

"duanbo (C)"  writes:
> Hi
>
> Thank you for your suggestions.
> I have adjust the testcases and used this command to test .
> "runtest --tool gcc --tool_opts -mabi=ilp32  aarch64.exp= 
> reload-valid-spoff.c"
>
> The results of those tests  changed from  unexpected failures to  
> unsupported. 

Thanks, pushed to master.

Richard

Re: Ping: [PATCH] wwwdocs: Document support for extended identifiers added to GCC 10

[Lewis Hyatt via Gcc-patches]

On Wed, Mar 11, 2020 at 9:12 AM Lewis Hyatt  wrote:
> On Sat, Mar 7, 2020 at 6:23 PM Gerald Pfeifer  wrote:
> >
> > On Tue, 25 Feb 2020, Lewis Hyatt wrote:
> > > Just checking whether the below is OK for gcc 10 changes.html please. 
> > > Thanks!
> > > https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01667.html
> >
> > Yes, this looks fine to me from a web perspective.
> >
> > Thank you,
> > Gerald
>
> Great, thank you very much for taking a look at it. Sorry if this
> email is unnecessary noise, but it wasn't quite clear to me whether
> this should also still be approved from a content perspective? I
> didn't want to assume. Thanks!

Hello-

Sorry to ask about this one again, it just still isn't clear to me
whether this change is OK to push or not? I took Gerald's message to
mean it's fine, as long as the content is approved. Thanks very much!

https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg01667.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c34

-Lewis

Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

[Richard Sandiford]

"Yangfei (Felix)"  writes:
> Hi,
>
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Wednesday, April 22, 2020 6:03 PM
>> To: Yangfei (Felix) 
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-
>> regs-only and sve
>> 
>> Mostly LGTM, just a couple of minor points:
>
> Thanks for the very careful code review.  :-) 
> I think the revised patch fixed these points.  
> GCC builds OK and the newly added test still works. 
> Please help push if it's good to go. 

Thanks, pushed to master.

Richard

Re: [wwwdocs] Update list of new C++20 features in libstdc++

[Jonathan Wakely via Gcc-patches]

On 21/04/20 20:30 +0100, Jonathan Wakely wrote:

Committed to wwwdocs.




commit ba9d172720e36f93daf9c1b4569d4babe34e307e
Author: Jonathan Wakely 
Date:   Tue Apr 21 20:28:48 2020 +0100

   Update list of new C++20 features in libstdc++

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index fc8f16e7..06a4267a 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -383,7 +383,24 @@ a work-in-progress.

  Improved experimental C++2a support, including:

+  
+Library concepts in concepts and
+iterator.
+  
+  
+Constrained algorithms in ranges,
+algorithm, and
+memory (thanks to Patrick Palka).
+  
+  
+New algorithms shift_left and shift_right
+(thanks to Patrick Palka).
+  
   std::span (thanks to JeanHeyd Meneide). 
+  
+Three-way comparisons in compare
+and throughout the library.
+  
  
Constexpr support in algorithm and elsewhere
(thanks to Edward Smith-Rowland).
@@ -396,16 +413,11 @@ a work-in-progress.
std::atomic_ref and
std::atomicfloating point.
  
-   std::ssize, std::to_array. 
  
-Library concepts in concepts and
-iterator.
+Integral comparison functions
+(cmp_equal, cmp_less etc.).


These functions work on _integer_ types, not integral types.

I hoped I'd stop getting that mixed up after doing it in
plenary in Prague, but apparently not.

The attached fix has been committed to wwwdocs.


commit cb7aff9c268dcb7012ea1d72dee82f64b0c9de12
Author: Jonathan Wakely 
Date:   Wed Apr 22 18:21:11 2020 +0100

Fix description of new C++20 library feature

These functions work on _integer_ types, not integral types.

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 06a4267a..3146806b 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -414,7 +414,7 @@ a work-in-progress.
 std::atomicfloating point.
   
   
-Integral comparison functions
+Integer comparison functions
 (cmp_equal, cmp_less etc.).
   
std::ssize, std::to_array. 

Re: [PATCH] free() was missing from a part of the documentation

[Jeff Law via Gcc-patches]

On Tue, 2020-04-21 at 18:18 -0600, Zackery Spytz via Gcc-patches wrote:
> Hello,
> 
> The free() function was missing from a part of the documentation!
Thanks.  I've pushed this fix to the trunk.

jeff
> 

Re: [rtl] Harden 'set_noop_p' for non-constant selectors [PR94279]

[Richard Sandiford]

Andrew Stubbs  writes:
> On 22/04/2020 17:43, Thomas Schwinge wrote:
>> In  "[amdgcn] internal compiler error: RTL
>> check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at
>> rtl.h:2379", we recently found that that it's wrong to expect constant
>> selectors, at least in the current code and its usage context.  (Thanks,
>> Richard Biener for the guidance!)  Not too many actually, but of course,
>> this code has seen some changes since 2013-12-04 (for example, r261530
>> "Use poly_int rtx accessors instead of hwi accessors"), and also the
>> context may have changed that it's being used in -- so, I'm not sure
>> whether the original code (as quoted above) is actually buggy already,
>> but it already does contain the pattern that 'INTVAL' is used on
>> something without making sure that we're actually dealing with a constant
>> selector.  (Has that maybe have been an impossible scenario back then?)
>
> I think it was impossible. See 
> https://gcc.gnu.org/legacy-ml/gcc-patches/2018-09/msg00273.html

Ah!  Thanks for the link.

>> Then, should this also be backported to release branches?  GCC 9: same
>> patch as for master branch.  GCC 8: pre poly_int, so only need to guard
>> 'INTVAL' (by 'CONST_INT_P', right?).  Or, is that not worth it, given
>> that nobody found this to be a problem until now (as far as I know),
>> and/or it's maybe really specific to (or, exposed by) AMD GCN's vector
>> instructions?  (For AMD GCN offloading, we only care about master
>> branch.)
>
> I don't think it's needed prior to GCC 9, and then only for amdgcn which 
> was probably not widely used.

Based on that, OK for master and GCC 9.

Thanks,
Richard

Re: [PATCH] Update documentation on optimizations turned on by O3

[Jeff Law via Gcc-patches]

On Wed, 2020-04-22 at 17:14 +0200, Erick Ochoa wrote:
> Hello,
> 
> I noted that the optimizations turned on by O3 was outdated in the 
> documentation. Here is the discussion that brought it to my attention:
> https://gcc.gnu.org/pipermail/gcc/2020-April/232164.html
THanks.  I've created a ChangeLog entry and pushed this fix.

Jeff
> 

[PATCH, libgfortran] Protect the trigd functions in libgfortran from unavailable math functions [PR94586, PR94694]

[Fritz Reese via Gcc-patches]

This patch here is a follow-on to Jakub's in his message "[PATCH]
libgfortran: Provide some further math library fallbacks [PR94694]" at
https://gcc.gnu.org/pipermail/fortran/2020-April/054252.html.

I think this should be committed along with Jakub's patch in response
to PRs 94586 and 94694. Though this patch alone does not fix either
PR, it prevents the build from failing when the degree-valued
trigonometric functions are ultimately unavailable on the target due
to lack of math library builtins.

If HAVE_* is not defined for the math functions required by the trigd
implementations, the intrinsic functions are built only to throw a
runtime_error. Prior to this, the libgfortran build would fail
completely. These intrinsics are extensions, and before the original
trigd patch the library could build even when these math functions
were missing. Therefore, I think the compiler should not fail to build
simply because the intrinsics are unsupported on the target.

In theory, this patch would also fix the trigd build for targets which
don't have a floating-point INFINITY defined, though I am unsure if
any such targets exist.

Furthermore, this patch replaces hard-coded floating point literal
suffixes with the use of GFC_REAL__LITERAL_SUFFIX, as defined by
libgfortran's kinds.h. This could help targets with quirky definitions
for real(16) such as HPUX, as in PR 94586. Similarly, the precision
used for the constants COSD_SMALL, COSD30, et al. for the REAL(16)
case are derived from the precision of GFC_REAL_16 rather than its
long-double-ness, since for example on HPUX long double is actually
128 bits.

This patch also fixes an issue which could have occurred in the
front-end: the front-end attemped to use a host-sized floating-point
literal to represent cosine of 30 degrees. This is of course
nonsensical. The patch replaces this with the use of mpfr functions to
compute the value as sqrt(3)/2 to the correct precision. I include
this in the patch because it is also a target-specific issue with the
degree-valued trigonometric intrinsics.

Jakub has OK'd the patch and I recently authored the original trigd
code being modified here. After his patch is committed I will commit
this one unless others have comments or concerns.

libgfortran/ChangeLog:

2020-04-22  Fritz Reese  

* intrinsics/trigd.c, intrinsics/trigd_lib.inc, intrinsics/trigd.inc:
Guard against unavailable math functions.
Use suffixes from kinds.h based on the REAL kind.

gcc/fortran/ChangeLog:

2020-04-22  Fritz Reese  

* trigd_fe.inc: Use mpfr to compute cosd(30) rather than a host-
precision floating point literal based on an invalid macro.

---
Fritz Reese

[Note: the only differences between this patch and the one in the PR
is whitespace.]
commit dd9c65c7338ceed5ef30e768e4530d73141918c5
Author: Fritz Reese 
Date:   Wed Apr 22 11:45:22 2020 -0400

Follow-on to: Provide some further math library fallbacks [PR94694]

Protect the trigd functions in libgfortran from unavailable math functions.

libgfortran/ChangeLog:

2020-04-22  Fritz Reese  

* intrinsics/trigd.c, intrinsics/trigd_lib.inc, intrinsics/trigd.inc:
Guard against unavailable math functions.
Use suffixes from kinds.h based on the REAL kind.

gcc/fortran/ChangeLog:

2020-04-22  Fritz Reese  

* trigd_fe.inc: Use mpfr to compute cosd(30) rather than a host-
precision floating point literal based on an invalid macro.

diff --git a/gcc/fortran/trigd_fe.inc b/gcc/fortran/trigd_fe.inc
index 78ca4416a21..f94c36773c1 100644
--- a/gcc/fortran/trigd_fe.inc
+++ b/gcc/fortran/trigd_fe.inc
@@ -29,17 +29,20 @@ along with GCC; see the file COPYING3.  If not see
 #define ISFINITE(x) mpfr_number_p(x)
 #define D2R(x) deg2rad(x)
 
+#define ENABLE_SIND
+#define ENABLE_COSD
+#define ENABLE_TAND
+
 #define SIND simplify_sind
 #define COSD simplify_cosd
 #define TAND simplify_tand
 
-#ifdef HAVE_GFC_REAL_16
-#define COSD30 8.66025403784438646763723170752936183e-01Q
-#else
-#define COSD30 8.66025403784438646763723170752936183e-01L
-#endif
-
-#define SET_COSD30(x) mpfr_set_ld((x), COSD30, GFC_RND_MODE)
+/* cosd(30) === sqrt(3) / 2.  */
+#define SET_COSD30(x) do { \
+mpfr_set_ui (x, 3, GFC_RND_MODE); \
+mpfr_sqrt (x, x, GFC_RND_MODE); \
+mpfr_div_ui (x, x, 2, GFC_RND_MODE); \
+  } while (0)
 
 static RETTYPE SIND (FTYPE);
 static RETTYPE COSD (FTYPE);
diff --git a/libgfortran/intrinsics/trigd.c b/libgfortran/intrinsics/trigd.c
index 81699069545..e1c51c7b2ef 100644
--- a/libgfortran/intrinsics/trigd.c
+++ b/libgfortran/intrinsics/trigd.c
@@ -27,6 +27,14 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 #include 
 
+/* Body of library functions which are cannot be implemented on the current
+ * platform because it lacks a capability, such as an underlying trigonometric
+ * function (sin, cos, tan) or C99 floating-point function (fabs, fmod). */

Re: [PATCH] libgfortran: Provide some further math library fallbacks [PR94694]

[Jeff Law via Gcc-patches]

On Wed, 2020-04-22 at 16:42 +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
> 
> The following patch provides some further math library fallbacks.
> fmaf can be implemented using fma if available, fma and fmal can use
> x * y + z as fallback, it is not perfect, but e.g. glibc on various arches
> has been using that as fallback for many years,
> and copysign/copysignl/fabs/fabsl can be implemented using corresponding
> __builtin_* if we make sure that gcc expands it inline instead of using
> a library call (these days it is expanded inline on most targets).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux and Andrea Corallo
> has tested it on aarch64-elf.  Ok for trunk?
> 
> Fritz has a further patch for the PR to deal with cases where some functions
> aren't available and there is no easy fallback for them.
> 
> 2020-04-22  Jakub Jelinek  
> 
>   PR libfortran/94694
>   PR libfortran/94586
>   * configure.ac: Add math func checks for fmaf, fma and fmal.  Add
>   HAVE_INLINE_BUILTIN_COPYSIGN check.
>   * c99_protos.h (copysign, fmaf, fma, fmal): Provide fallback
>   prototypes.
>   (HAVE_COPYSIGN, HAVE_FMAF, HAVE_FMA, HAVE_FMAL): Define if not
>   defined and fallback version is provided.
>   * intrinsics/c99_functions.c (copysign, fmaf, fma, fmal): Provide
>   fallback implementations if possible
>   * configure: Regenerated.
>   * config.h.in: Regenerated.
Normally I try to stay out of libgfortran.  But I'll go ahead and ACK this.

The *-elf targets in my tester don't build fortran/libgfortran.  But I'm open to
possibly turning that on if they're stable enough.

jeff
> 

Re: [rtl] Harden 'set_noop_p' for non-constant selectors [PR94279]

[Andrew Stubbs]

On 22/04/2020 17:43, Thomas Schwinge wrote:

In  "[amdgcn] internal compiler error: RTL
check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at
rtl.h:2379", we recently found that that it's wrong to expect constant
selectors, at least in the current code and its usage context.  (Thanks,
Richard Biener for the guidance!)  Not too many actually, but of course,
this code has seen some changes since 2013-12-04 (for example, r261530
"Use poly_int rtx accessors instead of hwi accessors"), and also the
context may have changed that it's being used in -- so, I'm not sure
whether the original code (as quoted above) is actually buggy already,
but it already does contain the pattern that 'INTVAL' is used on
something without making sure that we're actually dealing with a constant
selector.  (Has that maybe have been an impossible scenario back then?)


I think it was impossible. See 
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-09/msg00273.html



Then, should this also be backported to release branches?  GCC 9: same
patch as for master branch.  GCC 8: pre poly_int, so only need to guard
'INTVAL' (by 'CONST_INT_P', right?).  Or, is that not worth it, given
that nobody found this to be a problem until now (as far as I know),
and/or it's maybe really specific to (or, exposed by) AMD GCN's vector
instructions?  (For AMD GCN offloading, we only care about master
branch.)


I don't think it's needed prior to GCC 9, and then only for amdgcn which 
was probably not widely used.


Andrew

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

[Bill Schmidt via Gcc-patches]

On 4/22/20 11:49 AM, Jakub Jelinek wrote:

On Wed, Apr 22, 2020 at 11:24:09AM -0500, Bill Schmidt wrote:

Hm, but this patch violates the ELFv2 ABI as written.  The ABI includes:

"Floating-point and vector aggregates that contain padding words and
integer fields with a width of 0 should not be treated as homogeneous
aggregates."

struct S {};
struct T : public S { float x, y, z; };
doesn't really contain any padding words nor integer fields with a width of
0, it is laid out as x at offset 0, y at offset sizeof (float) and
z at offset sizeof (float) * 2, the struct has sizeof (T) == sizeof (float) * 3.
The ELFv2 ABI certainly can't talk about how GCC implements them and what
TYPE_FIELDS chain elts should be honored and what should be ignored,
it must talk about what is in the source.
struct S {};
struct U { struct S s; float x, y, z; };
in C is considered homogeneous and is laid out exactly the same, and so is
T in C++14, just in C++17 as an implementation detail the C++ FE adds a base
field.


OK, on reflection I'll accept that.  Thanks for the explanation.

Bill


Short description + the patch that introduced it is
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01213.html

Jakub

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 22, 2020 at 11:24:09AM -0500, Bill Schmidt wrote:
> Hm, but this patch violates the ELFv2 ABI as written.  The ABI includes:
> 
> "Floating-point and vector aggregates that contain padding words and
> integer fields with a width of 0 should not be treated as homogeneous
> aggregates."

struct S {};
struct T : public S { float x, y, z; };
doesn't really contain any padding words nor integer fields with a width of
0, it is laid out as x at offset 0, y at offset sizeof (float) and
z at offset sizeof (float) * 2, the struct has sizeof (T) == sizeof (float) * 3.
The ELFv2 ABI certainly can't talk about how GCC implements them and what
TYPE_FIELDS chain elts should be honored and what should be ignored,
it must talk about what is in the source.
struct S {};
struct U { struct S s; float x, y, z; };
in C is considered homogeneous and is laid out exactly the same, and so is
T in C++14, just in C++17 as an implementation detail the C++ FE adds a base
field.
Short description + the patch that introduced it is
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01213.html

Jakub

[rtl] Harden 'set_noop_p' for non-constant selectors [PR94279] (was: [Patch, RTL] Eliminate redundant vec_select moves)

[Thomas Schwinge]

Hi!

First: please be gentle: I don't speak RTL.  ;-) And second: it's been
some time.

On 2013-12-04T16:06:48+, Tejas Belagod  wrote:
> gcc/
>   * rtlanal.c (set_noop_p): Return nonzero in case of redundant vec_select
>   for overlapping register lanes.

This got committed to trunk in r205712.

> --- a/gcc/rtlanal.c
> +++ b/gcc/rtlanal.c
> @@ -1180,6 +1180,26 @@ set_noop_p (const_rtx set)
>dst = SUBREG_REG (dst);
>  }
>
> +  /* It is a NOOP if destination overlaps with selected src vector
> + elements.  */
> +  if (GET_CODE (src) == VEC_SELECT
> +  && REG_P (XEXP (src, 0)) && REG_P (dst)
> +  && HARD_REGISTER_P (XEXP (src, 0))
> +  && HARD_REGISTER_P (dst))
> +{
> +  int i;
> +  rtx par = XEXP (src, 1);
> +  rtx src0 = XEXP (src, 0);
> +  int c0 = INTVAL (XVECEXP (par, 0, 0));
> +  HOST_WIDE_INT offset = GET_MODE_UNIT_SIZE (GET_MODE (src0)) * c0;
> +
> +  for (i = 1; i < XVECLEN (par, 0); i++)
> + if (INTVAL (XVECEXP (par, 0, i)) != c0 + i)
> +   return 0;
> +  return simplify_subreg_regno (REGNO (src0), GET_MODE (src0),
> + offset, GET_MODE (dst)) == (int)REGNO (dst);
> +}
> +
>return (REG_P (src) && REG_P (dst)
> && REGNO (src) == REGNO (dst));
>  }

In  "[amdgcn] internal compiler error: RTL
check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at
rtl.h:2379", we recently found that that it's wrong to expect constant
selectors, at least in the current code and its usage context.  (Thanks,
Richard Biener for the guidance!)  Not too many actually, but of course,
this code has seen some changes since 2013-12-04 (for example, r261530
"Use poly_int rtx accessors instead of hwi accessors"), and also the
context may have changed that it's being used in -- so, I'm not sure
whether the original code (as quoted above) is actually buggy already,
but it already does contain the pattern that 'INTVAL' is used on
something without making sure that we're actually dealing with a constant
selector.  (Has that maybe have been an impossible scenario back then?)

Anyway.  Attached is a WIP patch "[rtl] Harden 'set_noop_p' for
non-constant selectors [PR94279]".  Richard Biener said that "A patch
like along that line is pre-approved", but given my illiterateness with
what I'm deal with here, I'd like that reviewed properly, please.  :-)
If approving this patch, please respond with "Reviewed-by: NAME "
so that your effort will be recorded in the commit log, see
.

I'll schedule x86_64-pc-linux-gnu and powerpc64le-unknown-linux-gnu
bootstrap testing.  What other testing does this need?  (Asking as this
seems to have been added for aarch64, which I'm not set up to test.)  So
far, I've only confirmed that it does solve the RTL checking issue with
libgomp AMD GCN offloading testing.

Then, should this also be backported to release branches?  GCC 9: same
patch as for master branch.  GCC 8: pre poly_int, so only need to guard
'INTVAL' (by 'CONST_INT_P', right?).  Or, is that not worth it, given
that nobody found this to be a problem until now (as far as I know),
and/or it's maybe really specific to (or, exposed by) AMD GCN's vector
instructions?  (For AMD GCN offloading, we only care about master
branch.)


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 3546ac8ef47cf67570834e5a70614907bef40304 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 22 Apr 2020 16:58:44 +0200
Subject: [PATCH] [rtl] Harden 'set_noop_p' for non-constant selectors
 [PR94279]

---
 gcc/rtlanal.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index c7ab86e228b1..0ebde7622db6 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -1631,12 +1631,18 @@ set_noop_p (const_rtx set)
   int i;
   rtx par = XEXP (src, 1);
   rtx src0 = XEXP (src, 0);
-  poly_int64 c0 = rtx_to_poly_int64 (XVECEXP (par, 0, 0));
+  poly_int64 c0;
+  if (!poly_int_rtx_p (XVECEXP (par, 0, 0), ))
+	return 0;
   poly_int64 offset = GET_MODE_UNIT_SIZE (GET_MODE (src0)) * c0;
 
   for (i = 1; i < XVECLEN (par, 0); i++)
-	if (maybe_ne (rtx_to_poly_int64 (XVECEXP (par, 0, i)), c0 + i))
-	  return 0;
+	{
+	  poly_int64 c0i;
+	  if (!poly_int_rtx_p (XVECEXP (par, 0, i), )
+	  || maybe_ne (c0i, c0 + i))
+	return 0;
+	}
   return
 	REG_CAN_CHANGE_MODE_P (REGNO (dst), GET_MODE (src0), GET_MODE (dst))
 	&& simplify_subreg_regno (REGNO (src0), GET_MODE (src0),
-- 
2.25.1

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

[Bill Schmidt via Gcc-patches]

On 4/22/20 8:11 AM, Jakub Jelinek via Gcc-patches wrote:

Hi!

As mentioned in the PR and on IRC, the recently added struct-layout-1.exp
new tests FAIL on powerpc64le-linux (among other targets).
FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute
in particular.  The problem is that the presence or absence of the C++17
artificial empty base fields, which have non-zero TYPE_SIZE, but zero
DECL_SIZE, change the ABI decisions, if it is present (-std=c++17), the type
might not be considered homogeneous, while if it is absent (-std=c++14), it
can be.

The following patch fixes that and emits a -Wpsabi inform; perhaps more
often than it could, because the fact that rs6000_discover_homogeneous_aggregate
returns true when it didn't in in GCC 7/8/9 with -std=c++17 doesn't still
mean it will make a different ABI decision, but the warning triggered only
on the test I've changed (the struct-layout-1.exp tests use -w -Wno-psabi
already).


Hm, but this patch violates the ELFv2 ABI as written.  The ABI includes:

"Floating-point and vector aggregates that contain padding words and
integer fields with a width of 0 should not be treated as homogeneous
aggregates."

So if this patch is accepted, it requires an exception in the ABI
document specifically for C++17 empty base fields.  Are these base fields
required by the C++17 specification?  We can't change the ABI just
based on a single implementation if it is not required.  If it is
required, I don't immediately foresee a problem with updating the ABI.

Thanks,
Bill



Bootstrapped/regtested on powerpc64le-linux, bootstrapped on powerpc64-linux
where regtest is still pending, but homogeneous aggregates are an ELFv2
thing, so I don't expect it to change anything (and so far no such messages
appear in the testsuite log files).

Ok for trunk?

2020-04-22  Jakub Jelinek  

PR target/94707
* config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Add
CXX17_EMPTY_BASE_SEEN argument.  Pass it to recursive calls.
Ignore cxx17_empty_base_field_p fields after setting
*CXX17_EMPTY_BASE_SEEN to true.
(rs6000_discover_homogeneous_aggregate): Adjust
rs6000_aggregate_candidate caller.  With -Wpsabi, diagnose homogeneous
aggregates with C++17 empty base fields.

* g++.dg/tree-ssa/pr27830.C: Use -Wpsabi -w for -std=c++17 and higher.

--- gcc/config/rs6000/rs6000-call.c.jj  2020-03-30 22:53:40.746640328 +0200
+++ gcc/config/rs6000/rs6000-call.c 2020-04-22 13:05:07.947809888 +0200
@@ -5528,7 +5528,8 @@ const struct altivec_builtin_types altiv
 sub-tree.  */
  
  static int

-rs6000_aggregate_candidate (const_tree type, machine_mode *modep)
+rs6000_aggregate_candidate (const_tree type, machine_mode *modep,
+   bool *cxx17_empty_base_seen)
  {
machine_mode mode;
HOST_WIDE_INT size;
@@ -5598,7 +5599,8 @@ rs6000_aggregate_candidate (const_tree t
|| TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST)
  return -1;
  
-	count = rs6000_aggregate_candidate (TREE_TYPE (type), modep);

+   count = rs6000_aggregate_candidate (TREE_TYPE (type), modep,
+   cxx17_empty_base_seen);
if (count == -1
|| !index
|| !TYPE_MAX_VALUE (index)
@@ -5636,7 +5638,14 @@ rs6000_aggregate_candidate (const_tree t
if (TREE_CODE (field) != FIELD_DECL)
  continue;
  
-	sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep);

+   if (cxx17_empty_base_field_p (field))
+ {
+   *cxx17_empty_base_seen = true;
+   continue;
+ }
+
+   sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep,
+   cxx17_empty_base_seen);
if (sub_count < 0)
  return -1;
count += sub_count;
@@ -5669,7 +5678,8 @@ rs6000_aggregate_candidate (const_tree t
if (TREE_CODE (field) != FIELD_DECL)
  continue;
  
-	sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep);

+   sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep,
+   cxx17_empty_base_seen);
if (sub_count < 0)
  return -1;
count = count > sub_count ? count : sub_count;
@@ -5710,7 +5720,9 @@ rs6000_discover_homogeneous_aggregate (m
&& AGGREGATE_TYPE_P (type))
  {
machine_mode field_mode = VOIDmode;
-  int field_count = rs6000_aggregate_candidate (type, _mode);
+  bool cxx17_empty_base_seen = false;
+  int field_count = rs6000_aggregate_candidate (type, _mode,
+   _empty_base_seen);
  
   

Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

[Thomas Koenig via Gcc-patches]

Hi Jose,



On 21/04/20 16:38, Thomas Koenig wrote:

Do you have commit privileges? It not, I can commit it for you.



No i do not. I would be grateful if you could.


Done, as 
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=808a6eadda1a353ce3a70556feac128580491b24 
.


Thanks a lot for the patch!

Regards

Thomas

Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

[José Rui Faustino de Sousa via Gcc-patches]

Hi Thomas,

On 21/04/20 16:38, Thomas Koenig wrote:

Do you have commit privileges? It not, I can commit it for you.



No i do not. I would be grateful if you could.

Best regards,
José Rui

Re: [PATCH][RFC] extend DECL_GIMPLE_REG_P to all types

[Richard Sandiford]

Richard Biener  writes:
> On Wed, 22 Apr 2020, Richard Biener wrote:
>
>> 
>> This extends DECL_GIMPLE_REG_P to all types so we can clear
>> TREE_ADDRESSABLE even for integers with partial defs, not just
>> complex and vector variables.  To make that transition easier
>> the patch inverts DECL_GIMPLE_REG_P to DECL_NOT_GIMPLE_REG_P
>> since that makes the default the current state for all other
>> types besides complex and vectors.  That also nicely simplifies
>> code throughout the compiler.
>> 
>> TREE_ADDRESSABLE and DECL_NOT_GIMPLE_REG_P are now truly
>> independent, either set prevents a decl from being rewritten
>> into SSA form.
>> 
>> For the testcase in PR94703 we're able to expand the partial
>> def'ed local integer to a register then, producing a single
>> movl rather than going through the stack.
>> 
>> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>> 
>> If there are no objections I'm going to install this once
>> stage1 opens.
>
> Of course there was some fallout.  On 32bit x86 gcc.dg/torture/pr71522.c
> fails execution because while the GIMPLE is unchanged at RTL expansion
> time:
>
> main ()
> {
>   char s[12];
>   long double d;
>
>   MEM  [(char * {ref-all})] = MEM  
> [(char * {ref-all})"AAA"];
>   MEM  [(char * {ref-all})] = MEM  
> [(char * {ref-all})];
>   _1 = __builtin_strcmp (, "AAA");
>   if (_1 != 0)
> ...
>
> we now assign 'd' an XFmode register (TREE_ADDRESSABLE is cleared
> now since we can set DECL_NOT_GIMPLE_REG_P).  The case is lost
> then, impossible to fix up AFAICS.  On x86 all moves to/from
> XFmode are normalizing, specifically we end up with
>
> fldt.LC0
> fstpt   (%esp)
>
> now the most appealing solution - and totally in the opposite
> direction of this patch - is to simply stop expanding non-SSA names
> as pseudos.  I do not remember the history as why we do this
> but it's likely remanents we preserved from either pre-SSA, times
> we did not go into SSA for -O0 or times we really gone out-of-SSA.
>
> There is _some_ good reason to expand a non-SSA "register" into
> a pseudo though - namely that RTL is not SSA and thus can accept
> partial defs.  And of course that RTL cannot get rid of a stack
> slot assigned to a variable.  Today we have somewhat robust
> infrastructure to deal with partial defs on GIMPLE, namely
> BIT_INSERT_EXPR, but it's not fully exercised.

Yeah, not being able to get rid of the stack slot seems
worrying here.

> It's of course possible to fixup the above problematical
> cases (there's precenent with discover_nonconstant_array_refs,
> which could be "easily" extended to handle "weird" accesses
> of non-integral-mode variables) but with the recent discussion
> on making RTL expansion more straight-forward I'd bring up
> the above idea ... it would get rid of quite some special
> code dealing with tcc_reference trees (and MEM_REFs) ending
> up operating on registers.

It might be nice to do it eventually, but I think at least
is_gimple_reg_type would need to be "return true" first,
otherwise we'll lose too much on aggregates.

There's also the problem that things passed in registers do need
to be RTL registers at function boundaries, so I'm not sure all
the expand code would necessarily go away.

Wouldn't want to see all targets suffer for XFmode oddities :-)

Thanks,
Richard

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

[Jeff Law via Gcc-patches]

On Wed, 2020-04-22 at 09:36 -0600, Martin Sebor via Gcc-patches wrote:
> On 4/22/20 7:28 AM, Christophe Lyon wrote:
> > On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches
> >  wrote:
> > > On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches
> > >  wrote:
> > > > The restrict pass computes the wrong lower bound of the size
> > > > of accesses to member arrays passed to strncpy as the source:
> > > > it uses the third argument to the function even though the size
> > > > of the read is limited by the length of the source when it is
> > > > a string.  This results in false positive -Warray-bounds
> > > > warnings in such cases.
> > > > 
> > > > The attached patch corrects this bug.  In addition, it adjusts
> > > > the range of offsets of the overlap printed in diagnostics to
> > > > be in an increasing order (i.e., [LOW, HIGH]), and removes
> > > > a hack was in place to adjust the offsets that's obviated by
> > > > the fix above.
> > > > 
> > > > Tested on x86_64-linux.
> > 
> > Hi,
> > 
> > The update of Warray-bounds-2.c fails on 32 bits targets:
> > /gcc/testsuite/c-c++-common/Warray-bounds-2.c:192:3: warning:
> > 'strncpy' pointer overflow between offset 2147483647 and size [1, 0]
> > [-Warray-bounds]
> > because the uppper limit is hardcoded in the testcase with the 64-bits
> > value. Can you adjust it?
> 
> Done.
I was going to suggest the (x|y|z) syntax to be a little tighter on what we
accept on the 16, 32 and 64bit targets (I was in the middle of building
appropriate toolchains to verify the change).  But your solution is fine as 
well.
Thanks for taking care of it.

Jeff

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

[Martin Sebor via Gcc-patches]

On 4/22/20 7:28 AM, Christophe Lyon wrote:

On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches
 wrote:


On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches
 wrote:


The restrict pass computes the wrong lower bound of the size
of accesses to member arrays passed to strncpy as the source:
it uses the third argument to the function even though the size
of the read is limited by the length of the source when it is
a string.  This results in false positive -Warray-bounds
warnings in such cases.

The attached patch corrects this bug.  In addition, it adjusts
the range of offsets of the overlap printed in diagnostics to
be in an increasing order (i.e., [LOW, HIGH]), and removes
a hack was in place to adjust the offsets that's obviated by
the fix above.

Tested on x86_64-linux.


Hi,

The update of Warray-bounds-2.c fails on 32 bits targets:
/gcc/testsuite/c-c++-common/Warray-bounds-2.c:192:3: warning:
'strncpy' pointer overflow between offset 2147483647 and size [1, 0]
[-Warray-bounds]
because the uppper limit is hardcoded in the testcase with the 64-bits
value. Can you adjust it?


Done.

Martin



Thanks



OK.

Richard.


Martin

[PATCH] Update documentation on optimizations turned on by O3

[Erick Ochoa]

Hello,

I noted that the optimizations turned on by O3 was outdated in the 
documentation. Here is the discussion that brought it to my attention:

https://gcc.gnu.org/pipermail/gcc/2020-April/232164.html

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e2bc2559218..a28001a5adf 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9241,14 +9241,14 @@ by @option{-O2} and also turns on the following 
optimization flags:

 -floop-unroll-and-jam @gol
 -fpeel-loops @gol
 -fpredictive-commoning @gol
+-fsplit-loops @gol
 -fsplit-paths @gol
--ftree-loop-distribute-patterns @gol
 -ftree-loop-distribution @gol
 -ftree-loop-vectorize @gol
 -ftree-partial-pre @gol
 -ftree-slp-vectorize @gol
 -funswitch-loops @gol
--fvect-cost-model @gol
+-fvect-cost-model=dynamic @gol
 -fversion-loops-for-strides}

 @item -O0

RE: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics

[Kyrylo Tkachov]

> -Original Message-
> From: Kyrylo Tkachov
> Sent: 22 April 2020 11:00
> To: Andre Vieira (lists) ; gcc-
> patc...@gcc.gnu.org
> Cc: Richard Sandiford ; s...@amazon.com
> Subject: RE: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics
> 
> Hi Andre,
> 
> > -Original Message-
> > From: Andre Vieira (lists) 
> > Sent: 22 April 2020 09:26
> > To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> > Cc: Richard Sandiford ; s...@amazon.com
> > Subject: Re: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics
> >
> >
> > On 20/04/2020 09:42, Kyrylo Tkachov wrote:
> > > Hi Andre,
> > >
> > >> -Original Message-
> > >> From: Andre Vieira (lists) 
> > >> Sent: 16 April 2020 13:24
> > >> To: gcc-patches@gcc.gnu.org
> > >> Cc: Kyrylo Tkachov ; Richard Sandiford
> > >> ; s...@amazon.com
> > >> Subject: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics
> > >>
> > >> Hi,
> > >>
> > >> This series backports all the patches and fixes regarding outline
> > >> atomics to the gcc-8 branch.
> > >>
> > >> Bootstrapped the series for aarch64-linux-gnu and regression tested.
> > >> Is this OK for gcc-8?
> > >>
> > >> Andre Vieira (19):
> > >> aarch64: Add early clobber for aarch64_store_exclusive
> > >> aarch64: Simplify LSE cas generation
> > >> aarch64: Improve cas generation
> > >> aarch64: Improve swp generation
> > >> aarch64: Improve atomic-op lse generation
> > >> aarch64: Remove early clobber from ATOMIC_LDOP scratch
> > >> aarch64: Extend %R for integer registers
> > >> aarch64: Implement TImode compare-and-swap
> > >> aarch64: Tidy aarch64_split_compare_and_swap
> > >> aarch64: Add out-of-line functions for LSE atomics
> > >> Add visibility to libfunc constructors
> > >> aarch64: Implement -moutline-atomics
> > >> Aarch64: Fix shrinkwrapping interactions with atomics (PR92692)
> > >> aarch64: Fix store-exclusive in load-operate LSE helpers
> > >> aarch64: Configure for sys/auxv.h in libgcc for lse-init.c
> > >> aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368]
> > >> aarch64: Fix bootstrap with old binutils [PR93053]
> > > Thanks for putting these together.
> > > Before they can go in we need to get this fix for PR93053 into GCC 9.
> > > Can you please test it on that branch to help Jakub out?
> > > Thanks,
> > > Kyrill
> > Bootstrapped and regression tested the PR93053 fix from Jakub on gcc-9
> > branch and it looks good.
> 
> Thanks, can you please apply the patch to the gcc-9 branch then? (making
> sure the PR markers are there in the commit message so that Bugzilla is
> updated).
> We can then proceed with the GCC 8 backports.

Now that that's done, this is ok to commit to the GCC 8 branch.
Can you please prepare entries for the appropriate changes.html pages for the 
GCC 9 and 8 releases to indicate the new support?
Thanks,
Kyrill

> 
> Kyrill
> 
> > >> aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]
> > >> re PR target/90724 (ICE with __sync_bool_compare_and_swap with
> > >> -march=armv8.2-a+sve)
> > >

Re: [PATCH v2] S/390: Fix several test cases

[Stefan Schulze Frielinghaus via Gcc-patches]

On Wed, Apr 22, 2020 at 02:14:11PM +0200, Andreas Krebbel wrote:
> On 22.04.20 13:56, Stefan Schulze Frielinghaus wrote:
> > Hi,
> > 
> > Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`.
> > Ok for master?
> > 
> > Cheers,
> > Stefan
> > 
> > gcc/ChangeLog:
> > 
> > 2020-04-21  Stefan Schulze Frielinghaus  
> > 
> > * config/s390/s390.md ("*_ior_and_sr_ze"): lift from 
> > SI
> >   mode to DSI ("*trunc_sidi_and_subreg_ze"): new
> >   insn pattern
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2020-04-21  Stefan Schulze Frielinghaus  
> > 
> > * gcc.target/s390/addsub-signed-overflow-1.c: fix options
> > * gcc.target/s390/addsub-signed-overflow-2.c: fix options
> > * gcc.target/s390/bswap-1.c: fix scan assembler regex
> > * gcc.target/s390/global-array-element-pic2.c: fix scan assembler 
> > regex
> > * gcc.target/s390/load-relative-check.c: fix options
> > * gcc.target/s390/morestack.c: fix options
> > * gcc.target/s390/nobp-return-mem-z900.c: temporarily silence this 
> > case
> > * gcc.target/s390/risbg-ll-1.c: fix scan assembler regex
> > * gcc.target/s390/risbg-ll-2.c: fix scan assembler regex
> > * gcc.target/s390/risbg-ll-3.c: fix scan assembler regex
> > * gcc.target/s390/target-attribute/pr82012.c: fix error message
> 
> The changelog descriptions are supposed to have a capital first letter and . 
> at the end. Ok with
> that change!

I've adapted the ChangeLog entries and pushed the commit.

Thanks for the review!

Cheers,
Stefan

[PATCH] libgfortran: Provide some further math library fallbacks [PR94694]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch provides some further math library fallbacks.
fmaf can be implemented using fma if available, fma and fmal can use
x * y + z as fallback, it is not perfect, but e.g. glibc on various arches
has been using that as fallback for many years,
and copysign/copysignl/fabs/fabsl can be implemented using corresponding
__builtin_* if we make sure that gcc expands it inline instead of using
a library call (these days it is expanded inline on most targets).

Bootstrapped/regtested on x86_64-linux and i686-linux and Andrea Corallo
has tested it on aarch64-elf.  Ok for trunk?

Fritz has a further patch for the PR to deal with cases where some functions
aren't available and there is no easy fallback for them.

2020-04-22  Jakub Jelinek  

PR libfortran/94694
PR libfortran/94586
* configure.ac: Add math func checks for fmaf, fma and fmal.  Add
HAVE_INLINE_BUILTIN_COPYSIGN check.
* c99_protos.h (copysign, fmaf, fma, fmal): Provide fallback
prototypes.
(HAVE_COPYSIGN, HAVE_FMAF, HAVE_FMA, HAVE_FMAL): Define if not
defined and fallback version is provided.
* intrinsics/c99_functions.c (copysign, fmaf, fma, fmal): Provide
fallback implementations if possible
* configure: Regenerated.
* config.h.in: Regenerated.

--- config/math.m4.jj   2020-01-12 11:54:35.753423366 +0100
+++ config/math.m4  2020-04-21 21:30:13.870397648 +0200
@@ -48,3 +48,67 @@ main ()
[Define to 1 if you have the `$1' function.])
   fi
 ])
+
+dnl GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK1([name], [type])
+dnl
+dnl Check if math function NAME fallback for function with single
+dnl TYPE argument and TYPE result can be implemented using
+dnl __builtin_NAME expanded inline without needing unavailable math
+dnl library function.
+AC_DEFUN([GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK1],
+[
+  AC_REQUIRE([GCC_CHECK_LIBM])
+if test $gcc_cv_math_func_$1 = no; then
+  AC_CACHE_CHECK([for inline __builtin_$1], [gcc_cv_math_inline_builtin_$1],
+[AC_LINK_IFELSE([AC_LANG_SOURCE([
+$2
+$1_fallback ($2 x)
+{
+  return __builtin_$1 (x);
+}
+
+int
+main ()
+{
+  return 0;
+}
+])],
+[gcc_cv_math_inline_builtin_$1=yes],
+[gcc_cv_math_inline_builtin_$1=no])])
+  if test $gcc_cv_math_inline_builtin_$1 = yes; then
+AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_INLINE_BUILTIN_$1),[1],
+ [Define to 1 if `__builtin_$1' is expanded inline.])
+  fi
+fi])
+
+dnl GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK2([name], [type])
+dnl
+dnl Check if math function NAME fallback for function with two
+dnl TYPE arguments and TYPE result can be implemented using
+dnl __builtin_NAME expanded inline without needing unavailable math
+dnl library function.
+AC_DEFUN([GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK2],
+[
+  AC_REQUIRE([GCC_CHECK_LIBM])
+if test $gcc_cv_math_func_$1 = no; then
+  AC_CACHE_CHECK([for inline __builtin_$1], [gcc_cv_math_inline_builtin_$1],
+[AC_LINK_IFELSE([AC_LANG_SOURCE([
+$2
+$1_fallback ($2 x, $2 y)
+{
+  return __builtin_$1 (x, y);
+}
+
+int
+main ()
+{
+  return 0;
+}
+])],
+[gcc_cv_math_inline_builtin_$1=yes],
+[gcc_cv_math_inline_builtin_$1=no])])
+  if test $gcc_cv_math_inline_builtin_$1 = yes; then
+AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_INLINE_BUILTIN_$1),[1],
+ [Define to 1 if `__builtin_$1' is expanded inline.])
+  fi
+fi])
--- libgfortran/configure.ac.jj 2020-01-24 22:34:36.340641225 +0100
+++ libgfortran/configure.ac2020-04-21 21:31:25.435319945 +0200
@@ -392,6 +392,9 @@ GCC_CHECK_MATH_FUNC([cabsl])
 GCC_CHECK_MATH_FUNC([floorf])
 GCC_CHECK_MATH_FUNC([floor])
 GCC_CHECK_MATH_FUNC([floorl])
+GCC_CHECK_MATH_FUNC([fmaf])
+GCC_CHECK_MATH_FUNC([fma])
+GCC_CHECK_MATH_FUNC([fmal])
 GCC_CHECK_MATH_FUNC([fmodf])
 GCC_CHECK_MATH_FUNC([fmod])
 GCC_CHECK_MATH_FUNC([fmodl])
@@ -516,6 +519,11 @@ GCC_CHECK_MATH_FUNC([catanl])
 # On AIX, clog is present in libm as __clog
 AC_CHECK_LIB([m],[__clog],[AC_DEFINE([HAVE_CLOG],[1],[libm includes clog])])
 
+GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK2([copysign], [double])
+GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK2([copysignl], [long double])
+GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK1([fabs], [double])
+GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK1([fabsl], [long double])
+
 # Check whether the system has a working stat()
 LIBGFOR_CHECK_WORKING_STAT
 
--- libgfortran/c99_protos.h.jj 2020-01-12 11:54:38.707378799 +0100
+++ libgfortran/c99_protos.h2020-04-21 21:33:57.949023242 +0200
@@ -71,6 +71,16 @@ extern float ceilf(float);
 extern float copysignf(float, float);
 #endif
 
+#if !defined(HAVE_COPYSIGN) && defined(HAVE_INLINE_BUILTIN_COPYSIGN)
+#define HAVE_COPYSIGN 1
+extern double copysign(double, double);
+#endif
+
+#if !defined(HAVE_COPYSIGNL) && defined(HAVE_INLINE_BUILTIN_COPYSIGNL)
+#define HAVE_COPYSIGNL 1
+extern long double copysignl(long double, long double);
+#endif
+
 #ifndef HAVE_COSF
 #define HAVE_COSF 1
 extern float cosf(float);
@@ -91,6 +101,16 @@ 

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Jeff Law via Gcc-patches]

On Wed, 2020-04-22 at 11:50 +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
> 
> On Tue, Apr 21, 2020 at 03:58:52PM +0100, Richard Sandiford wrote:
> > >   if (TREE_CODE (field) != FIELD_DECL)
> > > continue;
> > >  
> > > - sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep);
> > > + /* Ignore C++17 empty base fields, while their type indicates
> > > +they do contain padding, they have zero size and thus don't
> > > +contain any padding.  */
> > > + if (DECL_ARTIFICIAL (field)
> > > + && DECL_NAME (field) == NULL_TREE
> > > + && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
> > > + && DECL_SIZE (field)
> > > + && integer_zerop (DECL_SIZE (field))
> > > + && (*avoid_c17empty_field & AVOID))
> > > +   {
> 
> As multiple targets are affected apparently, I believe at least
> aarch64, arm, powerpc64le, s390{,x} and ia64,
> I think we should have a middle-end predicate for this, so that if we need
> to tweak it, we can do it in one spot.
> 
> So is the following ok (of course after testing)?
> 
> 2020-04-22  Jakub Jelinek  
> 
>   PR target/94383
>   * calls.h (cxx17_empty_base_field_p): Declare.
>   * calls.c (cxx17_empty_base_field_p): Define.
OK.
jeff
> 

Re: introduce target tmpnam and require it in tests relying on it

[Martin Sebor via Gcc-patches]

On 4/22/20 2:03 AM, Bernhard Reutner-Fischer wrote:

On Tue, 21 Apr 2020 at 16:59, Martin Sebor  wrote:


https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543672.html


I'm okay with the changes to the tests.

The target-supports.exp changes look reasonable to me as well but
I can't approve them.  Since you said it's for targets that don't
have file I/O functions I wonder if the name would better reflect
that if it were called, say, check_effective_target_fileio?


Since tmpnam is obsolescent in SUSv4 and hence a libc is fine to omit it, I'd 
rather fix the tests to use functions that are known to stay.


I would be okay with replacing tmpnam with something else, although
I don't think it's necessary.  tmpnam is a standard C function that
conforming C (and so POSIX) implementation are required to provide.


IMO it's perfectly fine to omit obsolescent functions from a
conforming implementation ¹).


No, it's not (the note you quoted below notwithstanding), certainly
not for C features.  In particular for tmpnam (and all other standard
C99 APIs), the POSIX description states

  The functionality described on this reference page is aligned with
  the ISO C standard. Any conflict between the requirements described
  here and the ISO C standard is unintentional. This volume of
  POSIX.1-2008 defers to the ISO C standard.

Since C99 (which is subsumed by POSXI) as well as subsequent revisions
of C require tmpnam to be provided by conforming implementation, so does
POSIX.


But one should use the recommended replacement functions either way,
e.g. mkstemp ²)


I wouldn't have a problem with using mkstemp in the tests but I don't
view it as important or, since it's a POSIX only API, necessarily even
the best choice for portability.



thanks,
¹)
[OB] [Option Start] Obsolescent [Option End]
The functionality described may be removed in a future version of this
volume of POSIX.1-2017. Strictly Conforming POSIX Applications and
Strictly Conforming XSI Applications shall not use obsolescent
features.


Nothing here suggests that a conforming POSIX implementation need
not provide obsolescent features.  The SUSv4 guide further clarifies
the meaning of obsolescence by saying:

  OB
  Obsolescent
  Features marked as obsolescent are portable to all Single UNIX
  Specification platforms, but may be withdrawn in a future issue.
  This functionality should be avoided.

Since future SUS issues will unavoidably continue to incorporate
C, C features made obsolescent in POSIX cannot be removed until
they are also removed from C.  And since tmpnam is not obsolescent
in C17 and no proposal has been submitted to make it so in C2X,
chances are that the function will continue to be required by
POSIX for the foreseeable future as well.

Martin


²)
https://pubs.opengroup.org/onlinepubs/9699919799/functions/tmpnam.html
---8<---
APPLICATION USAGE
   Applications should use the tmpfile(), mkstemp(), or mkdtemp()
functions instead of the obsolescent tmpnam() function.
---8<---

Re: [PATCH] ia64: Fix C++14 vs. C++17 ABI issue on ia64 [PR94706]

[Jeff Law via Gcc-patches]

On Wed, 2020-04-22 at 15:36 +0200, Jakub Jelinek wrote:
> Hi!
> 
> ia64 seems to be affected too, but the backend doesn't have any
> -Wpsabi warnings and I'm not sure if we really need them for an (almost?)
> dead target.
> 
> Untested by me, but Andreas confirmed it fixed all struct-layout-1.exp
> regressions.  Ok for trunk?
> 
> 2020-04-22  Jakub Jelinek  
> 
>   PR target/94706
>   * config/ia64/ia64.c (hfa_element_mode): Ignore
>   cxx17_empty_base_field_p fields.
OK. 
Jeff

Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

[Qing Zhao via Gcc-patches]

Hi, Richard And Dave:

Thanks a lot for the review and comments.

> On Apr 21, 2020, at 1:46 PM, Richard Sandiford  
> wrote:
> 
> David Malcolm  writes:
>> On Tue, 2020-04-21 at 15:04 +0100, Richard Sandiford wrote
>>> 
>>> Please add:
>>> 
>>> PR c/94230

Will do. 

>>> 
* common.opt: Add -flocation-ranges.
* doc/invoke.texi: Document it.
* toplev.c (process_options): set line_table-
> default_range_bits
to 0 when flag_location_ranges is false. 
>>> 
>>> I think it would be worth adding a hint to use the new option to
>>> get_visual_column, when warning about column tracking being disabled.
>>> This should probably be a second inform(), immediately after the
>>> current one.

Sounds reasonable to me, I will add that.

>>> 
 @@ -14151,6 +14151,13 @@ This option may be useful in conjunction
 with the @option{-B} or
 perform additional processing of the program source between
 normal preprocessing and compilation.
 
 +@item -flocation-ranges
 +@opindex flocation-ranges
>>> 
>>> Normally the documented option should be the non-default one,
>>> so -fno-... in this case.

Okay. 

>>> 
 +Enable range tracking when recording source locations.
 +By default, GCC enables range tracking when recording source
 locations.
 +If disable range tracking by -fno-location-ranges, more location
 space
 +will be saved for column tracking.
>>> 
>>> My understanding is that the patch doesn't actually disable location-
>>> range
>>> tracking, but simply uses a less efficient form for *all* ranges,
>>> rather
>>> than only using the less efficient form for ranges that aren't "caret
>>> at
>>> start, length < 64 chars".
>> 
>> Indeed.

Okay, I see. 
Providing a good documentation at the user level for this option might be a 
challenge to me, I will try.  -:)

>> 
>>> I know you're simply following the suggestion in the PR, sorry,
>> 
>> Sorry.  I did put a caveat on the suggestion FWIW.
>> 
>>> but I wonder if the option should instead be:
>>> 
>>> -flarge-source-files
>>> 
>>> since that seems like a more user-facing concept.  The option would
>>> tell GCC that the source files are likely to be very large and that
>>> GCC should adapt accordingly.  In particular, the option makes GCC
>>> cope with more source lines at the expense of slowing down
>>> compilation
>>> and using more memory.
>> 
>> Another approach would be to go lower-level and introduce a param for
>> this; something like "--param location-range-bits" defaulting to 5; the
>> user can set it to 0 to disable the range-bit optimization to deal with
>> bigger files, and it allows for experimentation without rebuilding the
>> compiler.
>> 
>> Again, I don't know if this is a good idea; I'm thinking aloud; I'm not
>> sure what the best direction here is.
> 
> The reason I like the -flarge-source-files (suggestion for better
> names welcome) is that the user is giving user-level information and
> letting the compiler decide how to deal with that.  What the option
> actually does can change with the implementation as necessary.
> 
> Potentially any user could hit the -Wmisleading-indent note, or could
> hit the limit at which columns get dropped from diagnostics.  So while
> this option isn't going to be used all that often, it also doesn't feel
> like an option designed specifically for “power users” who like to
> experiment with compiler internals.

Agreed, I prefer to use -flarge-source-files for this functionality. 

Let me know if you have any other suggestions for this patch.

Thanks.

Qing


> 
> Thanks,
> Richard

[committed][gcc-9] aarch64: Fix bootstrap with old binutils [PR93053]

[Andre Vieira (lists)]

Went ahead and committed the backport to gcc-9.

As reported in the PR, GCC 10 (and also 9.3.1 but not 9.3.0) fails to build
when using older binutils which lack LSE support, because those instructions
are used in libgcc.
Thanks to Kyrylo's hint, the following patches (hopefully) allow it to build
even with older binutils by using .inst directive if LSE support isn't
available in the assembler.

2020-04-22  Andre Vieira  

    Backport from mainline.
    2020-04-15  Jakub Jelinek  

    PR target/93053
    * configure.ac (LIBGCC_CHECK_AS_LSE): Add HAVE_AS_LSE checking.
    * config/aarch64/lse.S: Include auto-target.h, if HAVE_AS_LSE
    is not defined, use just .arch armv8-a.
    (B, M, N, OPN): Define.
    (COMMENT): New .macro.
    (CAS, CASP, SWP, LDOP): Use .inst directive if HAVE_AS_LSE is not
    defined.  Otherwise, move the operands right after the glue? and
    comment out operands where the macros are used.
    * configure: Regenerated.
    * config.in: Regenerated.

On 22/04/2020 10:59, Kyrylo Tkachov wrote:

Hi Andre,


-Original Message-
From: Andre Vieira (lists) 
Sent: 22 April 2020 09:26
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Cc: Richard Sandiford ; s...@amazon.com
Subject: Re: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics


On 20/04/2020 09:42, Kyrylo Tkachov wrote:

Hi Andre,


-Original Message-
From: Andre Vieira (lists) 
Sent: 16 April 2020 13:24
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Sandiford
; s...@amazon.com
Subject: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics

Hi,

This series backports all the patches and fixes regarding outline
atomics to the gcc-8 branch.

Bootstrapped the series for aarch64-linux-gnu and regression tested.
Is this OK for gcc-8?

Andre Vieira (19):
aarch64: Add early clobber for aarch64_store_exclusive
aarch64: Simplify LSE cas generation
aarch64: Improve cas generation
aarch64: Improve swp generation
aarch64: Improve atomic-op lse generation
aarch64: Remove early clobber from ATOMIC_LDOP scratch
aarch64: Extend %R for integer registers
aarch64: Implement TImode compare-and-swap
aarch64: Tidy aarch64_split_compare_and_swap
aarch64: Add out-of-line functions for LSE atomics
Add visibility to libfunc constructors
aarch64: Implement -moutline-atomics
Aarch64: Fix shrinkwrapping interactions with atomics (PR92692)
aarch64: Fix store-exclusive in load-operate LSE helpers
aarch64: Configure for sys/auxv.h in libgcc for lse-init.c
aarch64: Fix up aarch64_compare_and_swaphi pattern [PR94368]
aarch64: Fix bootstrap with old binutils [PR93053]

Thanks for putting these together.
Before they can go in we need to get this fix for PR93053 into GCC 9.
Can you please test it on that branch to help Jakub out?
Thanks,
Kyrill

Bootstrapped and regression tested the PR93053 fix from Jakub on gcc-9
branch and it looks good.

Thanks, can you please apply the patch to the gcc-9 branch then? (making sure 
the PR markers are there in the commit message so that Bugzilla is updated).
We can then proceed with the GCC 8 backports.

Kyrill


aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]
re PR target/90724 (ICE with __sync_bool_compare_and_swap with
-march=armv8.2-a+sve)
diff --git a/libgcc/config.in b/libgcc/config.in
index 
59a3d8daf52e72e548d3d9425d6043d5e0c663ad..5be5321d2584392bac1ec3af779cd96823212902
 100644
--- a/libgcc/config.in
+++ b/libgcc/config.in
@@ -10,6 +10,9 @@
*/
 #undef HAVE_AS_CFI_SECTIONS
 
+/* Define to 1 if the assembler supports LSE. */
+#undef HAVE_AS_LSE
+
 /* Define to 1 if the target assembler supports thread-local storage. */
 #undef HAVE_CC_TLS
 
diff --git a/libgcc/config/aarch64/lse.S b/libgcc/config/aarch64/lse.S
index 
c7979382ad7770b61bb1c64d32ba2395963a9d7a..f7f1c19587beaec2ccb6371378d54d50139ba1c9
 100644
--- a/libgcc/config/aarch64/lse.S
+++ b/libgcc/config/aarch64/lse.S
@@ -48,8 +48,14 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
  * separately to minimize code size.
  */
 
+#include "auto-target.h"
+
 /* Tell the assembler to accept LSE instructions.  */
+#ifdef HAVE_AS_LSE
.arch armv8-a+lse
+#else
+   .arch armv8-a
+#endif
 
 /* Declare the symbol gating the LSE implementations.  */
.hidden __aarch64_have_lse_atomics
@@ -58,12 +64,19 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #if SIZE == 1
 # define S b
 # define UXT   uxtb
+# define B 0x
 #elif SIZE == 2
 # define S h
 # define UXT   uxth
+# define B 0x4000
 #elif SIZE == 4 || SIZE == 8 || SIZE == 16
 # define S
 # define UXT   mov
+# if SIZE == 4
+#  define B0x8000
+# elif SIZE == 8
+#  define B0xc000
+# endif
 #else
 # error
 #endif
@@ -72,18 +85,26 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 # define SUFF  _relax
 # define A
 # define L
+# define M 0x00
+# define N 0x00
 #elif MODEL == 2
 # define SUFF  _acq
 # define A a
 # define L
+# 

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

[Nathan Sidwell]

On 4/22/20 2:37 AM, Jonathan Wakely via Gcc-patches wrote:

These warnings have nothing to do with virtual functions, so "override"
is inappropriate. The warnings are just talking about defining special
members, so let's say that.

PR translation/94698
* class.c (check_field_decls): Change "override" to "define" in
-Weffc++ diagnostics.

Tested powerpc64le-linux, OK for master?

ok, thanks


--
Nathan Sidwell

Re: [PATCH][RFC] extend DECL_GIMPLE_REG_P to all types

[Richard Biener]

On Wed, 22 Apr 2020, Richard Biener wrote:

> 
> This extends DECL_GIMPLE_REG_P to all types so we can clear
> TREE_ADDRESSABLE even for integers with partial defs, not just
> complex and vector variables.  To make that transition easier
> the patch inverts DECL_GIMPLE_REG_P to DECL_NOT_GIMPLE_REG_P
> since that makes the default the current state for all other
> types besides complex and vectors.  That also nicely simplifies
> code throughout the compiler.
> 
> TREE_ADDRESSABLE and DECL_NOT_GIMPLE_REG_P are now truly
> independent, either set prevents a decl from being rewritten
> into SSA form.
> 
> For the testcase in PR94703 we're able to expand the partial
> def'ed local integer to a register then, producing a single
> movl rather than going through the stack.
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> 
> If there are no objections I'm going to install this once
> stage1 opens.

Of course there was some fallout.  On 32bit x86 gcc.dg/torture/pr71522.c
fails execution because while the GIMPLE is unchanged at RTL expansion
time:

main ()
{
  char s[12];
  long double d;

  MEM  [(char * {ref-all})] = MEM  
[(char * {ref-all})"AAA"];
  MEM  [(char * {ref-all})] = MEM  
[(char * {ref-all})];
  _1 = __builtin_strcmp (, "AAA");
  if (_1 != 0)
...

we now assign 'd' an XFmode register (TREE_ADDRESSABLE is cleared
now since we can set DECL_NOT_GIMPLE_REG_P).  The case is lost
then, impossible to fix up AFAICS.  On x86 all moves to/from
XFmode are normalizing, specifically we end up with

fldt.LC0
fstpt   (%esp)

now the most appealing solution - and totally in the opposite
direction of this patch - is to simply stop expanding non-SSA names
as pseudos.  I do not remember the history as why we do this
but it's likely remanents we preserved from either pre-SSA, times
we did not go into SSA for -O0 or times we really gone out-of-SSA.

There is _some_ good reason to expand a non-SSA "register" into
a pseudo though - namely that RTL is not SSA and thus can accept
partial defs.  And of course that RTL cannot get rid of a stack
slot assigned to a variable.  Today we have somewhat robust
infrastructure to deal with partial defs on GIMPLE, namely
BIT_INSERT_EXPR, but it's not fully exercised.

It's of course possible to fixup the above problematical
cases (there's precenent with discover_nonconstant_array_refs,
which could be "easily" extended to handle "weird" accesses
of non-integral-mode variables) but with the recent discussion
on making RTL expansion more straight-forward I'd bring up
the above idea ... it would get rid of quite some special
code dealing with tcc_reference trees (and MEM_REFs) ending
up operating on registers.

Thanks,
Richard.

Re: [PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

[Christophe Lyon via Gcc-patches]

On Wed, 22 Apr 2020 at 15:16, duanbo (C)  wrote:
>
> Hi
>
> Thank you for your suggestions.
> I have adjust the testcases and used this command to test .
> "runtest --tool gcc --tool_opts -mabi=ilp32  aarch64.exp= 
> reload-valid-spoff.c"
>
> The results of those tests  changed from  unexpected failures to  unsupported.
> Attached please find the v5 patch.
> Any suggestions.
>

Looks good to me, but I'm not a maintainer.

Thanks,

Christophe

> Thanks,
> Duanbo
>
> > -Original Message-
> > From: Christophe Lyon [mailto:christophe.l...@linaro.org]
> > Sent: Wednesday, April 22, 2020 2:41 PM
> > To: duanbo (C) ; GCC Patches  > patc...@gcc.gnu.org>; Richard Sandiford 
> > Subject: Re: [PATCH] aarch64：Add an error message in large code model for
> > ilp32 [PR94577]
> >
> > Hi,
> >
> > After this patch, a few tests are failing when running the testsuite with -
> > mabi=ilp32:
> > gcc.target/aarch64/pr63304_1.c (test for excess errors)
> > gcc.target/aarch64/pr63304_1.c scan-assembler-times adrp 6
> > gcc.target/aarch64/pr70120-2.c (test for excess errors)
> > gcc.target/aarch64/pr94530.c (test for excess errors)
> > gcc.target/aarch64/reload-valid-spoff.c (test for excess errors)
> >
> > All of them fail because of the new error message: would you mind adjusting
> > the tests?
> >
> > Thanks
> >
> > Christophe
> >
> > On Tue, 21 Apr 2020 at 16:10, Richard Sandiford 
> > wrote:
> > >
> > > "duanbo (C)"  writes:
> > > > Hi
> > > >
> > > >> -Original Message-
> > > >> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> > > >> Sent: Monday, April 20, 2020 10:42 PM
> > > >> To: duanbo (C) 
> > > >> Cc: GCC Patches 
> > > >> Subject: Re: [PATCH] aarch64：Add an error message in large code
> > > >> model for
> > > >> ilp32 [PR94577]
> > > >>
> > > >> "duanbo (C)"  writes:
> > > >> > Hi
> > > >> >
> > > >> >> -Original Message-
> > > >> >> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> > > >> >> Sent: Friday, April 17, 2020 9:38 PM
> > > >> >> To: duanbo (C) 
> > > >> >> Cc: Wilco Dijkstra ;
> > > >> >> gcc-patches@gcc.gnu.org
> > > >> >> Subject: Re: [PATCH PR94577] [AArch64] ：Add an error message in
> > > >> >> large code model for ilp32
> > > >> >>
> > > >> >> "duanbo (C)"  writes:
> > > >> >> > Thank you for your suggestions.
> > > >> >> > I have modified accordingly and a full test has been carried,
> > > >> >> > no new failure
> > > >> >> witnessed.
> > > >> >> > Attached please find the new patch which has been adjusted to
> > > >> >> > be suitable
> > > >> >> for git am.
> > > >> >> > Does the v2 patch look better ?
> > > >> >> >
> > > >> >> > Thanks,
> > > >> >> > Duan bo
> > > >> >> >
> > > >> >> > -Original Message-
> > > >> >> > From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
> > > >> >> > Sent: Tuesday, April 14, 2020 4:40 AM
> > > >> >> > To: GCC Patches ; duanbo (C)
> > > >> >> > 
> > > >> >> > Subject: Re: [PATCH PR2] aarch64：Add an error message in
> > > >> >> > large code model for ilp32
> > > >> >> >
> > > >> >> > Hi Duanbo,
> > > >> >> >
> > > >> >> >> This is a simple fix for pr94577.
> > > >> >> >> The option -mabi=ilp32 should not be used in large code model.
> > > >> >> >> Like x86,
> > > >> >> using -mx32 and -mcmodel=large together will result in an error
> > message.
> > > >> >> >> On aarch64, there is no error message for this option conflict.
> > > >> >> >> A solution to this problem can be found in the attached patch.
> > > >> >> >> Bootstrap and tested on aarch64 Linux platform. No new
> > > >> >> >> regression
> > > >> >> witnessed.
> > > >> >> >> Any suggestion?
> > > >> >> >
> > > >> >> > Thanks for your patch, more than 4GB doesn't make any sense
> > > >> >> > with
> > > >> >> > ILP32
> > > >> >> indeed.
> > > >> >> > A few suggestions:
> > > >> >> >
> > > >> >> > It would be good to also update the documentation for
> > > >> >> > -mcmodel=large to
> > > >> >> state it is incompatible with -fpic, -fPIC and -mabi=ilp32.
> > > >> >> >
> > > >> >> > The patch adds a another switch statement on mcmodel that
> > > >> >> > ignores the
> > > >> >> previous processing done (which may changes the selected
> > > >> >> mcmodel). It would be safer and more concise to use one switch
> > > >> >> at the top level and in each case use an if statement to handle the
> > special cases.
> > > >> >> >
> > > >> >> > A few minor nitpics:
> > > >> >> >
> > > >> >> > +   PR  target/94577
> > > >> >> > +   * gcc.target/aarch64/pr94577.c : New test
> > > >> >> >
> > > >> >> > Just like comments, there should be a '.' at the end of changelog
> > entries.
> > > >> >> >
> > > >> >> > AFAICT the format isn't exactly specified, but the email
> > > >> >> > header should be
> > > >> >> like:
> > > >> >> >
> > > >> >> > [PATCH][AArch64] PR94577: Add an error message in large code
> > > >> >> > model for
> > > >> >> > ilp32
> > > >> >> >
> > > >> >> > Sometimes the PR number is also placed in brackets.
> > > >> >> >
> > > >> >> > 

[PATCH] ia64: Fix C++14 vs. C++17 ABI issue on ia64 [PR94706]

[Jakub Jelinek via Gcc-patches]

Hi!

ia64 seems to be affected too, but the backend doesn't have any
-Wpsabi warnings and I'm not sure if we really need them for an (almost?)
dead target.

Untested by me, but Andreas confirmed it fixed all struct-layout-1.exp
regressions.  Ok for trunk?

2020-04-22  Jakub Jelinek  

PR target/94706
* config/ia64/ia64.c (hfa_element_mode): Ignore
cxx17_empty_base_field_p fields.

--- gcc/config/ia64/ia64.c.jj   2020-01-12 11:54:36.338414540 +0100
+++ gcc/config/ia64/ia64.c  2020-04-22 12:49:59.627563114 +0200
@@ -4665,7 +4665,7 @@ hfa_element_mode (const_tree type, bool
 case QUAL_UNION_TYPE:
   for (t = TYPE_FIELDS (type); t; t = DECL_CHAIN (t))
{
- if (TREE_CODE (t) != FIELD_DECL)
+ if (TREE_CODE (t) != FIELD_DECL || cxx17_empty_base_field_p (t))
continue;
 
  mode = hfa_element_mode (TREE_TYPE (t), 1);

Jakub

Re: [PATCH] coroutines: Handle lambda capture objects in the way as clang.

[Nathan Sidwell]

On 4/22/20 8:48 AM, Iain Sandoe wrote:

Hi,

There is no PR for this, at present, but the implementation of
clang and GCC's handling of lambda capture object implicit parms
is currently different.  There is still some discussion about
'correct' interpretation of the standard - but in the short-term
it is probably best to have consistent implementations - even if
those subsequently turn out to be 'consistently wrong'.


Agreed, the std is at best ambigiuous in this area, we should aim for 
implementation agreement.


It would be good to comment as such in the code itself.


+   is_this_parameter (arg)
+   || (DECL_NAME (arg) && DECL_NAME (arg) == closure_identifier);


DECL_NAME (arg) == closure_identifier
is sufficient (it can't be NULL and == an ident :)



+ parm.this_ptr = false;
+ parm.lambda_cobj = is_this_parameter (arg)
+|| (DECL_NAME (arg)
+&& DECL_NAME (arg) == closure_identifier);


and here.

Otherwise ok

nathan


--
Nathan Sidwell

RE: [PATCH 5/5] testsuite: [arm/mve] Include arm_mve.h in arm_v8_1m_mve_ok

[Kyrylo Tkachov]

> -Original Message-
> From: Gcc-patches  On Behalf Of Andre
> Vieira (lists)
> Sent: 14 April 2020 09:40
> To: Christophe Lyon 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 5/5] testsuite: [arm/mve] Include arm_mve.h in
> arm_v8_1m_mve_ok
> 
> 
> On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
> > Since arm_mve.h includes stdint.h, its use requires the presence of
> > the right gnu/stub-*.h, so make sure to include it when checking the
> > arm_v8_1m_mve_ok_nocache effective target, otherwise we can decide
> MVE
> > is supported while it's not really. This makes several tests
> > unsupported rather than fail.
> Hi Christophe,
> 
> LGTM, but you need to wait for maintainer approval.

Ok.
Thanks,
Kyrill

> 
> Cheers,
> Andre
> >
> > 2020-04-10  Christophe Lyon  
> >
> > gcc/testsuite/
> > * lib/target-supports.exp
> > (check_effective_target_arm_v8_1m_mve_ok_nocache): Include
> > arm_mve.h.
> > ---
> >   gcc/testsuite/lib/target-supports.exp | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/gcc/testsuite/lib/target-supports.exp 
> > b/gcc/testsuite/lib/target-
> supports.exp
> > index 6c8dd01..d16498d 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -4965,6 +4965,7 @@ proc
> check_effective_target_arm_v8_1m_mve_ok_nocache { } {
> > #if __ARM_BIG_ENDIAN
> > #error "MVE intrinsics are not supported in Big-Endian mode."
> > #endif
> > +   #include 
> >   } "$flags -mthumb"] } {
> >   set et_arm_v8_1m_mve_flags "$flags -mthumb --save-temps"
> >   return 1

RE: [PATCH 3/5] testsuite: [arm/mve] Fix mve_move_gpr_to_gpr.c

[Kyrylo Tkachov]

> -Original Message-
> From: Gcc-patches  On Behalf Of Andre
> Vieira (lists)
> Sent: 14 April 2020 09:39
> To: christophe Lyon 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 3/5] testsuite: [arm/mve] Fix mve_move_gpr_to_gpr.c
> 
> On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
> > This test can pass with a hard-float toolchain, provided we don't
> > force -mfloat-abi=softfp.
> >
> > This patch removes this useless option, as well as -save-temps which
> > is implied by arm_v8_1m_mve_fp.
> Hi Christophe,
> 
> LGTM, but you need to wait for maintainer approval.

Ok.
Thanks,
Kyrill

> 
> Cheers,
> Andre
> >
> > 2020-04-10  Christophe Lyon  
> >
> > gcc/tesuite/
> > * gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c: Remove
> > useless options.
> > ---
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c | 2
> +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
> > index 374bc4d..53300e5 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
> > +++
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
> > @@ -1,6 +1,6 @@
> >   /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> >   /* { dg-add-options arm_v8_1m_mve_fp } */
> > -/* { dg-additional-options "-O2 -mfloat-abi=softfp --save-temps" } */
> > +/* { dg-additional-options "-O2" } */
> >
> >   #include "arm_mve.h"
> >

RE: [PATCH 4/5] testsuite: [arm/mve] Use dg-add-options arm_v8_1m_mve in MVE tests

[Kyrylo Tkachov]

> -Original Message-
> From: Gcc-patches  On Behalf Of Andre
> Vieira (lists)
> Sent: 14 April 2020 09:38
> To: Christophe Lyon 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 4/5] testsuite: [arm/mve] Use dg-add-options
> arm_v8_1m_mve in MVE tests
> 
> On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
> > Several ARM/MVE tests can be compiled even if the toolchain does not
> > support -mfloat-abi=hard (softfp is OK).
> >
> > Use dg-add-options arm_v8_1m_mve or arm_v8_1m_mve_fp instead of
> using
> > dg-additional-options.
> Hi Christophe,
> 
> I think a bunch of these tests were initially meant to test hard float
> abi with vectors, especially in the MVE integer cases, this is what the
> scan-assemblers are meant to test. However, it seems to pass for
> float-abi=softfp too ... which means these tests don't really mean
> anything. I think it would be good to remove the scan-assembler tests
> for now and improve these tests later with run tests, or some smarter
> function body testing.
> 
> I suggest we apply your changes and I can follow up with a patch to
> remove the scan-assemblers for now, if a maintainer agrees with me that is.
> 

Sure, thanks.
Ok.
Kyrill

> Cheers,
> Andre
> > 2020-04-10  Christophe Lyon  
> >
> > gcc/testsuite/
> > * gcc.target/arm/mve/intrinsics/mve_vector_float.c: Use
> > arm_v8_1m_mve_fp.
> > * gcc.target/arm/mve/intrinsics/mve_vector_float1.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_int.c: Use
> > arm_v8_1m_mve.
> > * gcc.target/arm/mve/intrinsics/mve_vector_int1.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_int2.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_uint.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_uint1.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/mve_vector_uint2.c: Likewise.
> > ---
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c  | 2 +-
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c | 2 +-
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c | 2 +-
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c| 2 +-
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c   | 2 +-
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int2.c   | 2 +-
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint.c   | 2 +-
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint1.c  | 2 +-
> >   gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint2.c  | 2 +-
> >   9 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
> > index 881157f..6519b81 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
> > @@ -1,6 +1,6 @@
> >   /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> > +/* { dg-add-options arm_v8_1m_mve_fp } */
> >   /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
> > {""} }
> */
> > -/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto -
> mfloat-abi=hard -mthumb --save-temps" } */
> >
> >   #include "arm_mve.h"
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
> > index 9515ed6..855e3b8 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
> > @@ -1,6 +1,6 @@
> >   /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> > +/* { dg-add-options arm_v8_1m_mve_fp } */
> >   /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
> > {""} }
> */
> > -/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto -
> mfloat-abi=hard -mthumb --save-temps" } */
> >
> >   #include "arm_mve.h"
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
> > index 3ce8ea3..e3cf8f8 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
> > @@ -1,6 +1,6 @@
> >   /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> > +/* { dg-add-options arm_v8_1m_mve_fp } */
> >   /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
> > {""} }
> */
> > -/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto -
> mfloat-abi=hard -mthumb --save-temps" } */
> >
> >   #include "arm_mve.h"
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
> > 

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

[Christophe Lyon via Gcc-patches]

On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches
 wrote:
>
> On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches
>  wrote:
> >
> > The restrict pass computes the wrong lower bound of the size
> > of accesses to member arrays passed to strncpy as the source:
> > it uses the third argument to the function even though the size
> > of the read is limited by the length of the source when it is
> > a string.  This results in false positive -Warray-bounds
> > warnings in such cases.
> >
> > The attached patch corrects this bug.  In addition, it adjusts
> > the range of offsets of the overlap printed in diagnostics to
> > be in an increasing order (i.e., [LOW, HIGH]), and removes
> > a hack was in place to adjust the offsets that's obviated by
> > the fix above.
> >
> > Tested on x86_64-linux.

Hi,

The update of Warray-bounds-2.c fails on 32 bits targets:
/gcc/testsuite/c-c++-common/Warray-bounds-2.c:192:3: warning:
'strncpy' pointer overflow between offset 2147483647 and size [1, 0]
[-Warray-bounds]
because the uppper limit is hardcoded in the testcase with the 64-bits
value. Can you adjust it?

Thanks

>
> OK.
>
> Richard.
>
> > Martin

Re: [PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

[Christophe Lyon via Gcc-patches]

Hi,


On Tue, 21 Apr 2020 at 18:52, Szabolcs Nagy  wrote:
>
> The 04/17/2020 11:05, Kyrylo Tkachov wrote:
> > Hi Szabolcs,
> >
> > > -Original Message-
> > > From: Szabolcs Nagy 
> > > Sent: 09 April 2020 15:20
> > > To: gcc-patches@gcc.gnu.org
> > > Cc: Richard Earnshaw ; Richard Sandiford
> > > ; Kyrylo Tkachov 
> > > Subject: [PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal
> > > frames [PR94514]
> > >
> > > With -mbranch-protection=pac-ret the debug info toggles the
> > > signedness state of the return address so the unwinder knows when
> > > the return address needs pointer authentication.
> > >
> > > The unwind context flags were not updated according to the dwarf
> > > frame info.
> > >
> > > This causes unwinding across frames that were built without pac-ret
> > > to incorrectly authenticate the return address wich corrupts the
> > > return address on a system where PAuth is enabled.
> > >
> > > Note: This even affects systems where all code use pac-ret because
> > > unwinding across a signal frame the return address is not signed.
> > >
> >
> > Ok, I'm guessing this needs backporting?
>
> committed now,
>
> yes i think it has to go back to gcc-9 and gcc-8,
> i will do that later. thanks.

The new test fails with ilp32, not sure if that's supposed to work?

FAIL: gcc.target/aarch64/pr94514.c (test for excess errors)
Excess errors:
/gcc/testsuite/gcc.target/aarch64/pr94514.c:27:4: warning: cast to
pointer from integer of different size [-Wint-to-pointer-cast]

spawn 
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/invoke-foundation-v8-bare-metal.sh
./pr94514.exe
force_unwind_stop: CFA: 0xef80 PC: 0x80001304 actions: 10
force_unwind_stop: CFA: 0xef90 PC: 0x8000133c actions: 10
Terminated by exception.

*** EXIT code 126
gcc.target/aarch64/pr94514.c execution test (reason: TCL LOOKUP CHANNEL exp7)
FAIL: gcc.target/aarch64/pr94514.c execution test

(executed using the Foundation Model)


The C++ test compiles without warnings, but fails at execution too
(without the force_unwind_stop traces):
PASS: g++.target/aarch64/pr94514.C (test for excess errors)
spawn 
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/invoke-foundation-v8-bare-metal.sh
./pr94514.exe
Terminated by exception.

*** EXIT code 126
g++.target/aarch64/pr94514.C execution test (reason: TCL LOOKUP CHANNEL exp7)
FAIL: g++.target/aarch64/pr94514.C execution test

Maybe you just want to skip the test for ilp32?

Thanks,

Christophe

RE: [PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

[duanbo (C)]

Hi

Thank you for your suggestions.
I have adjust the testcases and used this command to test .
"runtest --tool gcc --tool_opts -mabi=ilp32  aarch64.exp= reload-valid-spoff.c"

The results of those tests  changed from  unexpected failures to  unsupported. 
Attached please find the v5 patch.
Any suggestions.

Thanks,
Duanbo

> -Original Message-
> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
> Sent: Wednesday, April 22, 2020 2:41 PM
> To: duanbo (C) ; GCC Patches  patc...@gcc.gnu.org>; Richard Sandiford 
> Subject: Re: [PATCH] aarch64：Add an error message in large code model for
> ilp32 [PR94577]
> 
> Hi,
> 
> After this patch, a few tests are failing when running the testsuite with -
> mabi=ilp32:
> gcc.target/aarch64/pr63304_1.c (test for excess errors)
> gcc.target/aarch64/pr63304_1.c scan-assembler-times adrp 6
> gcc.target/aarch64/pr70120-2.c (test for excess errors)
> gcc.target/aarch64/pr94530.c (test for excess errors)
> gcc.target/aarch64/reload-valid-spoff.c (test for excess errors)
> 
> All of them fail because of the new error message: would you mind adjusting
> the tests?
> 
> Thanks
> 
> Christophe
> 
> On Tue, 21 Apr 2020 at 16:10, Richard Sandiford 
> wrote:
> >
> > "duanbo (C)"  writes:
> > > Hi
> > >
> > >> -Original Message-
> > >> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> > >> Sent: Monday, April 20, 2020 10:42 PM
> > >> To: duanbo (C) 
> > >> Cc: GCC Patches 
> > >> Subject: Re: [PATCH] aarch64：Add an error message in large code
> > >> model for
> > >> ilp32 [PR94577]
> > >>
> > >> "duanbo (C)"  writes:
> > >> > Hi
> > >> >
> > >> >> -Original Message-
> > >> >> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> > >> >> Sent: Friday, April 17, 2020 9:38 PM
> > >> >> To: duanbo (C) 
> > >> >> Cc: Wilco Dijkstra ;
> > >> >> gcc-patches@gcc.gnu.org
> > >> >> Subject: Re: [PATCH PR94577] [AArch64] ：Add an error message in
> > >> >> large code model for ilp32
> > >> >>
> > >> >> "duanbo (C)"  writes:
> > >> >> > Thank you for your suggestions.
> > >> >> > I have modified accordingly and a full test has been carried,
> > >> >> > no new failure
> > >> >> witnessed.
> > >> >> > Attached please find the new patch which has been adjusted to
> > >> >> > be suitable
> > >> >> for git am.
> > >> >> > Does the v2 patch look better ?
> > >> >> >
> > >> >> > Thanks,
> > >> >> > Duan bo
> > >> >> >
> > >> >> > -Original Message-
> > >> >> > From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
> > >> >> > Sent: Tuesday, April 14, 2020 4:40 AM
> > >> >> > To: GCC Patches ; duanbo (C)
> > >> >> > 
> > >> >> > Subject: Re: [PATCH PR2] aarch64：Add an error message in
> > >> >> > large code model for ilp32
> > >> >> >
> > >> >> > Hi Duanbo,
> > >> >> >
> > >> >> >> This is a simple fix for pr94577.
> > >> >> >> The option -mabi=ilp32 should not be used in large code model.
> > >> >> >> Like x86,
> > >> >> using -mx32 and -mcmodel=large together will result in an error
> message.
> > >> >> >> On aarch64, there is no error message for this option conflict.
> > >> >> >> A solution to this problem can be found in the attached patch.
> > >> >> >> Bootstrap and tested on aarch64 Linux platform. No new
> > >> >> >> regression
> > >> >> witnessed.
> > >> >> >> Any suggestion?
> > >> >> >
> > >> >> > Thanks for your patch, more than 4GB doesn't make any sense
> > >> >> > with
> > >> >> > ILP32
> > >> >> indeed.
> > >> >> > A few suggestions:
> > >> >> >
> > >> >> > It would be good to also update the documentation for
> > >> >> > -mcmodel=large to
> > >> >> state it is incompatible with -fpic, -fPIC and -mabi=ilp32.
> > >> >> >
> > >> >> > The patch adds a another switch statement on mcmodel that
> > >> >> > ignores the
> > >> >> previous processing done (which may changes the selected
> > >> >> mcmodel). It would be safer and more concise to use one switch
> > >> >> at the top level and in each case use an if statement to handle the
> special cases.
> > >> >> >
> > >> >> > A few minor nitpics:
> > >> >> >
> > >> >> > +   PR  target/94577
> > >> >> > +   * gcc.target/aarch64/pr94577.c : New test
> > >> >> >
> > >> >> > Just like comments, there should be a '.' at the end of changelog
> entries.
> > >> >> >
> > >> >> > AFAICT the format isn't exactly specified, but the email
> > >> >> > header should be
> > >> >> like:
> > >> >> >
> > >> >> > [PATCH][AArch64] PR94577: Add an error message in large code
> > >> >> > model for
> > >> >> > ilp32
> > >> >> >
> > >> >> > Sometimes the PR number is also placed in brackets.
> > >> >> >
> > >> >> > Cheers,
> > >> >> > Wilco
> > >> >> >
> > >> >> >
> > >> >> > From feb16a5e5d35d4f632e1be10ce0ac4f4c3505d22 Mon Sep 17
> > >> 00:00:00
> > >> >> 2001
> > >> >> > From: Duan bo 
> > >> >> > Date: Wed, 15 Apr 2020 05:19:31 -0400
> > >> >> > Subject: [PATCH] aarch64: Add an error message in large code
> > >> >> > model for
> > >> >> > ilp32  [PR94577]
> > >> >> >
> > >> >> > The 

[PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

[Jakub Jelinek via Gcc-patches]

Hi!

As mentioned in the PR and on IRC, the recently added struct-layout-1.exp
new tests FAIL on powerpc64le-linux (among other targets).
FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute
in particular.  The problem is that the presence or absence of the C++17
artificial empty base fields, which have non-zero TYPE_SIZE, but zero
DECL_SIZE, change the ABI decisions, if it is present (-std=c++17), the type
might not be considered homogeneous, while if it is absent (-std=c++14), it
can be.

The following patch fixes that and emits a -Wpsabi inform; perhaps more
often than it could, because the fact that rs6000_discover_homogeneous_aggregate
returns true when it didn't in in GCC 7/8/9 with -std=c++17 doesn't still
mean it will make a different ABI decision, but the warning triggered only
on the test I've changed (the struct-layout-1.exp tests use -w -Wno-psabi
already).

Bootstrapped/regtested on powerpc64le-linux, bootstrapped on powerpc64-linux
where regtest is still pending, but homogeneous aggregates are an ELFv2
thing, so I don't expect it to change anything (and so far no such messages
appear in the testsuite log files).

Ok for trunk?

2020-04-22  Jakub Jelinek  

PR target/94707
* config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Add
CXX17_EMPTY_BASE_SEEN argument.  Pass it to recursive calls.
Ignore cxx17_empty_base_field_p fields after setting
*CXX17_EMPTY_BASE_SEEN to true.
(rs6000_discover_homogeneous_aggregate): Adjust
rs6000_aggregate_candidate caller.  With -Wpsabi, diagnose homogeneous
aggregates with C++17 empty base fields.

* g++.dg/tree-ssa/pr27830.C: Use -Wpsabi -w for -std=c++17 and higher.

--- gcc/config/rs6000/rs6000-call.c.jj  2020-03-30 22:53:40.746640328 +0200
+++ gcc/config/rs6000/rs6000-call.c 2020-04-22 13:05:07.947809888 +0200
@@ -5528,7 +5528,8 @@ const struct altivec_builtin_types altiv
sub-tree.  */
 
 static int
-rs6000_aggregate_candidate (const_tree type, machine_mode *modep)
+rs6000_aggregate_candidate (const_tree type, machine_mode *modep,
+   bool *cxx17_empty_base_seen)
 {
   machine_mode mode;
   HOST_WIDE_INT size;
@@ -5598,7 +5599,8 @@ rs6000_aggregate_candidate (const_tree t
|| TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST)
  return -1;
 
-   count = rs6000_aggregate_candidate (TREE_TYPE (type), modep);
+   count = rs6000_aggregate_candidate (TREE_TYPE (type), modep,
+   cxx17_empty_base_seen);
if (count == -1
|| !index
|| !TYPE_MAX_VALUE (index)
@@ -5636,7 +5638,14 @@ rs6000_aggregate_candidate (const_tree t
if (TREE_CODE (field) != FIELD_DECL)
  continue;
 
-   sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep);
+   if (cxx17_empty_base_field_p (field))
+ {
+   *cxx17_empty_base_seen = true;
+   continue;
+ }
+
+   sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep,
+   cxx17_empty_base_seen);
if (sub_count < 0)
  return -1;
count += sub_count;
@@ -5669,7 +5678,8 @@ rs6000_aggregate_candidate (const_tree t
if (TREE_CODE (field) != FIELD_DECL)
  continue;
 
-   sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep);
+   sub_count = rs6000_aggregate_candidate (TREE_TYPE (field), modep,
+   cxx17_empty_base_seen);
if (sub_count < 0)
  return -1;
count = count > sub_count ? count : sub_count;
@@ -5710,7 +5720,9 @@ rs6000_discover_homogeneous_aggregate (m
   && AGGREGATE_TYPE_P (type))
 {
   machine_mode field_mode = VOIDmode;
-  int field_count = rs6000_aggregate_candidate (type, _mode);
+  bool cxx17_empty_base_seen = false;
+  int field_count = rs6000_aggregate_candidate (type, _mode,
+   _empty_base_seen);
 
   if (field_count > 0)
{
@@ -5725,6 +5737,17 @@ rs6000_discover_homogeneous_aggregate (m
*elt_mode = field_mode;
  if (n_elts)
*n_elts = field_count;
+ if (cxx17_empty_base_seen && warn_psabi)
+   {
+ static const_tree last_reported_type;
+ if (type != last_reported_type)
+   {
+ inform (input_location,
+ "prior to GCC 10, parameters of type "
+ "%qT were passed incorrectly for C++17", type);
+ last_reported_type = type;

RE: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

[Yangfei (Felix)]

Hi,

> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, April 22, 2020 6:03 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-
> regs-only and sve
> 
> Mostly LGTM, just a couple of minor points:

Thanks for the very careful code review.  :-) 
I think the revised patch fixed these points.  
GCC builds OK and the newly added test still works. 
Please help push if it's good to go. 

Felix


0001-aarch64-unexpected-result-with-mgeneral-regs-only-an.patch
Description: 0001-aarch64-unexpected-result-with-mgeneral-regs-only-an.patch

[GCC][PATCH][ARM]: Modify the MVE polymorphic variant arguments to match the MVE intrinsic definition.

[Srinath Parvathaneni]

Hello,

When MVE intrinsic's are called, few implicit typecasting are done on the 
formal arguments to match the intrinsic parameters.
But when same intrinsics are called through MVE polymorphic variants, _Generic 
feature used here does strict type checking and fails to match the exact 
intrinsic.
This patch corrects the behaviour of polymorphic variants and match the 
expected intrinsic by explicitly typecasting the polymorphic variant's 
arguments.

Please refer to M-profile Vector Extension (MVE) intrinsics [1]  for more 
details.
[1] 
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics

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

Ok for trunk?

Thanks,
Srinath.

gcc/ChangeLog:

2020-04-22  Srinath Parvathaneni  

* config/arm/arm_mve.h (__arm_vbicq_n_u16): Modify function parameter's
datatype.
(__arm_vbicq_n_s16): Likewise.
(__arm_vbicq_n_u32): Likewise.
(__arm_vbicq_n_s32): Likewise.
(__arm_vbicq): Likewise.
(__arm_vbicq_n_s16): Modify MVE polymorphic variant argument's datatype.
(__arm_vbicq_n_s32): Likewise.
(__arm_vbicq_n_u16): Likewise.
(__arm_vbicq_n_u32): Likewise.
(__arm_vdupq_m_n_s8): Likewise.
(__arm_vdupq_m_n_s16): Likewise.
(__arm_vdupq_m_n_s32): Likewise.
(__arm_vdupq_m_n_u8): Likewise.
(__arm_vdupq_m_n_u16): Likewise.
(__arm_vdupq_m_n_u32): Likewise.
(__arm_vdupq_m_n_f16): Likewise.
(__arm_vdupq_m_n_f32): Likewise.
(__arm_vldrhq_gather_offset_s16): Likewise.
(__arm_vldrhq_gather_offset_s32): Likewise.
(__arm_vldrhq_gather_offset_u16): Likewise.
(__arm_vldrhq_gather_offset_u32): Likewise.
(__arm_vldrhq_gather_offset_f16): Likewise.
(__arm_vldrhq_gather_offset_z_s16): Likewise.
(__arm_vldrhq_gather_offset_z_s32): Likewise.
(__arm_vldrhq_gather_offset_z_u16): Likewise.
(__arm_vldrhq_gather_offset_z_u32): Likewise.
(__arm_vldrhq_gather_offset_z_f16): Likewise.
(__arm_vldrhq_gather_shifted_offset_s16): Likewise.
(__arm_vldrhq_gather_shifted_offset_s32): Likewise.
(__arm_vldrhq_gather_shifted_offset_u16): Likewise.
(__arm_vldrhq_gather_shifted_offset_u32): Likewise.
(__arm_vldrhq_gather_shifted_offset_f16): Likewise.
(__arm_vldrhq_gather_shifted_offset_z_s16): Likewise.
(__arm_vldrhq_gather_shifted_offset_z_s32): Likewise.
(__arm_vldrhq_gather_shifted_offset_z_u16): Likewise.
(__arm_vldrhq_gather_shifted_offset_z_u32): Likewise.
(__arm_vldrhq_gather_shifted_offset_z_f16): Likewise.
(__arm_vldrwq_gather_offset_s32): Likewise.
(__arm_vldrwq_gather_offset_u32): Likewise.
(__arm_vldrwq_gather_offset_f32): Likewise.
(__arm_vldrwq_gather_offset_z_s32): Likewise.
(__arm_vldrwq_gather_offset_z_u32): Likewise.
(__arm_vldrwq_gather_offset_z_f32): Likewise.
(__arm_vldrwq_gather_shifted_offset_s32): Likewise.
(__arm_vldrwq_gather_shifted_offset_u32): Likewise.
(__arm_vldrwq_gather_shifted_offset_f32): Likewise.
(__arm_vldrwq_gather_shifted_offset_z_s32): Likewise.
(__arm_vldrwq_gather_shifted_offset_z_u32): Likewise.
(__arm_vldrwq_gather_shifted_offset_z_f32): Likewise.
(__arm_vdwdupq_x_n_u8): Likewise.
(__arm_vdwdupq_x_n_u16): Likewise.
(__arm_vdwdupq_x_n_u32): Likewise.
(__arm_viwdupq_x_n_u8): Likewise.
(__arm_viwdupq_x_n_u16): Likewise.
(__arm_viwdupq_x_n_u32): Likewise.
(__arm_vidupq_x_n_u8): Likewise.
(__arm_vddupq_x_n_u8): Likewise.
(__arm_vidupq_x_n_u16): Likewise.
(__arm_vddupq_x_n_u16): Likewise.
(__arm_vidupq_x_n_u32): Likewise.
(__arm_vddupq_x_n_u32): Likewise.
(__arm_vldrdq_gather_offset_s64): Likewise.
(__arm_vldrdq_gather_offset_u64): Likewise.
(__arm_vldrdq_gather_offset_z_s64): Likewise.
(__arm_vldrdq_gather_offset_z_u64): Likewise.
(__arm_vldrdq_gather_shifted_offset_s64): Likewise.
(__arm_vldrdq_gather_shifted_offset_u64): Likewise.
(__arm_vldrdq_gather_shifted_offset_z_s64): Likewise.
(__arm_vldrdq_gather_shifted_offset_z_u64): Likewise.
(__arm_vidupq_m_n_u8): Likewise.
(__arm_vidupq_m_n_u16): Likewise.
(__arm_vidupq_m_n_u32): Likewise.
(__arm_vddupq_m_n_u8): Likewise.
(__arm_vddupq_m_n_u16): Likewise.
(__arm_vddupq_m_n_u32): Likewise.
(__arm_vidupq_n_u16): Likewise.
(__arm_vidupq_n_u32): Likewise.
(__arm_vidupq_n_u8): Likewise.
(__arm_vddupq_n_u16): Likewise.
(__arm_vddupq_n_u32): Likewise.
(__arm_vddupq_n_u8): Likewise.

gcc/testsuite/ChangeLog:

2020-04-22  Srinath Parvathaneni  

* gcc.target/arm/mve/intrinsics/mve_vddupq_m_n_u16.c: New test.
* 

Re: [PATCH][v3], rs6000: Use plq/pstq for atomic_{load, store} (PR94622)

[Segher Boessenkool]

Hi!

On Tue, Apr 21, 2020 at 04:53:53PM -0500, Aaron Sawdey via Gcc-patches wrote:
> For future architecture with prefix instructions, always use plq/pstq
> rather than lq/stq for atomic load of quadword. Then we never have to
> do the doubleword swap on little endian. Before this fix, -mno-pcrel
> would generate lq with the doubleword swap (which was ok) and -mpcrel
> would generate plq, also with the doubleword swap, which was wrong.

> 2020-04-20  Aaron Sawdey  
> 
>   PR target/94622
>   * config/rs6000/sync.md (load_quadpti): Add attr "prefixed"
>   if TARGET_PREFIXED.
>   (store_quadpti): Ditto.
>   (atomic_load): Do not swap doublewords if TARGET_PREFIXED as
>   plq will be used and doesn't need it.
>   (atomic_store): Ditto, for pstq.

> +;; Pattern load_quadpti will always use plq for atomic TImode if
> +;; TARGET_PREFIXED.  It has the correct doubleword ordering on either LE
> +;; or BE, so we can just move the result into the output register and
> +;; do not need to do the doubleword swap for LE. Also this avoids any
> +;; confusion about whether the lq vs plq might be used based on whether
> +;; op1 has PC-relative addressing. We could potentially allow BE to
> +;; use lq because it doesn't have the doubleword ordering problem.

Two spaces after dot (twice).

Thanks for the nice comments :-)

> -  [(set_attr "type" "store")])
> +  [(set_attr "type" "store")
> +   (set (attr "prefixed") (if_then_else (match_test "TARGET_PREFIXED")
> +(const_string "yes")
> +(const_string "no")))])

Every 8 leading spaces should be a tab (it's annoying to have a mixture
of styles, and then later to have patches randomly change such things as
well.  Spaces everywhere (no tabs ever) works fine for me, but that is
not what we use, not in GCC, and not in our port.  We could change that
in GCC 11 perhaps?  Opinions?)

The patch is okay for trunk modulo those nits.  Thanks!


Segher

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 22, 2020 at 01:33:45PM +0100, Richard Sandiford wrote:
> Jakub Jelinek  writes:
> > On Wed, Apr 22, 2020 at 12:17:02PM +0100, Richard Sandiford wrote:
> >> But my point was that, if the DECL_NAME does actually act to exclude
> >
> > I'm fine with dropping DECL_NAME test there, on the other side would like to
> > add
> >   && TYPE_SIZE (TREE_TYPE (field))
> >   && !integer_zerop (TYPE_SIZE (TREE_TYPE (field)))
> > in there because that is what all these empty bases should satisfy too.
> 
> Sounds good to me FWIW.

Thus below in the patch form.  Ok for trunk?

> > /* Verify that other zero sized fields don't affect the
> >ABI decisions.  */
> > if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)))
> >   gcc_assert (sub_count == 0);
> >
> > if (sub_count < 0)
> >   return -1;
> > count += sub_count;
> > ?
> 
> I fear this will actually trip in practice, but I'd have to go back and
> check.  (This came up in the context of the SVE parameter-passing rules,
> where we ended up deliberately checking DECL_SIZE to avoid zero-size
> user-level decls.)
> 
> E.g. I'd expect a :0 bitfield to have a zero size and an integer
> TREE_TYPE, so the recursive call should return -1.  AIUI we should
> skip these kinds of bitfield too, but again that's just my understanding,
> not a definitive statement.

Indeed, struct S { int : 0; }; in C has (at least on x86) sizeof 0, so
does struct T { struct S a, b, c, d; };
Sure, the backend needs to decide whether those change the ABI decisions or
not.
E.g. on rs6000 where I was considering similar check that assertion
triggers on
struct S { int : 0; };
struct T { struct S a, b, c, d; } t;
struct U { struct T e; float f, g, h, i; } u;
void foo (struct U);
int
bar (void)
{
  foo (u);
  return 1;
}

2020-04-22  Jakub Jelinek  

PR target/94383
* calls.h (cxx17_empty_base_field_p): Declare.
* calls.c (cxx17_empty_base_field_p): Define.

--- gcc/calls.h.jj  2020-01-12 11:54:36.214416411 +0100
+++ gcc/calls.h 2020-04-22 11:44:09.037853379 +0200
@@ -135,5 +135,6 @@ extern tree get_attr_nonstring_decl (tre
 extern void maybe_warn_nonstring_arg (tree, tree);
 extern bool get_size_range (tree, tree[2], bool = false);
 extern rtx rtx_for_static_chain (const_tree, bool);
+extern bool cxx17_empty_base_field_p (const_tree);
 
 #endif // GCC_CALLS_H
--- gcc/calls.c.jj  2020-03-27 22:27:09.615964438 +0100
+++ gcc/calls.c 2020-04-22 11:44:17.621722376 +0200
@@ -6261,5 +6261,23 @@ must_pass_va_arg_in_stack (tree type)
   return targetm.calls.must_pass_in_stack (arg);
 }
 
+/* Return true if FIELD is the C++17 empty base field that should
+   be ignored for ABI calling convention decisions in order to
+   maintain ABI compatibility between C++14 and earlier, which doesn't
+   add this FIELD to classes with empty bases, and C++17 and later
+   which does.  */
+
+bool
+cxx17_empty_base_field_p (const_tree field)
+{
+  return (TREE_CODE (field) == FIELD_DECL
+ && DECL_ARTIFICIAL (field)
+ && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
+ && DECL_SIZE (field)
+ && integer_zerop (DECL_SIZE (field))
+ && TYPE_SIZE (TREE_TYPE (field))
+ && !integer_zerop (TYPE_SIZE (TREE_TYPE (field;
+}
+
 /* Tell the garbage collector about GTY markers in this source file.  */
 #include "gt-calls.h"


Jakub

[PATCH] coroutines: Handle lambda capture objects in the way as clang.

[Iain Sandoe]

Hi,

There is no PR for this, at present, but the implementation of
clang and GCC's handling of lambda capture object implicit parms
is currently different.  There is still some discussion about
'correct' interpretation of the standard - but in the short-term
it is probably best to have consistent implementations - even if
those subsequently turn out to be 'consistently wrong'.

To bring GCC to the same as currently released clang versions we
need to:

 * omit the capture object type from the parameter pack used
to select the traits.
 * omit the capture object pointer from the promise parameters
   preview.

This patch implements that change,
tested on x86_64-darwin16,

thoughts?
Iain

gcc/cp/ChangeLog:

2020-04-22  Iain Sandoe  

* coroutines.cc (instantiate_coro_traits): Do not add the
type of any lambda capture object to the traits lookup.
(struct param_info): Note that we have a lambda capture
object.
(morph_fn_to_coro): Do not add lambda capture object pointers
to the promise parameters preview.
---
 gcc/cp/coroutines.cc | 69 +++-
 1 file changed, 56 insertions(+), 13 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index b1d91f84cae..5380bc45d44 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -297,21 +297,48 @@ instantiate_coro_traits (tree fndecl, location_t kw)
 
   tree functyp = TREE_TYPE (fndecl);
   tree arg_node = TYPE_ARG_TYPES (functyp);
-  tree argtypes = make_tree_vec (list_length (arg_node)-1);
-  unsigned p = 0;
+  tree arg = DECL_ARGUMENTS (fndecl);
+  unsigned num_args = list_length (arg_node) - 1;
 
-  while (arg_node != NULL_TREE && !VOID_TYPE_P (TREE_VALUE (arg_node)))
+  bool lambda_p = LAMBDA_TYPE_P (DECL_CONTEXT (fndecl));
+  if (lambda_p && num_args >= 1)
+num_args -= 1;
+
+  tree argtypepack = NULL_TREE;
+  tree targ;
+  /* If we have no arguments, after removing any lambda closure object
+ pointer, then there's no pack to make.  */
+  if (num_args)
 {
-  TREE_VEC_ELT (argtypes, p++) = TREE_VALUE (arg_node);
-  arg_node = TREE_CHAIN (arg_node);
-}
+  tree argtypes = make_tree_vec (num_args);
+  unsigned p = 0;
 
-  tree argtypepack = cxx_make_type (TYPE_ARGUMENT_PACK);
-  SET_ARGUMENT_PACK_ARGS (argtypepack, argtypes);
+  while (arg_node != NULL_TREE && !VOID_TYPE_P (TREE_VALUE (arg_node)))
+   {
+ /* Lambda closure object pointers are named 'this' when the lambda
+is a class method, and __closure otherwise.  */
+ bool is_closure_obj =
+   is_this_parameter (arg)
+   || (DECL_NAME (arg) && DECL_NAME (arg) == closure_identifier);
+ if (lambda_p && is_closure_obj)
+   ; /* Skip the arg type.  */
+ else
+   TREE_VEC_ELT (argtypes, p++) = TREE_VALUE (arg_node);
+ arg_node = TREE_CHAIN (arg_node);
+ arg = DECL_CHAIN (arg);
+   }
 
-  tree targ = make_tree_vec (2);
-  TREE_VEC_ELT (targ, 0) = TREE_TYPE (functyp);
-  TREE_VEC_ELT (targ, 1) = argtypepack;
+  argtypepack = cxx_make_type (TYPE_ARGUMENT_PACK);
+  SET_ARGUMENT_PACK_ARGS (argtypepack, argtypes);
+  targ = make_tree_vec (2);
+  TREE_VEC_ELT (targ, 0) = TREE_TYPE (functyp);
+  TREE_VEC_ELT (targ, 1) = argtypepack;
+}
+  else
+{
+  targ = make_tree_vec (1);
+  TREE_VEC_ELT (targ, 0) = TREE_TYPE (functyp);
+}
 
   tree traits_class
 = lookup_template_class (coro_traits_templ, targ,
@@ -1769,6 +1796,7 @@ struct param_info
   bool pt_ref;   /* Was a pointer to object.  */
   bool trivial_dtor; /* The frame type has a trivial DTOR.  */
   bool this_ptr; /* Is 'this' */
+  bool lambda_cobj;  /* Lambda capture object */
 };
 
 struct local_var_info
@@ -3241,6 +3269,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
  The second two entries start out empty - and only get populated
  when we see uses.  */
   param_uses = new hash_map;
+  bool lambda_p = LAMBDA_TYPE_P (DECL_CONTEXT (orig));
 
   for (tree arg = DECL_ARGUMENTS (orig); arg != NULL;
   arg = DECL_CHAIN (arg))
@@ -3280,7 +3309,19 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
}
  else
parm.frame_type = actual_type;
- parm.this_ptr = is_this_parameter (arg);
+ if (lambda_p)
+   {
+ parm.this_ptr = false;
+ parm.lambda_cobj = is_this_parameter (arg)
+|| (DECL_NAME (arg)
+&& DECL_NAME (arg) == closure_identifier);
+   }
+ else
+   {
+ parm.lambda_cobj = false;
+ parm.this_ptr = is_this_parameter (arg);
+   }
+
  parm.trivial_dtor = TYPE_HAS_TRIVIAL_DESTRUCTOR (parm.frame_type);
  tree pname = DECL_NAME (arg);
  char *buf = xasprintf ("__parm.%s", IDENTIFIER_POINTER (pname));

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Richard Sandiford]

Jakub Jelinek  writes:
> On Wed, Apr 22, 2020 at 12:17:02PM +0100, Richard Sandiford wrote:
>> But my point was that, if the DECL_NAME does actually act to exclude
>
> I'm fine with dropping DECL_NAME test there, on the other side would like to
> add
>   && TYPE_SIZE (TREE_TYPE (field))
>   && !integer_zerop (TYPE_SIZE (TREE_TYPE (field)))
> in there because that is what all these empty bases should satisfy too.

Sounds good to me FWIW.

> If the predicate says that it is the C++17 empty base field, then it better
> should be a narrow check.
> Now, in the backend, one has the -Wpsabi diagnostics that also talks about
> C++17, so I think it is better to use that predicate in there.

Ack.

> But, what one could do is verify that all other
> if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)))
> fields don't matter for the ABI decisions.
> So
> if (TREE_CODE (field) != FIELD_DECL)
>   continue;
>
>   if (cxx17_empty_base_field_p (field))
> {
>   /* hint -Wpsabi warning here somehow.  */
>   continue;
> }
>
> sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep);
>
>   /* Verify that other zero sized fields don't affect the
>  ABI decisions.  */
>   if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)))
> gcc_assert (sub_count == 0);
>
> if (sub_count < 0)
>   return -1;
> count += sub_count;
> ?

I fear this will actually trip in practice, but I'd have to go back and
check.  (This came up in the context of the SVE parameter-passing rules,
where we ended up deliberately checking DECL_SIZE to avoid zero-size
user-level decls.)

E.g. I'd expect a :0 bitfield to have a zero size and an integer
TREE_TYPE, so the recursive call should return -1.  AIUI we should
skip these kinds of bitfield too, but again that's just my understanding,
not a definitive statement.

Either way, I think we should deal with the other zero-size cases
separately after GCC 10.

Thanks,
Richard

Re: [PATCH] tree-inline: Simplify IPA-CP type conversion (PR 93385)

[Richard Biener]

On Wed, 22 Apr 2020, Martin Jambor wrote:

> Hi,
> 
> when callers and callees do not quite agree on the type of a
> parameter, usually with ill-defined K or with smilarly wrong LTO
> input, IPA-CP can attempt to try and substitute a wrong type for a
> parameter (see e.g. gcc.dg/torture/pr48063.c).  Function
> tree_function_versioning attempts to handle this in order not to
> create invalid gimple but it then creates the mapping using
> setup_one_parameter which also handles the same situation to avoid
> similar problems when inlining and in more defined way.
> 
> So this patch simply removes the conversion attempts in
> tree_function_versioning itself.  It is helpful for my upcoming fix of
> PR 93385 because then I do not need to teach
> ipa_param_body_adjustments to distinguish between successful and
> unsuccessful mappings - setup_one_parameter uses force_value_to_type
> for conversions which simly maps the worst cases to zero.
> 
> Bootstrapped, LTO-bootstrapped and tested on x86_64-linux.  I assume
> this should wait until GCC 11 stage 1 but note that if we want to
> backport a fix for PR 93385 later, this will probably be a prerequisite.
> 
> So, OK for trunk in stage 1?

OK for stage1.

Thanks,
Richard.

> Thanks,
> 
> Martin
> 
> 
> 2020-04-21  Martin Jambor  
> 
>   PR ipa/93385
>   * tree-inline.c (tree_function_versioning): Leave any type conversion
>   of replacements to setup_one_parameter and its friend
>   force_value_to_type.
> ---
>  gcc/ChangeLog |  7 +++
>  gcc/tree-inline.c | 42 +-
>  2 files changed, 12 insertions(+), 37 deletions(-)
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 1edb5f2d70b..2578b6251af 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,10 @@
> +2020-04-21  Martin Jambor  
> +
> + PR ipa/93385
> + * tree-inline.c (tree_function_versioning): Leave any type conversion
> + of replacements to setup_one_parameter and its friend
> + force_value_to_type.
> +
>  2020-04-18  Jeff Law  
>  
>   PR debug/94439
> diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
> index 26c23f504be..fb1850382af 100644
> --- a/gcc/tree-inline.c
> +++ b/gcc/tree-inline.c
> @@ -6260,46 +6260,14 @@ tree_function_versioning (tree old_decl, tree 
> new_decl,
> p = new_param_indices[p];
>  
>   tree parm;
> - tree req_type, new_type;
> -
>   for (parm = DECL_ARGUMENTS (old_decl); p;
>parm = DECL_CHAIN (parm))
> p--;
> - tree old_tree = parm;
> - req_type = TREE_TYPE (parm);
> - new_type = TREE_TYPE (replace_info->new_tree);
> - if (!useless_type_conversion_p (req_type, new_type))
> -   {
> - if (fold_convertible_p (req_type, replace_info->new_tree))
> -   replace_info->new_tree
> - = fold_build1 (NOP_EXPR, req_type, replace_info->new_tree);
> - else if (TYPE_SIZE (req_type) == TYPE_SIZE (new_type))
> -   replace_info->new_tree
> - = fold_build1 (VIEW_CONVERT_EXPR, req_type,
> -replace_info->new_tree);
> - else
> -   {
> - if (dump_file)
> -   {
> - fprintf (dump_file, "const ");
> - print_generic_expr (dump_file,
> - replace_info->new_tree);
> - fprintf (dump_file,
> -  "  can't be converted to param ");
> - print_generic_expr (dump_file, parm);
> - fprintf (dump_file, "\n");
> -   }
> - old_tree = NULL;
> -   }
> -   }
> -
> - if (old_tree)
> -   {
> - init = setup_one_parameter (, old_tree, replace_info->new_tree,
> - id.src_fn, NULL, );
> - if (init)
> -   init_stmts.safe_push (init);
> -   }
> + gcc_assert (parm);
> + init = setup_one_parameter (, parm, replace_info->new_tree,
> + id.src_fn, NULL, );
> + if (init)
> +   init_stmts.safe_push (init);
>}
>  
>ipa_param_body_adjustments *param_body_adjs = NULL;
> 

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

[PATCH][arm] Add initial support for Arm Cortex-M55

[Kyrylo Tkachov]

Hi all,

This patch adds initial -mcpu support for the Arm Cortex-M55 CPU.
This CPU is an Armv8.1-M Mainline CPU supporting MVE.
An option to disable floating-point (and MVE) is provided with the +nofp.
For GCC 11 I'd like to add further fine-grained options to enable integer-only 
MVE
but that needs a bit more elaborate surgery in arm-cpus.in that I don't want to 
do
in GCC 10 at this stage.

As this CPU is not supported in gas and I don't want to couple GCC 10 to the 
very
latest binutils anyway, this CPU emits the cpu string in the assembly file as a 
build attribute
rather than a .cpu directive, thus sparing us the need to support .cpu 
cortex-m55 in gas.
The .cpu directive in gas isn't used for anything besides setting the 
Tag_CPU_name 
build attribute anyway (which itself is not used by any tools I'm aware of).
All the architecture information used for target detection is already emitted 
using .arch_extension
directives and similar.

Bootstrapped and tested on arm-none-linux-gnueabihf. Also tested on 
arm-none-eabi.

Committing to trunk.
Thanks,
Kyrill

2020-04-22  Kyrylo Tkachov  
Andre Vieira  
Mihail Ionescu  

* config/arm/arm.c (arm_file_start): Handle isa_bit_quirk_no_asmcpu.
* config/arm/arm-cpus.in (quirk_no_asmcpu): Define.
(ALL_QUIRKS): Add quirk_no_asmcpu.
(cortex-m55): Define new cpu.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/arm-tune.md: Likewise.
* doc/invoke.texi (Arm Options): Document -mcpu=cortex-m55.


m55-kyrill.patch
Description: m55-kyrill.patch

Re: [PATCH v2] S/390: Fix several test cases

[Andreas Krebbel via Gcc-patches]

On 22.04.20 13:56, Stefan Schulze Frielinghaus wrote:
> Hi,
> 
> Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`.
> Ok for master?
> 
> Cheers,
> Stefan
> 
> gcc/ChangeLog:
> 
> 2020-04-21  Stefan Schulze Frielinghaus  
> 
> * config/s390/s390.md ("*_ior_and_sr_ze"): lift from SI
>   mode to DSI ("*trunc_sidi_and_subreg_ze"): new
>   insn pattern
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-04-21  Stefan Schulze Frielinghaus  
> 
> * gcc.target/s390/addsub-signed-overflow-1.c: fix options
> * gcc.target/s390/addsub-signed-overflow-2.c: fix options
> * gcc.target/s390/bswap-1.c: fix scan assembler regex
> * gcc.target/s390/global-array-element-pic2.c: fix scan assembler 
> regex
> * gcc.target/s390/load-relative-check.c: fix options
> * gcc.target/s390/morestack.c: fix options
> * gcc.target/s390/nobp-return-mem-z900.c: temporarily silence this 
> case
> * gcc.target/s390/risbg-ll-1.c: fix scan assembler regex
> * gcc.target/s390/risbg-ll-2.c: fix scan assembler regex
> * gcc.target/s390/risbg-ll-3.c: fix scan assembler regex
> * gcc.target/s390/target-attribute/pr82012.c: fix error message

The changelog descriptions are supposed to have a capital first letter and . at 
the end. Ok with
that change!

Thanks!

Andreas

Re: [Patch, committed][Fortran] Truncate warn with OpenMP/OpenACC/!GCC$ (PR94709)

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 22, 2020 at 01:53:00PM +0200, Tobias Burnus wrote:
>   PR fortran/94709
>   * scanner.c (load_line): In fixed form, also tread 'C' as comment and

s/tread/treat/

>   'D'/'d' only with -fd-lines-as-comments. Treat '!$' with -fopenmp,
>   '!$acc' with -fopenacc and '!GCC$' as non-comment to permit 
>   and truncation warnings.
> 
>   PR fortran/94709
>   * gfortran.dg/gomp/warn_truncated.f: New.
>   * gfortran.dg/gomp/warn_truncated.f90: New.

LGTM.

Jakub

[PATCH] tree-inline: Simplify IPA-CP type conversion (PR 93385)

[Martin Jambor]

Hi,

when callers and callees do not quite agree on the type of a
parameter, usually with ill-defined K or with smilarly wrong LTO
input, IPA-CP can attempt to try and substitute a wrong type for a
parameter (see e.g. gcc.dg/torture/pr48063.c).  Function
tree_function_versioning attempts to handle this in order not to
create invalid gimple but it then creates the mapping using
setup_one_parameter which also handles the same situation to avoid
similar problems when inlining and in more defined way.

So this patch simply removes the conversion attempts in
tree_function_versioning itself.  It is helpful for my upcoming fix of
PR 93385 because then I do not need to teach
ipa_param_body_adjustments to distinguish between successful and
unsuccessful mappings - setup_one_parameter uses force_value_to_type
for conversions which simly maps the worst cases to zero.

Bootstrapped, LTO-bootstrapped and tested on x86_64-linux.  I assume
this should wait until GCC 11 stage 1 but note that if we want to
backport a fix for PR 93385 later, this will probably be a prerequisite.

So, OK for trunk in stage 1?

Thanks,

Martin


2020-04-21  Martin Jambor  

PR ipa/93385
* tree-inline.c (tree_function_versioning): Leave any type conversion
of replacements to setup_one_parameter and its friend
force_value_to_type.
---
 gcc/ChangeLog |  7 +++
 gcc/tree-inline.c | 42 +-
 2 files changed, 12 insertions(+), 37 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1edb5f2d70b..2578b6251af 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2020-04-21  Martin Jambor  
+
+   PR ipa/93385
+   * tree-inline.c (tree_function_versioning): Leave any type conversion
+   of replacements to setup_one_parameter and its friend
+   force_value_to_type.
+
 2020-04-18  Jeff Law  
 
PR debug/94439
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 26c23f504be..fb1850382af 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -6260,46 +6260,14 @@ tree_function_versioning (tree old_decl, tree new_decl,
  p = new_param_indices[p];
 
tree parm;
-   tree req_type, new_type;
-
for (parm = DECL_ARGUMENTS (old_decl); p;
 parm = DECL_CHAIN (parm))
  p--;
-   tree old_tree = parm;
-   req_type = TREE_TYPE (parm);
-   new_type = TREE_TYPE (replace_info->new_tree);
-   if (!useless_type_conversion_p (req_type, new_type))
- {
-   if (fold_convertible_p (req_type, replace_info->new_tree))
- replace_info->new_tree
-   = fold_build1 (NOP_EXPR, req_type, replace_info->new_tree);
-   else if (TYPE_SIZE (req_type) == TYPE_SIZE (new_type))
- replace_info->new_tree
-   = fold_build1 (VIEW_CONVERT_EXPR, req_type,
-  replace_info->new_tree);
-   else
- {
-   if (dump_file)
- {
-   fprintf (dump_file, "const ");
-   print_generic_expr (dump_file,
-   replace_info->new_tree);
-   fprintf (dump_file,
-"  can't be converted to param ");
-   print_generic_expr (dump_file, parm);
-   fprintf (dump_file, "\n");
- }
-   old_tree = NULL;
- }
- }
-
-   if (old_tree)
- {
-   init = setup_one_parameter (, old_tree, replace_info->new_tree,
-   id.src_fn, NULL, );
-   if (init)
- init_stmts.safe_push (init);
- }
+   gcc_assert (parm);
+   init = setup_one_parameter (, parm, replace_info->new_tree,
+   id.src_fn, NULL, );
+   if (init)
+ init_stmts.safe_push (init);
   }
 
   ipa_param_body_adjustments *param_body_adjs = NULL;
-- 
2.26.0

[PATCH v2] S/390: Fix several test cases

[Stefan Schulze Frielinghaus via Gcc-patches]

Hi,

Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`.
Ok for master?

Cheers,
Stefan

gcc/ChangeLog:

2020-04-21  Stefan Schulze Frielinghaus  

* config/s390/s390.md ("*_ior_and_sr_ze"): lift from SI
  mode to DSI ("*trunc_sidi_and_subreg_ze"): new
  insn pattern

gcc/testsuite/ChangeLog:

2020-04-21  Stefan Schulze Frielinghaus  

* gcc.target/s390/addsub-signed-overflow-1.c: fix options
* gcc.target/s390/addsub-signed-overflow-2.c: fix options
* gcc.target/s390/bswap-1.c: fix scan assembler regex
* gcc.target/s390/global-array-element-pic2.c: fix scan assembler regex
* gcc.target/s390/load-relative-check.c: fix options
* gcc.target/s390/morestack.c: fix options
* gcc.target/s390/nobp-return-mem-z900.c: temporarily silence this case
* gcc.target/s390/risbg-ll-1.c: fix scan assembler regex
* gcc.target/s390/risbg-ll-2.c: fix scan assembler regex
* gcc.target/s390/risbg-ll-3.c: fix scan assembler regex
* gcc.target/s390/target-attribute/pr82012.c: fix error message
---
 gcc/config/s390/s390.md   | 39 ---
 .../s390/addsub-signed-overflow-1.c   |  2 +-
 .../s390/addsub-signed-overflow-2.c   |  2 +-
 gcc/testsuite/gcc.target/s390/bswap-1.c   |  8 ++--
 .../s390/global-array-element-pic2.c  |  4 +-
 .../gcc.target/s390/load-relative-check.c |  2 +-
 gcc/testsuite/gcc.target/s390/morestack.c |  2 +-
 .../gcc.target/s390/nobp-return-mem-z900.c| 17 ++--
 gcc/testsuite/gcc.target/s390/risbg-ll-1.c| 13 +++
 gcc/testsuite/gcc.target/s390/risbg-ll-2.c|  6 +--
 gcc/testsuite/gcc.target/s390/risbg-ll-3.c|  2 +-
 .../s390/target-attribute/pr82012.c   |  2 +-
 12 files changed, 59 insertions(+), 40 deletions(-)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 44b59659e20..cf53ef1b791 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -3970,22 +3970,21 @@
   [(set_attr "op_type" "RIE")
(set_attr "z10prop" "z10_super_E1")])
 
-; 32 bit: (a & -16) | ((b >> 8) & 15)
-(define_insn "*_ior_and_sr_ze"
-  [(set (match_operand:SI 0 "register_operand" "=d")
-   (ior:SI (and:SI
-(match_operand:SI 1 "register_operand" "0")
-(match_operand:SI 2 "const_int_operand" ""))
-   (subreg:SI
-(zero_extract:DI
- (match_operand:DI 3 "register_operand" "d")
- (match_operand 4 "const_int_operand" "") ; size
+; (a & -16) | ((b >> 8) & 15)
+(define_insn "*_ior_and_sr_ze"
+  [(set (match_operand:DSI 0 "register_operand" "=d")
+   (ior:DSI (and:DSI
+ (match_operand:DSI 1 "register_operand" "0")
+ (match_operand:DSI 2 "const_int_operand" ""))
+(zero_extract:DSI
+ (match_operand:DSI 3 "register_operand" "d")
+ (match_operand 4 "const_int_operand" "")  ; size
  (match_operand 5 "const_int_operand" "")) ; start
-4)))]
+ ))]
   "
-   && EXTRACT_ARGS_IN_RANGE (INTVAL (operands[4]), INTVAL (operands[5]), 64)
+   && EXTRACT_ARGS_IN_RANGE (INTVAL (operands[4]), INTVAL (operands[5]), 
)
&& UINTVAL (operands[2]) == (HOST_WIDE_INT_M1U << UINTVAL (operands[4]))"
-  "\t%0,%3,64-%4,63,%4+%5"
+  "\t%0,%3,64-%4,63,(64-)+%4+%5"
   [(set_attr "op_type" "RIE")
(set_attr "z10prop" "z10_super_E1")])
 
@@ -4237,6 +4236,20 @@
   [(set_attr "op_type" "RIE")
(set_attr "z10prop" "z10_super_E1")])
 
+; (ui32)(((ui64)x) >> 12) & -4
+(define_insn "*trunc_sidi_and_subreg_ze"
+  [(set (match_operand:SI 0 "register_operand" "=d")
+   (and:SI
+(subreg:SI (zero_extract:DI
+(match_operand:DI 1 "register_operand" "d")
+(const_int 32)
+(match_operand:SI 2 "nonzero_shift_count_operand" "")) 4)
+(match_operand:SI 3 "contiguous_bitmask_nowrap_operand" "")))]
+  ""
+  "\t%0,%1,%t3,128+%f3,32+%2"
+  [(set_attr "op_type" "RIE")
+   (set_attr "z10prop" "z10_super_E1")])
+
 ; z = (x << c) | (y >> d) with (x << c) and (y >> d) not overlapping after 
shifting
 ;  -> z = y >> d; z = (x << c) | (z & ((1 << c) - 1))
 ;  -> z = y >> d; z = risbg;
diff --git a/gcc/testsuite/gcc.target/s390/addsub-signed-overflow-1.c 
b/gcc/testsuite/gcc.target/s390/addsub-signed-overflow-1.c
index 143220d5541..ebc02479587 100644
--- a/gcc/testsuite/gcc.target/s390/addsub-signed-overflow-1.c
+++ b/gcc/testsuite/gcc.target/s390/addsub-signed-overflow-1.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-options "-O3 -mzarch --save-temps" } */
+/* { dg-options "-O3 -march=z13 -mzarch --save-temps" } */
 
 #include 
 #include 
diff --git a/gcc/testsuite/gcc.target/s390/addsub-signed-overflow-2.c 
b/gcc/testsuite/gcc.target/s390/addsub-signed-overflow-2.c
index 798e489cece..8bd1a764bc6 100644
--- 

[Patch, committed][Fortran] Truncate warn with OpenMP/OpenACC/!GCC$ (PR94709)

[Tobias Burnus]

Hi all,

when looking into 94690, I was wondering why it didn't accept
'collapse(2)'. Well, it turned out that the line was too long
and the string got clipped.

There is a nice check whether a comment is a real comment or
an OpenACC/OpenMP directive or an !GCC$ attribute – but this
check in gfc_next_char_literal comes too late – as the string
is already truncated and the truncated flag is not set.

The problem is that load_line sets 'seen_comment' and if it
is true, it does not set the truncated flag (used by
gfc_next_char_literal and used in load_line to do 
usage diagostic).

This patch unsets the seen_comment when the first comment is
(case insensitive) '!$' (-fopenmp), '!$acc' (-fopenacc) or '!GCC$'
[or c/* in the first column with fixed-form source code].

!$ is needed for OpenMP's conditional compilation sentinel; there
is some complicated fine print – but as this only affects 
diagnostic, it is not worthwhile to spend efford on it.
[For truncation, there is an extra check in gfc_next_char_literal
which ensures that !$acc is not diagnosed with -fopenmp -fno-openacc.]

OK for the trunk?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
[Fortran] Truncate warn with OpenMP/OpenACC/!GCC$ (PR94709)

While '!$' with -fopenmp unsets too often load_line's seen_comment flag,
this only affects  warnings; for trunction warnings, gfc_next_char_literal 
re-handles the directives correctly.  In terms of missed warnings, a directive
that is completely in the truncated part is not diagnosted (as it starts
with a '!').

	PR fortran/94709
	* scanner.c (load_line): In fixed form, also tread 'C' as comment and
	'D'/'d' only with -fd-lines-as-comments. Treat '!$' with -fopenmp,
	'!$acc' with -fopenacc and '!GCC$' as non-comment to permit 
	and truncation warnings.

	PR fortran/94709
	* gfortran.dg/gomp/warn_truncated.f: New.
	* gfortran.dg/gomp/warn_truncated.f90: New.

 gcc/fortran/scanner.c | 57 ++-
 gcc/testsuite/gfortran.dg/gomp/warn_truncated.f   | 15 ++
 gcc/testsuite/gfortran.dg/gomp/warn_truncated.f90 | 19 
 3 files changed, 80 insertions(+), 11 deletions(-)

diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index f65594f8baa..6f93508f934 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1755,11 +1755,15 @@ static int
 load_line (FILE *input, gfc_char_t **pbuf, int *pbuflen, const int *first_char)
 {
   int c, maxlen, i, preprocessor_flag, buflen = *pbuflen;
-  int trunc_flag = 0, seen_comment = 0;
-  int seen_printable = 0, seen_ampersand = 0, quoted = ' ';
-  gfc_char_t *buffer;
+  int quoted = ' ', comment_ix = -1;
+  bool seen_comment = false;
+  bool first_comment = true;
+  bool trunc_flag = false;
+  bool seen_printable = false;
+  bool seen_ampersand = false;
   bool found_tab = false;
   bool warned_tabs = false;
+  gfc_char_t *buffer;
 
   /* Determine the maximum allowed line length.  */
   if (gfc_current_form == FORM_FREE)
@@ -1794,7 +1798,7 @@ load_line (FILE *input, gfc_char_t **pbuf, int *pbuflen, const int *first_char)
 
   /* In order to not truncate preprocessor lines, we have to
  remember that this is one.  */
-  preprocessor_flag = (c == '#' ? 1 : 0);
+  preprocessor_flag = (c == '#');
 
   for (;;)
 {
@@ -1824,20 +1828,24 @@ load_line (FILE *input, gfc_char_t **pbuf, int *pbuflen, const int *first_char)
 	{
 	  if (seen_ampersand)
 	{
-	  seen_ampersand = 0;
-	  seen_printable = 1;
+	  seen_ampersand = false;
+	  seen_printable = true;
 	}
 	  else
-	seen_ampersand = 1;
+	seen_ampersand = true;
 	}
 
   if ((c != '&' && c != '!' && c != ' ') || (c == '!' && !seen_ampersand))
-	seen_printable = 1;
+	seen_printable = true;
 
   /* Is this a fixed-form comment?  */
   if (gfc_current_form == FORM_FIXED && i == 0
-	  && (c == '*' || c == 'c' || c == 'd'))
-	seen_comment = 1;
+	  && (c == '*' || c == 'c' || c == 'C'
+	  || (gfc_option.flag_d_lines != -1 && (c == 'd' || c == 'D'
+	{
+	  seen_comment = true;
+	  comment_ix = i;
+	}
 
   if (quoted == ' ')
 	{
@@ -1849,7 +1857,34 @@ load_line (FILE *input, gfc_char_t **pbuf, int *pbuflen, const int *first_char)
 
   /* Is this a free-form comment?  */
   if (c == '!' && quoted == ' ')
-seen_comment = 1;
+	{
+	  if (seen_comment)
+	first_comment = false;
+	  seen_comment = true;
+	  comment_ix = i;
+	}
+
+  /* For truncation and tab warnings, set seen_comment to false if one has
+	 either an OpenMP or OpenACC directive - or a !GCC$ attribute.  If
+	 OpenMP is enabled, use '!$' as as conditional compilation sentinel
+	 and OpenMP directive ('!$omp').  */
+  if (seen_comment && first_comment && flag_openmp && comment_ix + 1 == i
+	  && c == '$')
+	first_comment = seen_comment = false;
+  if (seen_comment && first_comment && 

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 22, 2020 at 12:17:02PM +0100, Richard Sandiford wrote:
> But my point was that, if the DECL_NAME does actually act to exclude

I'm fine with dropping DECL_NAME test there, on the other side would like to
add
  && TYPE_SIZE (TREE_TYPE (field))
  && !integer_zerop (TYPE_SIZE (TREE_TYPE (field)))
in there because that is what all these empty bases should satisfy too.

If the predicate says that it is the C++17 empty base field, then it better
should be a narrow check.
Now, in the backend, one has the -Wpsabi diagnostics that also talks about
C++17, so I think it is better to use that predicate in there.
But, what one could do is verify that all other
if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)))
fields don't matter for the ABI decisions.
So
if (TREE_CODE (field) != FIELD_DECL)
  continue;

if (cxx17_empty_base_field_p (field))
  {
/* hint -Wpsabi warning here somehow.  */
continue;
  }
   
sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep);

/* Verify that other zero sized fields don't affect the
   ABI decisions.  */
if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)))
  gcc_assert (sub_count == 0);

if (sub_count < 0)
  return -1;
count += sub_count;
?

Jakub

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Richard Sandiford]

Richard Biener  writes:
> On Wed, 22 Apr 2020, Richard Sandiford wrote:
>
>> Jakub Jelinek  writes:
>> > On Wed, Apr 22, 2020 at 11:45:19AM +0100, Richard Sandiford wrote:
>> >> Given what was said on irc about DECL_NAME not necessarily being
>> >> significant for DECL_ARTIFICIAL decls, would it be better to drop
>> >> this part of the check?
>> >
>> > My preference was have it as narrow as possible for the time being,
>> > because we are shortly before release.
>> > We can replace it with an assertion or whatever later.
>> 
>> But my point was that, if the DECL_NAME does actually act to exclude
>> some type X during a "normal" frontend-to-asm run, that type X might
>> then be treated differently during LTO, because the DECL_NAME might then
>> be null.  (Unless I misunderstood what Richi said on IRC.)  So checking
>> DECL_NAME might then introduce an ABI incompatiblity between non-LTO and
>> LTO code for X.
>> 
>> Is that not right?  Am I just being too paranoid? :-)
>
> The predicate checks !DECL_NAME (field), it's unlikely that LTO
> will invent a DECL_NAME out of nothing.

Yeah, the case I was talking about was if some theoretical type X had
a field with a nonnull DECL_NAME in the frontend, but that name got
cleared during LTO.

> What I was saying is that for DECL_ARTIFICIAL/DECL_IGNORED_P fields
> with DECL_NAME (field) != NULL that LTO might choose to clear
> DECL_NAME (field) because it is clearly not necessary (it currently
> does no such thing).

Ah, OK.  So checking the name is OK now, but we'd have to remember
to come back to this if we ever did clear the DECL_NAME in future,
otherwise it sounds like we could introduce a new ABI incompatibility.

I still think it's less risky not to check at all though...

>> This is the part that I'm most uncomfortable with as far as aarch64
>> is concerned.  I think for aarch64, just:
>> 
>>   if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)))
>> continue;
>> 
>> would be correct from an ABI perspective.
>
> Either we require that only "complete" fields exist and you can
> elide the DECL_SIZE (field) check or we assume that !DECL_SIZE (field)
> fields have zero size.  I think decls never have a NULL DECL_SIZE.

Even better :-)

>> The only reason for not
>> doing that is that it might then "fix" the ABI for other cases besides
>> the one that we're trying to fix.  So the extra "&&"s can be justified
>> in trying to narrow down the scope/impact of the fix given how late
>> we are in the cycle.
>> 
>> (Note: this is just my understanding of the ABI, not a definitive
>> statement.)
>
> We could do
>
>   if (integer_zerop (DECL_SIZE (field)))
> {
>   gcc_assert (cxx17_empty_bae_field_p (field));
>   continue;
> }
>
> so fix it as written in the ABI but assert we've not fixed something
> we don't know.  It'll ICE then and we can reconsider for the found case.

AIUI, DECL_SIZEs are expected to be zero for things like :0 bitfields though.

Thanks,
Richard

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Richard Biener]

On Wed, 22 Apr 2020, Richard Sandiford wrote:

> Jakub Jelinek  writes:
> > On Wed, Apr 22, 2020 at 11:45:19AM +0100, Richard Sandiford wrote:
> >> Given what was said on irc about DECL_NAME not necessarily being
> >> significant for DECL_ARTIFICIAL decls, would it be better to drop
> >> this part of the check?
> >
> > My preference was have it as narrow as possible for the time being,
> > because we are shortly before release.
> > We can replace it with an assertion or whatever later.
> 
> But my point was that, if the DECL_NAME does actually act to exclude
> some type X during a "normal" frontend-to-asm run, that type X might
> then be treated differently during LTO, because the DECL_NAME might then
> be null.  (Unless I misunderstood what Richi said on IRC.)  So checking
> DECL_NAME might then introduce an ABI incompatiblity between non-LTO and
> LTO code for X.
> 
> Is that not right?  Am I just being too paranoid? :-)

The predicate checks !DECL_NAME (field), it's unlikely that LTO
will invent a DECL_NAME out of nothing.  What I was saying is that
for DECL_ARTIFICIAL/DECL_IGNORED_P fields with DECL_NAME (field) != NULL
that LTO might choose to clear DECL_NAME (field) because it is
clearly not necessary (it currently does no such thing).

> This is the part that I'm most uncomfortable with as far as aarch64
> is concerned.  I think for aarch64, just:
> 
>   if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)))
> continue;
> 
> would be correct from an ABI perspective.

Either we require that only "complete" fields exist and you can
elide the DECL_SIZE (field) check or we assume that !DECL_SIZE (field)
fields have zero size.  I think decls never have a NULL DECL_SIZE.

> The only reason for not
> doing that is that it might then "fix" the ABI for other cases besides
> the one that we're trying to fix.  So the extra "&&"s can be justified
> in trying to narrow down the scope/impact of the fix given how late
> we are in the cycle.
> 
> (Note: this is just my understanding of the ABI, not a definitive
> statement.)

We could do

  if (integer_zerop (DECL_SIZE (field)))
{
  gcc_assert (cxx17_empty_bae_field_p (field));
  continue;
}

so fix it as written in the ABI but assert we've not fixed something
we don't know.  It'll ICE then and we can reconsider for the found case.

Richard.

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Richard Sandiford]

Jakub Jelinek  writes:
> On Wed, Apr 22, 2020 at 11:45:19AM +0100, Richard Sandiford wrote:
>> Given what was said on irc about DECL_NAME not necessarily being
>> significant for DECL_ARTIFICIAL decls, would it be better to drop
>> this part of the check?
>
> My preference was have it as narrow as possible for the time being,
> because we are shortly before release.
> We can replace it with an assertion or whatever later.

But my point was that, if the DECL_NAME does actually act to exclude
some type X during a "normal" frontend-to-asm run, that type X might
then be treated differently during LTO, because the DECL_NAME might then
be null.  (Unless I misunderstood what Richi said on IRC.)  So checking
DECL_NAME might then introduce an ABI incompatiblity between non-LTO and
LTO code for X.

Is that not right?  Am I just being too paranoid? :-)

This is the part that I'm most uncomfortable with as far as aarch64
is concerned.  I think for aarch64, just:

  if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field)))
continue;

would be correct from an ABI perspective.  The only reason for not
doing that is that it might then "fix" the ABI for other cases besides
the one that we're trying to fix.  So the extra "&&"s can be justified
in trying to narrow down the scope/impact of the fix given how late
we are in the cycle.

(Note: this is just my understanding of the ABI, not a definitive
statement.)

But as far as the aarch64 ABI is concerned, it's hard to find a good
justification for checking the DECL_NAME .  Adding that particular "&&"
feels more dangerous than safe.

Thanks,
Richard

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 22, 2020 at 12:58:52PM +0200, Richard Biener wrote:
> On Wed, 22 Apr 2020, Jakub Jelinek wrote:
> 
> > On Wed, Apr 22, 2020 at 11:45:19AM +0100, Richard Sandiford wrote:
> > > Given what was said on irc about DECL_NAME not necessarily being
> > > significant for DECL_ARTIFICIAL decls, would it be better to drop
> > > this part of the check?
> > 
> > My preference was have it as narrow as possible for the time being,
> > because we are shortly before release.
> > We can replace it with an assertion or whatever later.
> > Perhaps even the predicate should check for non-NULL and non-zero
> > TYPE_SIZE (TREE_TYPE (field)).
> 
> Btw, do we ever have more than one of those?  The predicate doesn't

I think there can be at most one in each TYPE_FIELDS chain, but fields
of that can have it in their TYPE_FIELDS of their TREE_TYPEs too of course.

> check if the field is the "first" one (does it reliably appear
> before non-FIELD_DECLs and thus is it always == TYPE_FIELDS (DECL_CONTEXT 
> (field))?)

I don't think anything guarantees that, in C++ I think usually the methods
appear first and there can be all kinds of other things in the chain (e.g.
using declarations etc.).

Jakub