[committed] MAINTAINERS: add myself for write after approval

[Stefan Schulze Frielinghaus via Gcc-patches]

ChangeLog:

2020-04-22  Stefan Schulze Frielinghaus  

* MAINTAINERS (Write After Approval): add myself

---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f37e9e68622..336346a37a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -582,6 +582,7 @@ Trevor Saunders 

 Aaron Sawdey   
 Roger Sayle
 Will Schmidt   
+Stefan Schulze Frielinghaus
 Tilo Schwarz   
 Martin Sebor   
 Svein Seldal   
-- 
2.25.3

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

[Bernhard Reutner-Fischer via Gcc-patches]

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 ¹).
But one should use the recommended replacement functions either way,
e.g. mkstemp ²)

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.
²)
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 0/19][GCC-8] aarch64: Backport outline atomics

[Andre Vieira (lists)]

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.

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)

[PATCH] forwprop: Fix ICE when building an identity constructor [PR94700]

[Richard Sandiford]

This is really PR94683 part 2, handling the case in which the vector is
an identity and so doesn't need a VEC_PERM_EXPR.  I should have realised
at the time that the other arm of the "if" would need the same fix.

Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
OK to install?

Richard


2020-04-22  Richard Sandiford  

gcc/
PR tree-optimization/94700
* tree-ssa-forwprop.c (simplify_vector_constructor): When processing
an identity constructor, use a VIEW_CONVERT_EXPR to handle mixtures
of similarly-structured but distinct vector types.

gcc/testsuite/
PR tree-optimization/94700
* gcc.target/aarch64/sve/acle/general/pr94700.c: New test.
---
 .../aarch64/sve/acle/general/pr94700.c| 28 +++
 gcc/tree-ssa-forwprop.c   | 13 -
 2 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c

diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
index 1a50045b367..8ee5450b94c 100644
--- a/gcc/tree-ssa-forwprop.c
+++ b/gcc/tree-ssa-forwprop.c
@@ -2475,7 +2475,18 @@ simplify_vector_constructor (gimple_stmt_iterator *gsi)
  orig[0] = gimple_assign_lhs (lowpart);
}
   if (conv_code == ERROR_MARK)
-   gimple_assign_set_rhs_from_tree (gsi, orig[0]);
+   {
+ tree src_type = TREE_TYPE (orig[0]);
+ if (!useless_type_conversion_p (type, src_type))
+   {
+ gcc_assert (!targetm.compatible_vector_types_p (type, src_type));
+ tree rhs = build1 (VIEW_CONVERT_EXPR, type, orig[0]);
+ orig[0] = make_ssa_name (type);
+ gassign *assign = gimple_build_assign (orig[0], rhs);
+ gsi_insert_before (gsi, assign, GSI_SAME_STMT);
+   }
+ gimple_assign_set_rhs_from_tree (gsi, orig[0]);
+   }
   else
gimple_assign_set_rhs_with_ops (gsi, conv_code, orig[0],
NULL_TREE, NULL_TREE);
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c
new file mode 100644
index 000..1feac60d8e9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c
@@ -0,0 +1,28 @@
+/* { dg-options "-O2 -msve-vector-bits=256" } */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+#include 
+
+typedef float v8sf __attribute__((vector_size(32)));
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*
+** test:
+** faddz0\.s, p0/m, z0\.s, #1.0
+** fdivz0\.s, p0/m, z0\.s, z1\.s
+** ret
+*/
+svfloat32_t
+test (svbool_t pg, svfloat32_t x, svfloat32_t y)
+{
+  v8sf a = svadd_x (pg, x, 1);
+  v8sf b = { a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7] };
+  return svdiv_x (pg, b, y);
+}
+
+#ifdef __cplusplus
+}
+#endif

Re: [PATCH v2] aarch64: Add TX3 machine model

[Ramana Radhakrishnan via Gcc-patches]

On Wed, Apr 22, 2020 at 5:38 AM Joel Jones via Gcc-patches
 wrote:
>
> I just joined the gcc-patches list, so I hope the mail software can parse 
> this out with an "In-Reply-To" header.
>
> I work for Marvell, and Anton's work is approved for submittal. I wrote the 
> first version of the .md file. I'm certain we have a copyright assignment.in 
> place, as we've had employees in the past six months submit changes, for 
> example Steve Ellcey.
>
I can certainly see Marvell hold a copyright assignment from 2010 in
the copyright.list file.

For being clear, is that stating that Anton's work is also covered by
that copyright assignment ?

Ramana

> Joel Jones
>
> >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 PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

[Yangfei (Felix)]

> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, April 21, 2020 6:11 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-
> regs-only and sve
> > Should aarch64_sve::init_builtins ()/aarch64_sve::handle_arm_sve_h () be
> guarded by TARGET_SVE?
> >
> > Could you please confirm that?
> 
> Yeah, that's right.  As Jakub says, the SVE stuff is (deliberately) registered
> unconditionally because it's possible to switch SVE on and off later.  Also,
> protecting it with just TARGET_SVE would mean that we'd continue to
> register SVE2 functions even if SVE2 isn't currently enabled.

Well, I was thinking maybe we can call aarch64_sve::init_builtins () in 
aarch64_pragma_target_parse when SVE is switched on.
But I think I will leave this alone.

> So what matters is whether SVE is enabled at the point of use, not the point
> of the #include.  FWIW, arm_neon.h works the same way: the same
> functions are defined regardless of what the current prevailing architecture 
> is,
> and what matters is whether the necessary features are enabled when the
> functions are called.  (Inlining fails if they're not.) But because we're
> implementing arm_sve.h directly in the compiler, we don't need the
> overhead of a full target switch when defining the functions.
>
> And like you say, the second of the above tests makes sure that turning SVE
> on later does indeed work, while the first makes sure that we get an
> appropriate error if SVE is disabled at the point of use.

Thanks for the details, it helps :-)
I have modified accordingly and attached please find the adapted v2 patch.
Bootstrap and tested on aarch64 Linux platform.  Does it look better?

Note that we need to disable TARGET_GENERAL_REGS_ONLY before 
register_builtin_types.
Otherwise we got ICEs like:
: internal compiler error: in register_builtin_types, at 
config/aarch64/aarch64-sve-builtins.cc:3336
0x185bcfb register_builtin_types
../../gcc-git/gcc/config/aarch64/aarch64-sve-builtins.cc:3332
0x185c467 aarch64_sve::init_builtins()
../../gcc-git/gcc/config/aarch64/aarch64-sve-builtins.cc:3375
0x17c075b aarch64_init_builtins
../../gcc-git/gcc/config/aarch64/aarch64.c:13086

, where TYPE_MODE (vectype) is BLKmode.

The reason is targetm.vector_mode_supported_p (mode) and 
have_regs_of_mode[mode] are false when TARGET_GENERAL_REGS_ONLY is enabled.
(gdb) bt
#0  vector_type_mode (t=0xb7aa2f18) at ../../gcc-git/gcc/tree.c:13825
#1  0x01297ee0 in layout_type (type=0xb7aa2f18) at 
../../gcc-git/gcc/stor-layout.c:2400
#2  0x016e19d8 in make_vector_type (innertype=0xb7aa2a80, 
nunits=..., mode=E_VNx16BImode) at ../../gcc-git/gcc/tree.c:9984
#3  0x016e79b4 in build_truth_vector_type_for_mode (nunits=..., 
mask_mode=E_VNx16BImode) at ../../gcc-git/gcc/tree.c:10929
#4  0x0185bb00 in aarch64_sve::register_builtin_types () at 
../../gcc-git/gcc/config/aarch64/aarch64-sve-builtins.cc:3331
#5  0x0185c468 in aarch64_sve::init_builtins () at 
../../gcc-git/gcc/config/aarch64/aarch64-sve-builtins.cc:3375
#6  0x017c075c in aarch64_init_builtins () at 
../../gcc-git/gcc/config/aarch64/aarch64.c:13086
#7  0x00a69cb4 in c_define_builtins 
(va_list_ref_type_node=0xb79ea540, va_list_arg_type_node=0xb79e79d8)
at ../../gcc-git/gcc/c-family/c-common.c:3973

Felix


pr94678-v2.patch
Description: pr94678-v2.patch

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

[Richard Sandiford]

Richard Biener via Gcc-patches  writes:
> On Mon, Apr 20, 2020 at 3:38 PM Segher Boessenkool
>  wrote:
>>
>> Hi!
>>
>> 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?

Testing that -fweb would have no effect is expensive, since it requires
full UD chains.  And there's a risk that optimisations could break the
condition accidentally.  E.g.:

   if (cond)
 {
   x = ...;
   ...use x...;
 }
   else
 {
   x = ...;
   ...use x...;
 }
   ...use x...; // A, REG_DEAD x

If anything managed to fold away the need for x in A (e.g. combine),
it would then be required to rename x in one of the if/else blocks.

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

Thanks,
Richard

[committed] coroutines, testsuite: Tidy some test names (NFC).

[Iain Sandoe]

Hi

Try to make sure that we have consistent and useful naming for the tests
before they get into the wild.

tested on x86_64-darwin16,
applied to master
thanks
Iain

gcc/testsuite/ChangeLog:

2020-04-22 Iain Sandoe 

* g++.dg/coroutines/torture/local-var-0.C: Rename to...
* g++.dg/coroutines/torture/local-var-00-const.C: ...this.
* g++.dg/coroutines/torture/local-var-1.C: Rename to...
* g++.dg/coroutines/torture/local-var-01-single.C: ...this.
* g++.dg/coroutines/torture/local-var-2.C: Rename to...
* g++.dg/coroutines/torture/local-var-02-conditional.C: ...this.
* g++.dg/coroutines/torture/local-var-3.C: Rename to...
* g++.dg/coroutines/torture/local-var-03-with-awaits.C: ...this.
* g++.dg/coroutines/torture/local-var-4.C: Rename to...
* g++.dg/coroutines/torture/local-var-04-hiding-nested-scopes.C: this.
* g++.dg/coroutines/torture/local-var-5-awaitable.C: Rename to...
* g++.dg/coroutines/torture/local-var-05-awaitable.C: ...this.
---
 .../coroutines/torture/{local-var-0.C => local-var-00-const.C}| 0
 .../coroutines/torture/{local-var-1.C => local-var-01-single.C}   | 0
 .../torture/{local-var-2.C => local-var-02-conditional.C} | 0
 .../torture/{local-var-3.C => local-var-03-with-awaits.C} | 0
 .../{local-var-4.C => local-var-04-hiding-nested-scopes.C}| 0
 .../torture/{local-var-5-awaitable.C => local-var-05-awaitable.C} | 0
 6 files changed, 0 insertions(+), 0 deletions(-)
 rename gcc/testsuite/g++.dg/coroutines/torture/{local-var-0.C => 
local-var-00-const.C} (100%)
 rename gcc/testsuite/g++.dg/coroutines/torture/{local-var-1.C => 
local-var-01-single.C} (100%)
 rename gcc/testsuite/g++.dg/coroutines/torture/{local-var-2.C => 
local-var-02-conditional.C} (100%)
 rename gcc/testsuite/g++.dg/coroutines/torture/{local-var-3.C => 
local-var-03-with-awaits.C} (100%)
 rename gcc/testsuite/g++.dg/coroutines/torture/{local-var-4.C => 
local-var-04-hiding-nested-scopes.C} (100%)
 rename gcc/testsuite/g++.dg/coroutines/torture/{local-var-5-awaitable.C => 
local-var-05-awaitable.C} (100%)

diff --git a/gcc/testsuite/g++.dg/coroutines/torture/local-var-0.C 
b/gcc/testsuite/g++.dg/coroutines/torture/local-var-00-const.C
similarity index 100%
rename from gcc/testsuite/g++.dg/coroutines/torture/local-var-0.C
rename to gcc/testsuite/g++.dg/coroutines/torture/local-var-00-const.C
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/local-var-1.C 
b/gcc/testsuite/g++.dg/coroutines/torture/local-var-01-single.C
similarity index 100%
rename from gcc/testsuite/g++.dg/coroutines/torture/local-var-1.C
rename to gcc/testsuite/g++.dg/coroutines/torture/local-var-01-single.C
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/local-var-2.C 
b/gcc/testsuite/g++.dg/coroutines/torture/local-var-02-conditional.C
similarity index 100%
rename from gcc/testsuite/g++.dg/coroutines/torture/local-var-2.C
rename to gcc/testsuite/g++.dg/coroutines/torture/local-var-02-conditional.C
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/local-var-3.C 
b/gcc/testsuite/g++.dg/coroutines/torture/local-var-03-with-awaits.C
similarity index 100%
rename from gcc/testsuite/g++.dg/coroutines/torture/local-var-3.C
rename to gcc/testsuite/g++.dg/coroutines/torture/local-var-03-with-awaits.C
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/local-var-4.C 
b/gcc/testsuite/g++.dg/coroutines/torture/local-var-04-hiding-nested-scopes.C
similarity index 100%
rename from gcc/testsuite/g++.dg/coroutines/torture/local-var-4.C
rename to 
gcc/testsuite/g++.dg/coroutines/torture/local-var-04-hiding-nested-scopes.C
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/local-var-5-awaitable.C 
b/gcc/testsuite/g++.dg/coroutines/torture/local-var-05-awaitable.C
similarity index 100%
rename from gcc/testsuite/g++.dg/coroutines/torture/local-var-5-awaitable.C
rename to gcc/testsuite/g++.dg/coroutines/torture/local-var-05-awaitable.C
-- 
2.24.1

[PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

[Jakub Jelinek via Gcc-patches]

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.

--- 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,22 @@ 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)
+ && DECL_NAME (field) == NULL_TREE
+ && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
+ && DECL_SIZE (field)
+ && integer_zerop (DECL_SIZE (field)));
+}
+
 /* Tell the garbage collector about GTY markers in this source file.  */
 #include "gt-calls.h"


Jakub

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

[Richard Biener]

On Wed, 22 Apr 2020, Jakub Jelinek 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)?

OK.

Richard.

> 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.jj2020-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.jj2020-03-27 22:27:09.615964438 +0100
> +++ gcc/calls.c   2020-04-22 11:44:17.621722376 +0200
> @@ -6261,5 +6261,22 @@ 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)
> +   && DECL_NAME (field) == NULL_TREE
> +   && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
> +   && DECL_SIZE (field)
> +   && integer_zerop (DECL_SIZE (field)));
> +}
> +
>  /* Tell the garbage collector about GTY markers in this source file.  */
>  #include "gt-calls.h"
> 
> 
>   Jakub
> 
> 

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

Re: [PATCH] forwprop: Fix ICE when building an identity constructor [PR94700]

[Richard Biener via Gcc-patches]

On Wed, Apr 22, 2020 at 10:31 AM Richard Sandiford
 wrote:
>
> This is really PR94683 part 2, handling the case in which the vector is
> an identity and so doesn't need a VEC_PERM_EXPR.  I should have realised
> at the time that the other arm of the "if" would need the same fix.
>
> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
> OK to install?

OK.

Richard.

> Richard
>
>
> 2020-04-22  Richard Sandiford  
>
> gcc/
> PR tree-optimization/94700
> * tree-ssa-forwprop.c (simplify_vector_constructor): When processing
> an identity constructor, use a VIEW_CONVERT_EXPR to handle mixtures
> of similarly-structured but distinct vector types.
>
> gcc/testsuite/
> PR tree-optimization/94700
> * gcc.target/aarch64/sve/acle/general/pr94700.c: New test.
> ---
>  .../aarch64/sve/acle/general/pr94700.c| 28 +++
>  gcc/tree-ssa-forwprop.c   | 13 -
>  2 files changed, 40 insertions(+), 1 deletion(-)
>  create mode 100644 
> gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c
>
> diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
> index 1a50045b367..8ee5450b94c 100644
> --- a/gcc/tree-ssa-forwprop.c
> +++ b/gcc/tree-ssa-forwprop.c
> @@ -2475,7 +2475,18 @@ simplify_vector_constructor (gimple_stmt_iterator *gsi)
>   orig[0] = gimple_assign_lhs (lowpart);
> }
>if (conv_code == ERROR_MARK)
> -   gimple_assign_set_rhs_from_tree (gsi, orig[0]);
> +   {
> + tree src_type = TREE_TYPE (orig[0]);
> + if (!useless_type_conversion_p (type, src_type))
> +   {
> + gcc_assert (!targetm.compatible_vector_types_p (type, 
> src_type));
> + tree rhs = build1 (VIEW_CONVERT_EXPR, type, orig[0]);
> + orig[0] = make_ssa_name (type);
> + gassign *assign = gimple_build_assign (orig[0], rhs);
> + gsi_insert_before (gsi, assign, GSI_SAME_STMT);
> +   }
> + gimple_assign_set_rhs_from_tree (gsi, orig[0]);
> +   }
>else
> gimple_assign_set_rhs_with_ops (gsi, conv_code, orig[0],
> NULL_TREE, NULL_TREE);
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c 
> b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c
> new file mode 100644
> index 000..1feac60d8e9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c
> @@ -0,0 +1,28 @@
> +/* { dg-options "-O2 -msve-vector-bits=256" } */
> +/* { dg-final { check-function-bodies "**" "" } } */
> +
> +#include 
> +
> +typedef float v8sf __attribute__((vector_size(32)));
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/*
> +** test:
> +** faddz0\.s, p0/m, z0\.s, #1.0
> +** fdivz0\.s, p0/m, z0\.s, z1\.s
> +** ret
> +*/
> +svfloat32_t
> +test (svbool_t pg, svfloat32_t x, svfloat32_t y)
> +{
> +  v8sf a = svadd_x (pg, x, 1);
> +  v8sf b = { a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7] };
> +  return svdiv_x (pg, b, y);
> +}
> +
> +#ifdef __cplusplus
> +}
> +#endif

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

[Richard Biener via Gcc-patches]

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:
> >>
> >> Hi!
> >>
> >> 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.

> Testing that -fweb would have no effect is expensive, since it requires
> full UD chains.  And there's a risk that optimisations could break the
> condition accidentally.  E.g.:
>
>if (cond)
>  {
>x = ...;
>...use x...;
>  }
>else
>  {
>x = ...;
>...use x...;
>  }
>...use x...; // A, REG_DEAD x
>
> If anything managed to fold away the need for x in A (e.g. combine),
> it would then be required to rename x in one of the if/else blocks.
>
> In some ways it feels like it would be easier to resurrect RTL SSA :-)
>
> Thanks,
> Richard

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

[Kyrylo Tkachov]

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)
> >

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

[Richard Sandiford]

Mostly LGTM, just a couple of minor points:

"Yangfei (Felix)"  writes:
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 6e226cc..e956b69 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,23 @@
> +2020-04-22  Felix Yang  
> +
> + PR target/94678
> + * config/aarch64/aarch64.h (TARGET_SVE, TARGET_SVE2):
> + Add && !TARGET_GENERAL_REGS_ONLY.
> + (TARGET_SVE2_AES, TARGET_SVE2_BITPERM, TARGET_SVE2_SHA3,
> + TARGET_SVE2_SM4): Add && TARGET_SVE2.

I agree using "TARGET_SVE2 &&" is just as good as adding
"!TARGET_GENERAL_REGS_ONLY &&", and arguably better.  But I think
it would then be more consistent to add "TARGET_SVE &&" rather than
"!TARGET_GENERAL_REGS_ONLY &&" to TARGET_SVE2.

> @@ -558,6 +558,10 @@ static hash_table 
> *function_table;
> when the required extension is disabled.  */
>  static bool reported_missing_extension_p;
>  
> +/* True if we've already complained about attempts to use functions
> +   which require registers that is missing.  */

s/is/are/

> +static bool reported_missing_registers_p;
> +
>  /* Record that TYPE is an ABI-defined SVE type that contains NUM_ZR SVE 
> vectors
> and NUM_PR SVE predicates.  MANGLED_NAME, if nonnull, is the ABI-defined
> mangling of the type.  */
> @@ -657,6 +661,28 @@ report_missing_extension (location_t location, tree 
> fndecl,
>reported_missing_extension_p = true;
>  }
>  
> +/* Check whether the registers required by SVE function fndecl are available.
> +   SVE registers are not usable when -mgeneral-regs-only option is specified.
> +   Report an error against LOCATION and return false if not.  */

The "Report an error ..." sentence really forms a unit with the
"Check ..." sentence.  I think it would probably be better to move
the intervening "SVE registers are not usable..." comment...

> +static bool
> +check_required_registers (location_t location, tree fndecl)
> +{
> +  /* Avoid reporting a slew of messages for a single oversight.  */
> +  if (reported_missing_registers_p)
> +return false;
> +
> +  if (TARGET_GENERAL_REGS_ONLY)

...here.

> +{
> +  error_at (location,
> + "ACLE function %qD is incompatible with the use of %qs",
> + fndecl, "-mgeneral-regs-only");
> +  reported_missing_registers_p = true;
> +  return false;
> +}
> +
> +  return true;
> +}
> +
>  /* Check whether all the AARCH64_FL_* values in REQUIRED_EXTENSIONS are
> enabled, given that those extensions are required for function FNDECL.
> Report an error against LOCATION if not.  */
> [...]
> diff --git a/gcc/config/aarch64/aarch64-sve-builtins.h 
> b/gcc/config/aarch64/aarch64-sve-builtins.h
> index f7f06d2..5fdccb1 100644
> --- a/gcc/config/aarch64/aarch64-sve-builtins.h
> +++ b/gcc/config/aarch64/aarch64-sve-builtins.h
> @@ -658,6 +658,7 @@ public:
>  
>  private:
>unsigned long m_old_isa_flags;
> +  bool old_general_regs_only;

The convention (not always followed!) is to use an "m_" prefix for
private member variables for classes.
[https://gcc.gnu.org/codingconventions.html#Cxx_Names]

So please add an "m_" prefix here for consistency with the other two
member variables.

Thanks,
Richard

>bool m_old_have_regs_of_mode[MAX_MACHINE_MODE];
>  };
>  
> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
> index 8f08bad..3aa3e25 100644
> --- a/gcc/config/aarch64/aarch64.h
> +++ b/gcc/config/aarch64/aarch64.h
> @@ -309,22 +309,22 @@ extern unsigned aarch64_architecture_version;
>  #define TARGET_DOTPROD (TARGET_SIMD && AARCH64_ISA_DOTPROD)
>  
>  /* SVE instructions, enabled through +sve.  */
> -#define TARGET_SVE (AARCH64_ISA_SVE)
> +#define TARGET_SVE (!TARGET_GENERAL_REGS_ONLY && AARCH64_ISA_SVE)
>  
>  /* SVE2 instructions, enabled through +sve2.  */
> -#define TARGET_SVE2 (AARCH64_ISA_SVE2)
> +#define TARGET_SVE2 (!TARGET_GENERAL_REGS_ONLY && AARCH64_ISA_SVE2)
>  
>  /* SVE2 AES instructions, enabled through +sve2-aes.  */
> -#define TARGET_SVE2_AES (AARCH64_ISA_SVE2_AES)
> +#define TARGET_SVE2_AES (TARGET_SVE2 && AARCH64_ISA_SVE2_AES)
>  
>  /* SVE2 BITPERM instructions, enabled through +sve2-bitperm.  */
> -#define TARGET_SVE2_BITPERM (AARCH64_ISA_SVE2_BITPERM)
> +#define TARGET_SVE2_BITPERM (TARGET_SVE2 && AARCH64_ISA_SVE2_BITPERM)
>  
>  /* SVE2 SHA3 instructions, enabled through +sve2-sha3.  */
> -#define TARGET_SVE2_SHA3 (AARCH64_ISA_SVE2_SHA3)
> +#define TARGET_SVE2_SHA3 (TARGET_SVE2 && AARCH64_ISA_SVE2_SHA3)
>  
>  /* SVE2 SM4 instructions, enabled through +sve2-sm4.  */
> -#define TARGET_SVE2_SM4 (AARCH64_ISA_SVE2_SM4)
> +#define TARGET_SVE2_SM4 (TARGET_SVE2 && AARCH64_ISA_SVE2_SM4)
>  
>  /* ARMv8.3-A features.  */
>  #define TARGET_ARMV8_3   (AARCH64_ISA_V8_3)
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index be374fb..b8ed79c 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2020-04-22  Felix Yang  
> +
> + PR target/94678
> + * gcc.target/aarch64/sve/acle/

[PATCH] S/390: Fix several test cases

[Stefan Schulze Frielinghaus via Gcc-patches]

Hi,

The attached patch fixes several test cases. Successfully bootstrapped and
regtested on S/390. 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..d43acba91d3 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" } */
 
 #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..0c3df5c4b3a 100644
--- a/gcc/testsuite/gcc.target/s39

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

[Richard Sandiford]

Jakub Jelinek  writes:
> 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.
>
> --- gcc/calls.h.jj2020-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.jj2020-03-27 22:27:09.615964438 +0100
> +++ gcc/calls.c   2020-04-22 11:44:17.621722376 +0200
> @@ -6261,5 +6261,22 @@ 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)
> +   && DECL_NAME (field) == NULL_TREE

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?

Thanks,
Richard

> +   && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
> +   && DECL_SIZE (field)
> +   && integer_zerop (DECL_SIZE (field)));
> +}
> +
>  /* Tell the garbage collector about GTY markers in this source file.  */
>  #include "gt-calls.h"
>
>
>   Jakub

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

[Jakub Jelinek via Gcc-patches]

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

Jakub

[PATCH][RFC] extend DECL_GIMPLE_REG_P to all types

[Richard Biener]

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.

Thanks,
Richard.

2020-04-22  Richard Biener  

PR middle-end/94703
* tree-core.h (tree_decl_common::gimple_reg_flag): Rename ...
(tree_decl_common::not_gimple_reg_flag): ... to this.
* tree.h (DECL_GIMPLE_REG_P): Rename ...
(DECL_NOT_GIMPLE_REG_P): ... to this.
* gimple-expr.c (copy_var_decl): Copy DECL_NOT_GIMPLE_REG_P.
(create_tmp_reg): Simplify.
(create_tmp_reg_fn): Likewise.
(is_gimple_reg): Check DECL_NOT_GIMPLE_REG_P for all regs.
* gimplify.c (create_tmp_from_val): Simplify.
(gimplify_bind_expr): Likewise.
(gimplify_compound_literal_expr): Likewise.
(gimplify_function_tree): Likewise.
(prepare_gimple_addressable): Set DECL_NOT_GIMPLE_REG_P.
* asan.c (create_odr_indicator): Do not clear DECL_GIMPLE_REG_P.
(asan_add_global): Copy it.
* cgraphunit.c (cgraph_node::expand_thunk): Force args
to be GIMPLE regs.
* function.c (gimplify_parameters): Copy
DECL_NOT_GIMPLE_REG_P.
* ipa-param-manipulation.c
(ipa_param_body_adjustments::common_initialization): Simplify.
(ipa_param_body_adjustments::reset_debug_stmts): Copy
DECL_NOT_GIMPLE_REG_P.
* omp-low.c (lower_omp_for_scan): Do not set DECL_GIMPLE_REG_P.
* sanopt.c (sanitize_rewrite_addressable_params): Likewise.
* tree-cfg.c (make_blocks_1): Simplify.
(verify_address): Do not verify DECL_GIMPLE_REG_P setting.
* tree-eh.c (lower_eh_constructs_2): Simplify.
* tree-inline.c (declare_return_variable): Adjust and
generalize.
(copy_decl_to_var): Copy DECL_NOT_GIMPLE_REG_P.
(copy_result_decl_to_var): Likewise.
* tree-into-ssa.c (pass_build_ssa::execute): Adjust comment.
* tree-nested.c (create_tmp_var_for): Simplify.
* tree-parloops.c (separate_decls_in_region_name): Copy
DECL_NOT_GIMPLE_REG_P.
* tree-sra.c (create_access_replacement): Adjust and
generalize partial def support.
* tree-ssa-forwprop.c (pass_forwprop::execute): Set
DECL_NOT_GIMPLE_REG_P on decls we introduce partial defs on.
* tree-ssa.c (maybe_optimize_var): Handle clearing of
TREE_ADDRESSABLE and setting/clearing DECL_NOT_GIMPLE_REG_P
independently.
* lto-streamer-out.c (hash_tree): Hash DECL_NOT_GIMPLE_REG_P.
* tree-streamer-out.c (pack_ts_decl_common_value_fields): Stream
DECL_NOT_GIMPLE_REG_P.
* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Likewise.

lto/
* lto-common.c (compare_tree_sccs_1): Compare
DECL_NOT_GIMPLE_REG_P.

c/
* gimple-parser.c (c_parser_parse_ssa_name): Do not set
DECL_GIMPLE_REG_P.

cp/
* optimize.c (update_cloned_parm): Copy DECL_NOT_GIMPLE_REG_P.

* gcc.dg/tree-ssa/pr94703.c: New testcase.
---
 gcc/asan.c  |  3 +-
 gcc/c/gimple-parser.c   |  3 --
 gcc/cgraphunit.c|  5 +--
 gcc/cp/optimize.c   |  2 +-
 gcc/function.c  |  5 +--
 gcc/gimple-expr.c   | 24 +++-
 gcc/gimplify.c  | 46 +--
 gcc/ipa-param-manipulation.c|  6 +--
 gcc/lto-streamer-out.c  |  2 +-
 gcc/lto/lto-common.c|  2 +-
 gcc/omp-low.c   |  1 -
 gcc/sanopt.c|  1 -
 gcc/testsuite/gcc.dg/tree-ssa/pr94703.c | 11 ++
 gcc/tree-cfg.c  |  9 -
 gcc/tree-core.h |  2 +-
 gcc/tree-eh.c   |  3 --
 gcc/tree-inline.c   | 23 
 gcc/tree-into-ssa.c |  3 +-
 gcc/tree-nested.c   |  3 --
 gcc/tree-parloops.c |  2 +-
 gcc/tree-sra.c  | 12 ++
 gcc/tree-ssa-forwprop.c |  6 ++-
 gcc/tree-ssa.c  | 66 +
 gcc/tree-st

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

[Richard Biener]

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
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))?)

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

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]

[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]

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]

[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

[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 && comment

[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
--- a/gcc/testsuite/gcc.target/s390/addsub-sig

[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&R 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 (&id, old_tree, replace_info->new_tree,
-   id.src_fn, NULL, &vars);
-   if (init)
- init_stmts.safe_push (init);
- }
+   gcc_assert (parm);
+   init = setup_one_parameter (&id, parm, replace_info->new_tree,
+   id.src_fn, NULL, &vars);
+   if (init)
+ init_stmts.safe_push (init);
   }
 
   ipa_param_body_adjustments *param_body_adjs = NULL;
-- 
2.26.0

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

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

[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] 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&R 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 (&id, old_tree, replace_info->new_tree,
> - id.src_fn, NULL, &vars);
> - if (init)
> -   init_stmts.safe_push (init);
> -   }
> + gcc_assert (parm);
> + init = setup_one_parameter (&id, parm, replace_info->new_tree,
> + id.src_fn, NULL, &vars);
> + 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)

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

[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]

[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

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

[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.
* gcc.target/arm/mve/intrin

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

[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, &field_mode);
+  bool cxx17_empty_base_seen = false;
+  int field_count = rs6000_aggregate_candidate (type, &field_mode,
+   &cxx17_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_repo

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 opt

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 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
> > ind

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 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] 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

[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] 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.
> > > >> >> >
> > > >> >> > 

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})&d] = MEM  
[(char * {ref-all})"AAA"];
  MEM  [(char * {ref-all})&s] = MEM  
[(char * {ref-all})&d];
  _1 = __builtin_strcmp (&s, "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] 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

[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
+# def

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

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: 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] 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
> 

[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 @@ exte

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

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)
> > >

[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] 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

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][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})&d] = MEM  
> [(char * {ref-all})"AAA"];
>   MEM  [(char * {ref-all})&s] = MEM  
> [(char * {ref-all})&d];
>   _1 = __builtin_strcmp (&s, "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 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 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] 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, &field_mode);
+  bool cxx17_empty_base_seen = false;
+  int field_count = rs6000_aggregate_candidate (type, &field_mode,
+   &cxx17_empty_

[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), &c0))
+	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), &c0i)
+	  || 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]

[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

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: [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] 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
> 

[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). */
+#define

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
> 

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] 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: [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  and
+.
+  
+  
+Constrained algorithms in ,
+, and
+ (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 
+and throughout the library.
+  
  
Constexpr support in  and elsewhere
(thanks to Edward Smith-Rowland).
@@ -396,16 +413,11 @@ a work-in-progress.
std::atomic_ref and
std::atomic.
  
-   std::ssize, std::to_array. 
  
-Library concepts in  and
-.
+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::atomic.
   
   
-Integral comparison functions
+Integer comparison functions
 (cmp_equal, cmp_less etc.).
   
std::ssize, std::to_array. 

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: 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] 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: [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] 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 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] 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] 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: 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

[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: [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

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
> 

[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);
 
-/* B

[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)
 {
-  _GLIBCXX_BEGIN_NAMESPACE

[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

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{};
+}

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

[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++: 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

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++: 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: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] 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.

[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: [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] 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