[PATCH][pushed] ada: bump Library_Version to 13.

[Martin Liška]

Pushed as obvious.

Martin

gcc/ada/ChangeLog:

* gnatvsn.ads: Bump Library_Version to 13.
---
 gcc/ada/gnatvsn.ads | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/gnatvsn.ads b/gcc/ada/gnatvsn.ads
index 47a06b96c3c..311a103b2a8 100644
--- a/gcc/ada/gnatvsn.ads
+++ b/gcc/ada/gnatvsn.ads
@@ -32,7 +32,7 @@ package Gnatvsn is
--  Static string identifying this version, that can be used as an argument
--  to e.g. pragma Ident.
 
-   Library_Version : constant String := "12";
+   Library_Version : constant String := "13";
--  Library version. It needs to be updated whenever the major version
--  number is changed.
--
-- 
2.36.0

[pushed] c++: traits, array of unknown bound of incomplete

[Jason Merrill via Gcc-patches]

My r161129 changed check_trait_type to reject arrays of unknown bound of
incomplete type, but I can't find a rationale for that, and now think it's
wrong: the standard just requires that the type be "complete, cv void, or an
array of unknown bound."  I imagine that allowing arrays of unknown bound is
because an array of unknown bound can't change from incomplete to complete
later in the translation unit, so there's no caching problem.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

* semantics.cc (check_trait_type): Don't check completeness
of element type of array of unknown bound.

gcc/testsuite/ChangeLog:

* g++.dg/ext/unary_trait_incomplete.C: Adjust.
---
 gcc/cp/semantics.cc   |  3 +--
 .../g++.dg/ext/unary_trait_incomplete.C   | 24 +--
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 9567559c962..377f61113c0 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -11978,8 +11978,7 @@ check_trait_type (tree type)
 return (check_trait_type (TREE_VALUE (type))
&& check_trait_type (TREE_CHAIN (type)));
 
-  if (TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type)
-  && COMPLETE_TYPE_P (TREE_TYPE (type)))
+  if (TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
 return true;
 
   if (VOID_TYPE_P (type))
diff --git a/gcc/testsuite/g++.dg/ext/unary_trait_incomplete.C 
b/gcc/testsuite/g++.dg/ext/unary_trait_incomplete.C
index b60ce84dcb2..6c83279c030 100644
--- a/gcc/testsuite/g++.dg/ext/unary_trait_incomplete.C
+++ b/gcc/testsuite/g++.dg/ext/unary_trait_incomplete.C
@@ -5,72 +5,72 @@ struct C { };
 
 bool nas1 = __has_nothrow_assign(I); // { dg-error "incomplete type" }
 bool nas2 = __has_nothrow_assign(C[]);
-bool nas3 = __has_nothrow_assign(I[]); // { dg-error "incomplete type" }
+bool nas3 = __has_nothrow_assign(I[]);
 bool nas4 = __has_nothrow_assign(void);
 bool nas5 = __has_nothrow_assign(const void);
 
 bool tas1 = __has_trivial_assign(I); // { dg-error "incomplete type" }
 bool tas2 = __has_trivial_assign(C[]);
-bool tas3 = __has_trivial_assign(I[]); // { dg-error "incomplete type" }
+bool tas3 = __has_trivial_assign(I[]);
 bool tas4 = __has_trivial_assign(void);
 bool tas5 = __has_trivial_assign(const void);
 
 bool nco1 = __has_nothrow_constructor(I); // { dg-error "incomplete type" }
 bool nco2 = __has_nothrow_constructor(C[]);
-bool nco3 = __has_nothrow_constructor(I[]); // { dg-error "incomplete type" }
+bool nco3 = __has_nothrow_constructor(I[]);
 bool nco4 = __has_nothrow_constructor(void);
 bool nco5 = __has_nothrow_constructor(const void);
 
 bool tco1 = __has_trivial_constructor(I); // { dg-error "incomplete type" }
 bool tco2 = __has_trivial_constructor(C[]);
-bool tco3 = __has_trivial_constructor(I[]); // { dg-error "incomplete type" }
+bool tco3 = __has_trivial_constructor(I[]);
 bool tco4 = __has_trivial_constructor(void);
 bool tco5 = __has_trivial_constructor(const void);
 
 bool ncp1 = __has_nothrow_copy(I); // { dg-error "incomplete type" }
 bool ncp2 = __has_nothrow_copy(C[]);
-bool ncp3 = __has_nothrow_copy(I[]); // { dg-error "incomplete type" }
+bool ncp3 = __has_nothrow_copy(I[]);
 bool ncp4 = __has_nothrow_copy(void);
 bool ncp5 = __has_nothrow_copy(const void);
 
 bool tcp1 = __has_trivial_copy(I); // { dg-error "incomplete type" }
 bool tcp2 = __has_trivial_copy(C[]);
-bool tcp3 = __has_trivial_copy(I[]); // { dg-error "incomplete type" }
+bool tcp3 = __has_trivial_copy(I[]);
 bool tcp4 = __has_trivial_copy(void);
 bool tcp5 = __has_trivial_copy(const void);
 
 bool vde1 = __has_virtual_destructor(I); // { dg-error "incomplete type" }
 bool vde2 = __has_virtual_destructor(C[]);
-bool vde3 = __has_virtual_destructor(I[]); // { dg-error "incomplete type" }
+bool vde3 = __has_virtual_destructor(I[]);
 bool vde4 = __has_virtual_destructor(void);
 bool vde5 = __has_virtual_destructor(const void);
 
 bool tde1 = __has_trivial_destructor(I); // { dg-error "incomplete type" }
 bool tde2 = __has_trivial_destructor(C[]);
-bool tde3 = __has_trivial_destructor(I[]); // { dg-error "incomplete type" }
+bool tde3 = __has_trivial_destructor(I[]);
 bool tde4 = __has_trivial_destructor(void);
 bool tde5 = __has_trivial_destructor(const void);
 
 bool abs1 = __is_abstract(I); // { dg-error "incomplete type" }
 bool abs2 = __is_abstract(C[]);
-bool abs3 = __is_abstract(I[]); // { dg-error "incomplete type" }
+bool abs3 = __is_abstract(I[]);
 bool abs4 = __is_abstract(void);
 bool abs5 = __is_abstract(const void);
 
 bool pod1 = __is_pod(I); // { dg-error "incomplete type" }
 bool pod2 = __is_pod(C[]);
-bool pod3 = __is_pod(I[]); // { dg-error "incomplete type" }
+bool pod3 = __is_pod(I[]);
 bool pod4 = __is_pod(void);
 bool pod5 = __is_pod(const void);
 
 bool emp1 = __is_empty(I); // { dg-error "incomplete type" }
 bool emp2 = __is_empty(C[]);
-bool emp3 = __is_empty(I[]); // { dg-error "incomplete type" }

[pushed] c++: typeid and instantiation [PR102651]

[Jason Merrill via Gcc-patches]

PR49387 was a problem with initially asking for a typeid for a class
template specialization before it was complete, and later actually filling
in the descriptor when the class was complete, and thus disagreeing on the
form of the descriptor.  I fixed that by forcing the class to be complete,
but this testcase shows why that approach is problematic.  So instead let's
adjust the type of the descriptor later if needed.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/102651
PR c++/49387

gcc/cp/ChangeLog:

* rtti.cc (get_tinfo_decl_direct): Don't complete_type.
(emit_tinfo_decl): Update tdesc type if needed.

gcc/testsuite/ChangeLog:

* g++.dg/rtti/typeid-complete1.C: New test.
---
 gcc/cp/rtti.cc   | 15 +++
 gcc/testsuite/g++.dg/rtti/typeid-complete1.C | 14 ++
 2 files changed, 25 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/rtti/typeid-complete1.C

diff --git a/gcc/cp/rtti.cc b/gcc/cp/rtti.cc
index a4dedc31f0a..f5b43ec0fb2 100644
--- a/gcc/cp/rtti.cc
+++ b/gcc/cp/rtti.cc
@@ -446,9 +446,6 @@ get_tinfo_decl_direct (tree type, tree name, int pseudo_ix)
 
   gcc_checking_assert (TREE_CODE (type) != METHOD_TYPE);
 
-  if (pseudo_ix < 0)
-type = complete_type (type);
-
   if (CLASS_TYPE_P (type))
 d = CLASSTYPE_TYPEINFO_VAR (TYPE_MAIN_VARIANT (type));
 
@@ -1693,7 +1690,17 @@ emit_tinfo_decl (tree decl)
   tree init;
 
   DECL_EXTERNAL (decl) = 0;
-  init = get_pseudo_ti_init (type, get_pseudo_ti_index (type));
+  int pseudo_ix = get_pseudo_ti_index (type);
+  const tinfo_s *ti = get_tinfo_desc (pseudo_ix);
+  if (TREE_TYPE (decl) != ti->type)
+   {
+ /* If the class became complete since we first called get_tinfo_decl,
+its type_info descriptor may have switched from __class_type_info
+to e.g. __si_class_type_info.  */
+ TREE_TYPE (decl) = ti->type;
+ relayout_decl (decl);
+   }
+  init = get_pseudo_ti_init (type, pseudo_ix);
   DECL_INITIAL (decl) = init;
   mark_used (decl);
   cp_finish_decl (decl, init, false, NULL_TREE, 0);
diff --git a/gcc/testsuite/g++.dg/rtti/typeid-complete1.C 
b/gcc/testsuite/g++.dg/rtti/typeid-complete1.C
new file mode 100644
index 000..8d3fec46801
--- /dev/null
+++ b/gcc/testsuite/g++.dg/rtti/typeid-complete1.C
@@ -0,0 +1,14 @@
+// PR c++/102651
+
+#include 
+
+template 
+struct S : T{
+T x;
+};
+
+const void *p;
+int main()
+{
+  p = ( S** );
+}

base-commit: 654f6978cdc85a3970ff2c478d4df3e55cf4d3ab
-- 
2.27.0

Re: [PATCH] libstdc++: ppc: conditionalize vsx-only simd intrinsics

[Alexandre Oliva via Gcc-patches]

On Apr 28, 2022, Segher Boessenkool  wrote:

> On Thu, Apr 28, 2022 at 03:09:54AM -0300, Alexandre Oliva wrote:

>> +# ifdef __VSX__

> No space after # (here and everywhere else).

'k, thanks

>> +  "no __intrinsic_type support for [long] double on PPC w/o 
>> VSX");

> This change isn't in the changelog.

It is, it's just that long double is dealt with differently from the
other types, so requiring VSX for it takes a different form:

>   * include/experimental/bits/simd.h [__ALTIVEC__]: Require VSX
>   for double, long long, and 64-bit long and 64-bit long double
>   intrinsic types.   ^^



> The message should not say "long
> double" without qualifying it as "64-bit long double".

How about qualifying both such messages as in this incremental patchlet:

@@ -2456,11 +2456,11 @@ template 
 static constexpr bool _S_is_ldouble = is_same_v<_Tp, long double>;
 // allow _Tp == long double with -mlong-double-64
 static_assert(!(_S_is_ldouble && sizeof(long double) > sizeof(double)),
- "no __intrinsic_type support for long double on PPC");
+ "no __intrinsic_type support for 128-bit floating point on 
PPC");
 #ifndef __VSX__
 static_assert(!(is_same_v<_Tp, double>
|| (_S_is_ldouble && sizeof(long double) == 
sizeof(double))),
- "no __intrinsic_type support for [long] double on PPC w/o 
VSX");
+ "no __intrinsic_type support for 64-bit floating point on PPC 
w/o VSX");
 #endif
 using type =
   typename __intrinsic_type_impl<

> Okay for trunk without this part of the patch, and the spaces after the
> hash signs deleted.  Or send a new patch with the "[long] double" thing
> fixed?

Thanks, awaiting feedback on the suggestion above to post the consolidated 
patch.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH v1] RISC-V: Implement C[LT]Z_DEFINED_VALUE_AT_ZERO

[Palmer Dabbelt]

On Thu, 28 Apr 2022 15:11:49 PDT (-0700), philipp.toms...@vrull.eu wrote:

Kito,

Did you have a chance to take a look at this one?

I assume this will have to wait until we reopen for 13...
OK for 13?  Also: OK for a backport (once a branch for that exists)?


I'd assumed it was 13 material when it was sent, given the timing and 
that it didn't call out anything about being targeted at 12.  IIUC we've 
also generally only backported regression fixes and that's the standard 
policy, but maybe I'm misunderstanding something?




Philipp.


On Sun, 24 Apr 2022 at 01:44, Philipp Tomsich  wrote:


The Zbb support has introduced ctz and clz to the backend, but some
transformations in GCC need to know what the value of c[lt]z at zero
is. This affects how the optab is generated and may suppress use of
CLZ/CTZ in tree passes.

Among other things, this is needed for the transformation of
table-based ctz-implementations, such as in deepsjeng, to work
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838).

Prior to this change, the test case from PR90838 would compile to
on RISC-V targets with Zbb:
  myctz:
lui a4,%hi(.LC0)
ld  a4,%lo(.LC0)(a4)
neg a5,a0
and a5,a5,a0
mul a5,a5,a4
lui a4,%hi(.LANCHOR0)
addia4,a4,%lo(.LANCHOR0)
srlia5,a5,58
sh2add  a5,a5,a4
lw  a0,0(a5)
ret

After this change, we get:
  myctz:
ctz a0,a0
andia0,a0,63
ret


This one looks correct to me, but does it pass the rest of the test 
suite?  I haven't been running regressions with the bitmanip extensions 
enabled, and I don't see any machinery in riscv-gnu-toolchain for 
B-extension-family regression runs (plus, my box is kind of tied up 
right now anyway trying to get other stuff fixed).




Testing this with deepsjeng_r (from SPEC 2017) against QEMU, this
shows a clear reduction in dynamic instruction count:
 - before  1961888067076
 - after   1907928279874 (2.75% reduction)

gcc/ChangeLog:

* config/riscv/riscv.h (CLZ_DEFINED_VALUE_AT_ZERO): Implement.
(CTZ_DEFINED_VALUE_AT_ZERO): Same.

gcc/testsuite/ChangeLog:

* gcc.dg/pr90838.c: Add additional flags (dg-additional-options)
  when compiling for riscv64.
* gcc.target/riscv/zbb-ctz.c: New test.

Signed-off-by: Philipp Tomsich 
Signed-off-by: Manolis Tsamis 
Co-developed-by: Manolis Tsamis 

---
 gcc/config/riscv/riscv.h|  5 ++
 gcc/testsuite/gcc.dg/pr90838.c  |  2 +
 gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c | 65 
 gcc/testsuite/gcc.target/riscv/zbb-ctz.c| 66 +


I was a bit worried about where the test came from, but it looks like 
they're essentially the same as some arm64 and x86 tests so they should 
be fine.  Might be good to refactor things to avoid the duplication, 
though.



 4 files changed, 138 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-ctz.c

diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 4210e252255..95f72e2fd3f 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -1019,4 +1019,9 @@ extern void riscv_remove_unneeded_save_restore_calls 
(void);

 #define HARD_REGNO_RENAME_OK(FROM, TO) riscv_hard_regno_rename_ok (FROM, TO)

+#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
+  ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)
+#define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
+  ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)


IIUC this is correct: it expends to 8/16 for q/himode, but as we don't 
have clz/ctz defined for those it's fine.  I'll let Kito have some time 
to chime in, though.



+
 #endif /* ! GCC_RISCV_H */
diff --git a/gcc/testsuite/gcc.dg/pr90838.c b/gcc/testsuite/gcc.dg/pr90838.c
index 41c5dab9a5c..162bd6f51d0 100644
--- a/gcc/testsuite/gcc.dg/pr90838.c
+++ b/gcc/testsuite/gcc.dg/pr90838.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-forwprop2-details" } */
+/* { dg-additional-options "-march=rv64gc_zbb" { target riscv64*-*-* } } */

 int ctz1 (unsigned x)
 {
@@ -57,3 +58,4 @@ int ctz4 (unsigned long x)
 }

 /* { dg-final { scan-tree-dump-times {= \.CTZ} 4 "forwprop2" { target 
aarch64*-*-* } } } */
+/* { dg-final { scan-tree-dump-times {= \.CTZ} 4 "forwprop2" { target 
riscv64*-*-* } } } */
diff --git a/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c 
b/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
new file mode 100644
index 000..b903517197a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
@@ -0,0 +1,65 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32gc_zbb -mabi=ilp32" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
+
+int ctz1 (unsigned x)
+{
+  static const char table[32] =
+{
+  0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
+  31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 

Re: [PATCH] Disable tests that require fesetround() on platforms without it

[Palmer Dabbelt]

On Thu, 28 Apr 2022 15:22:37 PDT (-0700), jos...@codesourcery.com wrote:

On Thu, 28 Apr 2022, Palmer Dabbelt wrote:


On Thu, 28 Apr 2022 15:12:39 PDT (-0700), jos...@codesourcery.com wrote:
> On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
>
> > +proc check_effective_target_fenv_setround {} {
> > +  return [check_runtime fenv_setround {
> > +#include 
> > +#include 
> > +int
> > +main (void)
> > +{
> > +  if (fesetround (1) == 0)
>
> There is no reason to expect that 1 is a valid argument to fesetround.
> (It isn't with x86 glibc, for example.)  You need to use whatever FE_*
> rounding mode macro the test in question cares about.

Sorry, I mis-read the man page and thought that list of numbers was ABI.  At
least some of the tests are using all the rounding modes, so unless you think
it's worth splitting up both the tests and the DG check I'll just check for
all of them?


I think checking for all four of the IEEE binary rounding modes is
reasonable.  (If we add support for FE_TONEARESTFROMZERO in RISC-V glibc,
that ought to be handled separately for any GCC tests involving that
rounding mode, given that most architectures don't support it.)


Yep, I was just talking about the IEEE modes.  I'll send a v2.

Re: [PATCH] c++, coroutines: Partial reversion of r12-8308-g15a176a833f23e [PR105426].

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 28, 2022 at 11:22:45PM +0100, Iain Sandoe wrote:
> how about the following, which uniques the names by bind scope, scope nest 
> and then
> sequence within that?

That LGTM.

> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -3913,6 +3913,7 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
> void *d)
>if (TREE_CODE (*stmt) == BIND_EXPR)
>  {
>tree lvar;
> +  unsigned serial = 0;
>for (lvar = BIND_EXPR_VARS (*stmt); lvar != NULL;
>lvar = DECL_CHAIN (lvar))
> {
> @@ -3974,16 +3975,14 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
> void *d)
> buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
>  lvd->nest_depth, lvd->bind_indx);
>   else
> -   buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
> -lvd->bind_indx);
> +   buf = xasprintf ("_D%u_%u_%u", lvd->nest_depth, lvd->bind_indx,
> +serial++);
> +
>   /* TODO: Figure out if we should build a local type that has any
>  excess alignment or size from the original decl.  */
> - if (buf)
> -   {
> - local_var.field_id = coro_make_frame_entry (lvd->field_list, 
> buf,
> - lvtype, lvd->loc);
> - free (buf);
> -   }
> + local_var.field_id = coro_make_frame_entry (lvd->field_list, buf,
> + lvtype, lvd->loc);
> + free (buf);
>   /* We don't walk any of the local var sub-trees, they won't contain
>  any bind exprs.  */
> }
> 
> 
> 

Jakub

Re: [PATCH] c++, coroutines: Partial reversion of r12-8308-g15a176a833f23e [PR105426].

[Iain Sandoe]

> On 28 Apr 2022, at 20:26, Jakub Jelinek  wrote:
> 
> On Thu, Apr 28, 2022 at 08:17:04PM +0100, Iain Sandoe wrote:
>> Signed-off-by: Iain Sandoe 
>> 
>>  PR c++/105426
>> 
>> gcc/cp/ChangeLog:
>> 
>>  * coroutines.cc (register_local_var_uses): Allow promotion of unnamed
>>  temporaries to coroutine frame copies.
>> ---
>> gcc/cp/coroutines.cc | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
>> index 551ddc9cc41..2e393b2cddc 100644
>> --- a/gcc/cp/coroutines.cc
>> +++ b/gcc/cp/coroutines.cc
>> @@ -3973,6 +3973,9 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
>> void *d)
>>else if (lvname != NULL_TREE)
>>  buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
>>   lvd->nest_depth, lvd->bind_indx);
>> +  else
>> +buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
>> + lvd->bind_indx);
>>/* TODO: Figure out if we should build a local type that has any
>>   excess alignment or size from the original decl.  */
>>if (buf)
> 
> This isn't going to play well with -fcompare-debug.
> We don't guarantee same DECL_UID values between -g and -g0, just that
> when two decls are created with both -g and -g0 they compare the same,
> but with -g the gap in between them could be larger.
> So names that include DECL_UID will be often different between -g and -g0.

that’s somewhat unfortunate (having the UIDs in the frame and the gimple is 
quite
helpful to debugging).  I guess I was not expecting a difference this early in 
the FE
(we are before initial folding / constexpr stuff).

FWIW, I ran the coroutines and coroutines torture testsuites with 
-fcompare-debug.
There are 5 fails, and those are unaffected by whether the field is made 
nameless as
suggested below (so something else to investigate).

> Can't the FIELD_DECL be instead nameless?  Say change coro_make_frame_entry
> to do
>  tree id = name ? get_identifier (name) : NULL_TREE;
> instead of
>  tree id = get_identifier (name);

Unfortunately, that does not work - although I cannot see anything in the 
coroutines code
that would cause it to fail - perhaps something is not playing nicely with
DECL_VALUE_EXPRs on unnamed temps?

how about the following, which uniques the names by bind scope, scope nest and 
then
sequence within that?

Iain

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 2e393b2cddc..1d886b31c77 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3913,6 +3913,7 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
   if (TREE_CODE (*stmt) == BIND_EXPR)
 {
   tree lvar;
+  unsigned serial = 0;
   for (lvar = BIND_EXPR_VARS (*stmt); lvar != NULL;
   lvar = DECL_CHAIN (lvar))
{
@@ -3974,16 +3975,14 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
 lvd->nest_depth, lvd->bind_indx);
  else
-   buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
-lvd->bind_indx);
+   buf = xasprintf ("_D%u_%u_%u", lvd->nest_depth, lvd->bind_indx,
+serial++);
+
  /* TODO: Figure out if we should build a local type that has any
 excess alignment or size from the original decl.  */
- if (buf)
-   {
- local_var.field_id = coro_make_frame_entry (lvd->field_list, buf,
- lvtype, lvd->loc);
- free (buf);
-   }
+ local_var.field_id = coro_make_frame_entry (lvd->field_list, buf,
+ lvtype, lvd->loc);
+ free (buf);
  /* We don't walk any of the local var sub-trees, they won't contain
 any bind exprs.  */
}

Re: [PATCH] Disable tests that require fesetround() on platforms without it

[Joseph Myers]

On Thu, 28 Apr 2022, Palmer Dabbelt wrote:

> On Thu, 28 Apr 2022 15:12:39 PDT (-0700), jos...@codesourcery.com wrote:
> > On Thu, 28 Apr 2022, Palmer Dabbelt wrote:
> > 
> > > +proc check_effective_target_fenv_setround {} {
> > > +  return [check_runtime fenv_setround {
> > > +#include 
> > > +#include 
> > > +int
> > > +main (void)
> > > +{
> > > +  if (fesetround (1) == 0)
> > 
> > There is no reason to expect that 1 is a valid argument to fesetround.
> > (It isn't with x86 glibc, for example.)  You need to use whatever FE_*
> > rounding mode macro the test in question cares about.
> 
> Sorry, I mis-read the man page and thought that list of numbers was ABI.  At
> least some of the tests are using all the rounding modes, so unless you think
> it's worth splitting up both the tests and the DG check I'll just check for
> all of them?

I think checking for all four of the IEEE binary rounding modes is 
reasonable.  (If we add support for FE_TONEARESTFROMZERO in RISC-V glibc, 
that ought to be handled separately for any GCC tests involving that 
rounding mode, given that most architectures don't support it.)

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

Re: [PATCH] Disable tests that require fesetround() on platforms without it

[Palmer Dabbelt]

On Thu, 28 Apr 2022 15:12:39 PDT (-0700), jos...@codesourcery.com wrote:

On Thu, 28 Apr 2022, Palmer Dabbelt wrote:


+proc check_effective_target_fenv_setround {} {
+  return [check_runtime fenv_setround {
+#include 
+#include 
+int
+main (void)
+{
+  if (fesetround (1) == 0)


There is no reason to expect that 1 is a valid argument to fesetround.
(It isn't with x86 glibc, for example.)  You need to use whatever FE_*
rounding mode macro the test in question cares about.


Sorry, I mis-read the man page and thought that list of numbers was ABI.  
At least some of the tests are using all the rounding modes, so unless 
you think it's worth splitting up both the tests and the DG check I'll 
just check for all of them?

Re: [PATCH] Disable tests that require fesetround() on platforms without it

[Joseph Myers]

On Thu, 28 Apr 2022, Palmer Dabbelt wrote:

> +proc check_effective_target_fenv_setround {} {
> +  return [check_runtime fenv_setround {
> +#include 
> +#include 
> +int
> +main (void)
> +{
> +  if (fesetround (1) == 0)

There is no reason to expect that 1 is a valid argument to fesetround.  
(It isn't with x86 glibc, for example.)  You need to use whatever FE_* 
rounding mode macro the test in question cares about.

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

Re: [PATCH v1] RISC-V: Implement C[LT]Z_DEFINED_VALUE_AT_ZERO

[Philipp Tomsich]

Kito,

Did you have a chance to take a look at this one?

I assume this will have to wait until we reopen for 13...
OK for 13?  Also: OK for a backport (once a branch for that exists)?

Philipp.


On Sun, 24 Apr 2022 at 01:44, Philipp Tomsich  wrote:
>
> The Zbb support has introduced ctz and clz to the backend, but some
> transformations in GCC need to know what the value of c[lt]z at zero
> is. This affects how the optab is generated and may suppress use of
> CLZ/CTZ in tree passes.
>
> Among other things, this is needed for the transformation of
> table-based ctz-implementations, such as in deepsjeng, to work
> (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838).
>
> Prior to this change, the test case from PR90838 would compile to
> on RISC-V targets with Zbb:
>   myctz:
> lui a4,%hi(.LC0)
> ld  a4,%lo(.LC0)(a4)
> neg a5,a0
> and a5,a5,a0
> mul a5,a5,a4
> lui a4,%hi(.LANCHOR0)
> addia4,a4,%lo(.LANCHOR0)
> srlia5,a5,58
> sh2add  a5,a5,a4
> lw  a0,0(a5)
> ret
>
> After this change, we get:
>   myctz:
> ctz a0,a0
> andia0,a0,63
> ret
>
> Testing this with deepsjeng_r (from SPEC 2017) against QEMU, this
> shows a clear reduction in dynamic instruction count:
>  - before  1961888067076
>  - after   1907928279874 (2.75% reduction)
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h (CLZ_DEFINED_VALUE_AT_ZERO): Implement.
> (CTZ_DEFINED_VALUE_AT_ZERO): Same.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr90838.c: Add additional flags (dg-additional-options)
>   when compiling for riscv64.
> * gcc.target/riscv/zbb-ctz.c: New test.
>
> Signed-off-by: Philipp Tomsich 
> Signed-off-by: Manolis Tsamis 
> Co-developed-by: Manolis Tsamis 
>
> ---
>  gcc/config/riscv/riscv.h|  5 ++
>  gcc/testsuite/gcc.dg/pr90838.c  |  2 +
>  gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c | 65 
>  gcc/testsuite/gcc.target/riscv/zbb-ctz.c| 66 +
>  4 files changed, 138 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-ctz.c
>
> diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> index 4210e252255..95f72e2fd3f 100644
> --- a/gcc/config/riscv/riscv.h
> +++ b/gcc/config/riscv/riscv.h
> @@ -1019,4 +1019,9 @@ extern void riscv_remove_unneeded_save_restore_calls 
> (void);
>
>  #define HARD_REGNO_RENAME_OK(FROM, TO) riscv_hard_regno_rename_ok (FROM, TO)
>
> +#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
> +  ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)
> +#define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
> +  ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)
> +
>  #endif /* ! GCC_RISCV_H */
> diff --git a/gcc/testsuite/gcc.dg/pr90838.c b/gcc/testsuite/gcc.dg/pr90838.c
> index 41c5dab9a5c..162bd6f51d0 100644
> --- a/gcc/testsuite/gcc.dg/pr90838.c
> +++ b/gcc/testsuite/gcc.dg/pr90838.c
> @@ -1,5 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-options "-O2 -fdump-tree-forwprop2-details" } */
> +/* { dg-additional-options "-march=rv64gc_zbb" { target riscv64*-*-* } } */
>
>  int ctz1 (unsigned x)
>  {
> @@ -57,3 +58,4 @@ int ctz4 (unsigned long x)
>  }
>
>  /* { dg-final { scan-tree-dump-times {= \.CTZ} 4 "forwprop2" { target 
> aarch64*-*-* } } } */
> +/* { dg-final { scan-tree-dump-times {= \.CTZ} 4 "forwprop2" { target 
> riscv64*-*-* } } } */
> diff --git a/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c 
> b/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
> new file mode 100644
> index 000..b903517197a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/zbb-ctz-32.c
> @@ -0,0 +1,65 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv32gc_zbb -mabi=ilp32" } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
> +
> +int ctz1 (unsigned x)
> +{
> +  static const char table[32] =
> +{
> +  0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
> +  31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
> +};
> +
> +  return table[((unsigned)((x & -x) * 0x077CB531U)) >> 27];
> +}
> +
> +int ctz2 (unsigned x)
> +{
> +#define u 0
> +  static short table[64] =
> +{
> +  32, 0, 1,12, 2, 6, u,13, 3, u, 7, u, u, u, u,14,
> +  10, 4, u, u, 8, u, u,25, u, u, u, u, u,21,27,15,
> +  31,11, 5, u, u, u, u, u, 9, u, u,24, u, u,20,26,
> +  30, u, u, u, u,23, u,19,29, u,22,18,28,17,16, u
> +};
> +
> +  x = (x & -x) * 0x0450FBAF;
> +  return table[x >> 26];
> +}
> +
> +int ctz3 (unsigned x)
> +{
> +  static int table[32] =
> +{
> +  0, 1, 2,24, 3,19, 6,25, 22, 4,20,10,16, 7,12,26,
> +  31,23,18, 5,21, 9,15,11,30,17, 8,14,29,13,28,27
> +};
> +
> +  if (x == 0) return 32;
> +  x = (x & -x) * 0x04D7651F;
> +  return table[x >> 27];
> +}
> +
> +static const unsigned long long magic = 0x03f08c5392f756cdULL;
> +
> +static const char 

Re: [PATCH] middle-end/105376 - invalid REAL_CST for DFP constant

[Joseph Myers]

On Thu, 28 Apr 2022, Richard Biener via Gcc-patches wrote:

> We are eventually ICEing in decimal_to_decnumber on non-decimal
> REAL_VALUE_TYPE that creep in from uses of build_real (..., dconst*)
> for DFP types.  The following extends the decimal_to_decnumber
> special-casing of dconst* to build_real, avoiding the bogus REAL_CSTs
> from creeping into the IL and modified to ones not handled by
> the decimal_to_decnumber special casing.  It also makes sure to
> ICE for not handled dconst* values at the point we build the REAL_CST.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for stage1
> and eventual backporting (I'm considering making the gcc_unreachable
> conditional on flag_checking on release branches).

OK.

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

[PATCH] libstdc++: Update Solaris baselines for GCC 12.1

[Rainer Orth]

The following patch updates the Solaris baselines for GCC 12.1.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
and 11.4 in each case).

The only (expected) difference between the 11.3 and 11.4 versions is

--- baseline_symbols.txt.s113s  2022-04-28 10:37:11.464068450 +
+++ baseline_symbols.txt.s114s  2022-04-27 16:54:31.995636805 +
@@ -4070,3 +4070,3 @@
-FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.30
-FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.30
-FUNC:_ZSt10from_charsPKcS0_RfSt12chars_format@@GLIBCXX_3.4.30
+FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_RfSt12chars_format@@GLIBCXX_3.4.29

which is handled by the fix for PR libstdc++/103407.  I'm using the 11.4
version here.

Ok for master and gcc-12 branch?

Rainer

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


2022-04-27  Rainer Orth  

libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.

# HG changeset patch
# Parent  89403bf1607513bdc3a7370fe16dc831f144512e
libstdc++: Update Solaris baselines for GCC 12.1

diff --git a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt
@@ -466,6 +466,7 @@ FUNC:_ZNKSt10moneypunctIwLb1EE8groupingE
 FUNC:_ZNKSt10ostrstream5rdbufEv@@GLIBCXX_3.4
 FUNC:_ZNKSt10ostrstream6pcountEv@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPKc@@GLIBCXX_3.4
+FUNC:_ZNKSt11__timepunctIcE15_M_am_pm_formatEPPKc@@GLIBCXX_3.4.30
 FUNC:_ZNKSt11__timepunctIcE15_M_date_formatsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE15_M_time_formatsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE19_M_days_abbreviatedEPPKc@@GLIBCXX_3.4
@@ -476,6 +477,7 @@ FUNC:_ZNKSt11__timepunctIcE7_M_daysEPPKc
 FUNC:_ZNKSt11__timepunctIcE8_M_am_pmEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIcE9_M_monthsEPPKc@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPKw@@GLIBCXX_3.4
+FUNC:_ZNKSt11__timepunctIwE15_M_am_pm_formatEPPKw@@GLIBCXX_3.4.30
 FUNC:_ZNKSt11__timepunctIwE15_M_date_formatsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE15_M_time_formatsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE19_M_days_abbreviatedEPPKw@@GLIBCXX_3.4
@@ -939,6 +941,7 @@ FUNC:_ZNKSt7__cxx118time_getIcSt19istrea
 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE15_M_extract_nameES4_S4_RiPPKcmRSt8ios_baseRSt12_Ios_Iostate@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE16do_get_monthnameES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tm@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE21_M_extract_via_formatES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKc@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE21_M_extract_via_formatES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKcRSt16__time_get_state@@GLIBCXX_3.4.30
 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE24_M_extract_wday_or_monthES4_S4_RiPPKcmRSt8ios_baseRSt12_Ios_Iostate@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKcSD_@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx118time_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmcc@@GLIBCXX_3.4.21
@@ -958,6 +961,7 @@ FUNC:_ZNKSt7__cxx118time_getIwSt19istrea
 FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE15_M_extract_nameES4_S4_RiPPKwmRSt8ios_baseRSt12_Ios_Iostate@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE16do_get_monthnameES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tm@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE21_M_extract_via_formatES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKw@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE21_M_extract_via_formatES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKwRSt16__time_get_state@@GLIBCXX_3.4.30
 FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE24_M_extract_wday_or_monthES4_S4_RiPPKwmRSt8ios_baseRSt12_Ios_Iostate@@GLIBCXX_3.4.21
 FUNC:_ZNKSt7__cxx118time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE3getES4_S4_RSt8ios_baseRSt12_Ios_IostateP2tmPKwSD_@@GLIBCXX_3.4.21
 

Re: [PATCH] c++, coroutines: Partial reversion of r12-8308-g15a176a833f23e [PR105426].

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 28, 2022 at 08:17:04PM +0100, Iain Sandoe wrote:
> Signed-off-by: Iain Sandoe 
> 
>   PR c++/105426
> 
> gcc/cp/ChangeLog:
> 
>   * coroutines.cc (register_local_var_uses): Allow promotion of unnamed
>   temporaries to coroutine frame copies.
> ---
>  gcc/cp/coroutines.cc | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index 551ddc9cc41..2e393b2cddc 100644
> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -3973,6 +3973,9 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
> void *d)
> else if (lvname != NULL_TREE)
>   buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
>lvd->nest_depth, lvd->bind_indx);
> +   else
> + buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
> +  lvd->bind_indx);
> /* TODO: Figure out if we should build a local type that has any
>excess alignment or size from the original decl.  */
> if (buf)

This isn't going to play well with -fcompare-debug.
We don't guarantee same DECL_UID values between -g and -g0, just that
when two decls are created with both -g and -g0 they compare the same,
but with -g the gap in between them could be larger.
So names that include DECL_UID will be often different between -g and -g0.

Can't the FIELD_DECL be instead nameless?  Say change coro_make_frame_entry
to do
  tree id = name ? get_identifier (name) : NULL_TREE;
instead of
  tree id = get_identifier (name);
?

Jakub

Ping #4: [PATCH, V4] Eliminate power8 fusion options, use power8 tuning, PR target/102059

[Michael Meissner via Gcc-patches]

Ping #4:

| Date: Tue, 12 Apr 2022 21:14:55 -0400
| From: Michael Meissner 
| Subject: [PATCH, V4] Eliminate power8 fusion options, use power8 tuning, PR 
target/102059
| Message-ID: 

https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593153.html

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

[PATCH] c++, coroutines: Partial reversion of r12-8308-g15a176a833f23e [PR105426].

[Iain Sandoe via Gcc-patches]

The changes to fix PR 105287 included a tightening of the constraints on which
variables are promoted to frame copies.  This has exposed that we are failing
to name some variables that should be promoted.

The long-term fix is to address the cases where the naming has been missed,
but for the short-term (and for the GCC-12 branch) backing out the additional
constraint is proposed.

This makes the fix for PR 105287 more conservative.

tested on x86_64-darwin, with the reproducer from the PR which now produces
the correct output for both optimised and unoptimised code.

OK for master?
OK for GCC-12?
thanks,
Iain

Signed-off-by: Iain Sandoe 

PR c++/105426

gcc/cp/ChangeLog:

* coroutines.cc (register_local_var_uses): Allow promotion of unnamed
temporaries to coroutine frame copies.
---
 gcc/cp/coroutines.cc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 551ddc9cc41..2e393b2cddc 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3973,6 +3973,9 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
  else if (lvname != NULL_TREE)
buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
 lvd->nest_depth, lvd->bind_indx);
+ else
+   buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
+lvd->bind_indx);
  /* TODO: Figure out if we should build a local type that has any
 excess alignment or size from the original decl.  */
  if (buf)
-- 
2.24.3 (Apple Git-128)

Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd

[FX via Gcc-patches]

> Given that 12 has been branched off, is it OK now to commit this patch?

How does the patch affect the results of “make check-gfortran”? How many tests 
that failed or were unsupported pass?

FX

Re: [PATCH] Replace EVRP in DOM with ranger.

[Jeff Law via Gcc-patches]

On 4/28/2022 10:30 AM, Aldy Hernandez wrote:

[Jeff, this is the same patch I sent you last week with minor tweaks
to the commit message.]
And I just dropped it into the tester.  We should have the vast majority 
of targets tested by this time tomorrow.




[Despite the verbosity of the message, this is actually a pretty
straightforward patch.  It should've gone in last cycle, but there
was a nagging regression I couldn't get to until after stage1
had closed.]

You had other, non-work/gcc priorities.  No worries at missing gcc-12.




There are 3 uses of EVRP in DOM that must be converted.
Unfortunately, they need to be converted in one go, so further
splitting of this patch would be problematic.

ACK



There's nothing here earth shattering.  It's all pretty obvious in
retrospect, but I've added a short description of each use to aid in
reviewing:

* Convert evrp use in cprop to ranger.

   This is easy, as cprop in DOM was converted to the ranger API last
   cycle, so this is just a matter of using a ranger instead of an
   evrp_range_analyzer.
Yea.  We may have covered this before, but what does ranger do with a 
conditional equivalence?


ie if we have something like

if (a == b)
  {
    blah blah
  }

Within the true arm we know there's an equivalence.  *But* we don't want 
to just blindly replace a with b or vice-versa.  The equivalence is 
primarily useful for simplification rather than propagation.


In fact, we every much do not want to cprop in these cases.   It rarely 
helps in a meaningful way and there's no good way to know which is the 
better value to use.  Canonicalization on SSA_NAMEs doesn't  really help 
due to SSA_NAME recycling.





* Convert evrp use in threader to ranger.

   The idea here is to use the hybrid approach we used for the initial
   VRP threader conversion last cycle.  The DOM threader will continue
   using the forward threader infrastructure while continuing to query
   DOM data structures, and only if the conditional does not relsolve,
   using the ranger.  This gives us the best of both worlds, and is a
   proven approach.

   Furthermore, as frange and prange come live in the next cycle, we
   can move away from the forward threader altogether, and just add
   another backward threader.  This will not only remove the last use
   of the forward threader, but will allow us to remove at least 1 or 2
   threader instances.

Excellent.



* Convert conditional folding to use the method used by the ranger and
   evrp.  Previously DOM was calling into the guts of
   simplify_using_ranges::vrp_visit_cond_stmt.  The blessed way now is
   using fold_cond() which rewrites the conditional and edges
   automatically.

   When legacy is removed, simplify_using_ranges will be further
   cleaned up, and there will only be one entry point into simplifying
   a statement.

Sure.



* DOM was setting global ranges determined from unreachable edges as a
   side-effect of using the evrp engine.  We must handle these cases
   before nuking evrp, and DOM seems like a good fit.  I've just moved
   the snippet to DOM, but it could live anywhere else we do a DOM
   walk.
 It was a semi-desirable to record/refine global ranges in DOM, but I'd 
be surprised if too much code depended on that.  Presumably there's a 
testcase in the suite which we don't handle well if we don't let DOM 
refine/record global ranges?




   For the record, this is the case *vrp handled:

:
...
if (c_5(D) != 5)
goto ;
else
goto ;
:
__builtin_unreachable ();
:

   If M dominates all uses of c_5, we can set the global range of c_5
   to [5,5].
And that will only happen if M eventually loops back to the conditional, 
right?  Otherwise all the uses wouldn't be dominated. I suspect this is 
exceedingly rare in practice an it looks really familiar.  This is 
coming from a testcase, right?


This is the only part of the patch that makes me go "e", so I would 
like to at least explore if we can rethink the value of that test.



There is a a regression on Wstringop-overflow-4.C which I'm planning
on XFAILing.  It's another variant of the usual middle-end false
positives: having no ranges produces no warnings, but slightly refined
ranges, or worse-- isolating specific problematic cases in the
threader causes flare-ups.

ACK.




As an aside, as Richi has suggested, I think we should discuss
restricting the threader's ability to thread highly unlikely paths.
These cause no end of pain for middle-end warnings.  However,
I don't know if this would conflict with path isolation for
things like null dereferencing.  ISTR you were interested in this.

I've never though too  much about it.  You're thinking of Richi :-)

It's a balance.  I bet if we stop threading those paths we're going to 
see other issues start popping up like uninitialized warnings.


It may be the case that it's really the constant propagation on an 
isolated path that's more 

[wwwdocs] gcc-12/changes.html: Document the RISC-V libstdc++ -latomic detection

[Palmer Dabbelt]

---
IMO this one is worth documenting too, not sure if it's too late for
gcc-12's docs (due to those branch commits) so I haven't committed it
yet to avoid any fallout.
---
 htdocs/gcc-12/changes.html | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index e9f132c0..e8a9cea2 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -746,6 +746,9 @@ function Multiply (S1, S2 : Sign) return Sign is
support architecture testing marco and -march= 
parsing.
 The option -mtune=thead-c906 is added to tune for T-HEAD
c906 cores.
+libstdc++'s no longer attempts to detect built-in atomics,
+   distributions that have out-of-tree workarounds for
+   -latomic should check their ABIs again.
   
 
 
-- 
2.34.1

[committed] analyzer: handle repeated accesses after init of unknown size [PR105285]

[David Malcolm via Gcc-patches]

PR analyzer/105285 reports a false positive from
-Wanalyzer-null-dereference on git.git's reftable/reader.c.

A reduced version of the problem can be seen in test_1a of
gcc.dg/analyzer/symbolic-12.c in the following:

void test_1a (void *p, unsigned next_off)
{
  struct st_1 *r = p;

  external_fn();

  if (next_off >= r->size)
return;

  if (next_off >= r->size)
/* We should have already returned if this is the case.  */
__analyzer_dump_path (); /* { dg-bogus "path" } */
}

where the analyzer erroneously considers this path, where
(next_off >= r->size) is both false and then true:

symbolic-12.c: In function ‘test_1a’:
symbolic-12.c:22:5: note: path
   22 | __analyzer_dump_path (); /* { dg-bogus "path" } */
  | ^~~
  ‘test_1a’: events 1-5
|
|   17 |   if (next_off >= r->size)
|  |  ^
|  |  |
|  |  (1) following ‘false’ branch...
|..
|   20 |   if (next_off >= r->size)
|  |  ~~~~
|  |  | |
|  |  | (2) ...to here
|  |  (3) following ‘true’ branch...
|   21 | /* We should have already returned if this is the case.  */
|   22 | __analyzer_dump_path (); /* { dg-bogus "path" } */
|  | ~~~
|  | |
|  | (4) ...to here
|  | (5) here
|

The root cause is that, at the call to the external function, the
analyzer considers the cluster for *p to have been touched, binding it
to a conjured_svalue, but because p is void * no particular size is
known for the write, and so the cluster is bound using a symbolic key
covering the base region.  Later, the accesses to r->size are handled by
binding_cluster::get_any_binding, but binding_cluster::get_binding fails
to find a match for the concrete field lookup, due to the key for the
binding being symbolic, and reaching this code:

1522  /* If this cluster has been touched by a symbolic write, then the content
1523 of any subregion not currently specifically bound is "UNKNOWN".  */
1524  if (m_touched)
1525{
1526  region_model_manager *rmm_mgr = mgr->get_svalue_manager ();
1527  return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ());
1528}

Hence each access to r->size is an unknown svalue, and thus the
condition (next_off >= r->size) isn't tracked, leading to the path with
contradictory conditions being treated as satisfiable.

In the original reproducer in git's reftable/reader.c, the call to the
external fn is:
  reftable_record_type(rec)
which is considered to possibly write to *rec, which is *tab, where tab
is the void * argument to reftable_reader_seek_void, and thus after the
call to reftable_record_type some arbitrary amount of *rec could have
been written to.

This patch fixes things by detecting the "this cluster has been 'filled'
with a conjured value of unknown size" case, and handling
get_any_binding on it by returning a sub_svalue of the conjured_svalue,
so that repeated accesses to r->size give the same symbolic value, so
that the constraint manager rejects the bogus execution path, fixing the
false positive.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-7-g00c4405cd7f6a144d0a439e4d848d246920e6ff3.

gcc/analyzer/ChangeLog:
PR analyzer/105285
* store.cc (binding_cluster::get_any_binding): Handle accessing
sub_svalues of clusters where the base region has a symbolic
binding.

gcc/testsuite/ChangeLog:
PR analyzer/105285
* gcc.dg/analyzer/symbolic-12.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/store.cc   |  12 +++
 gcc/testsuite/gcc.dg/analyzer/symbolic-12.c | 106 
 2 files changed, 118 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/symbolic-12.c

diff --git a/gcc/analyzer/store.cc b/gcc/analyzer/store.cc
index 35f66a4b6fc..f5f8fe061f5 100644
--- a/gcc/analyzer/store.cc
+++ b/gcc/analyzer/store.cc
@@ -1519,6 +1519,18 @@ binding_cluster::get_any_binding (store_manager *mgr,
   = get_binding_recursive (mgr, reg))
 return direct_sval;
 
+  /* If we had a write to a cluster of unknown size, we might
+ have a self-binding of the whole base region with an svalue,
+ where the base region is symbolic.
+ Handle such cases by returning sub_svalue instances.  */
+  if (const svalue *cluster_sval = maybe_get_simple_value (mgr))
+{
+  /* Extract child svalue from parent svalue.  */
+  region_model_manager *rmm_mgr = mgr->get_svalue_manager ();
+  return rmm_mgr->get_or_create_sub_svalue (reg->get_type (),
+   cluster_sval, reg);
+}
+
   /* If this cluster has been touched by a symbolic write, then the content
  of any subregion not currently specifically bound is "UNKNOWN".  */
   if (m_touched)
diff --git 

[committed] analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibility

[David Malcolm via Gcc-patches]

I found this extension to -fdump-analyzer-feasibility very helpful when
debugging PR analyzer/105285.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6-gd8586b00dd00a1783862da5f0c8811a740400074.

gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (epath_finder::process_worklist_item):
Call dump_feasible_path when a path that reaches the the target
enode is found.
(epath_finder::dump_feasible_path): New.
* engine.cc (feasibility_state::dump_to_pp): New.
* exploded-graph (feasibility_state::dump_to_pp): New decl.
* feasible-graph.cc (feasible_graph::dump_feasible_path): New.
* feasible-graph.h (feasible_graph::dump_feasible_path): New
decls.
* program-point.cc (function_point::print): Fix missing trailing
newlines.
* program-point.h (program_point::print_source_line): Remove
unimplemented decl.

gcc/ChangeLog:
* doc/invoke.texi (-fdump-analyzer-feasibility): Mention the
fpath.txt output.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/diagnostic-manager.cc | 24 +++
 gcc/analyzer/engine.cc |  9 +
 gcc/analyzer/exploded-graph.h  |  2 +
 gcc/analyzer/feasible-graph.cc | 65 ++
 gcc/analyzer/feasible-graph.h  |  6 +++
 gcc/analyzer/program-point.cc  |  4 ++
 gcc/analyzer/program-point.h   |  1 -
 gcc/doc/invoke.texi|  4 +-
 8 files changed, 112 insertions(+), 3 deletions(-)

diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index bf7c8fc5147..5bd4cd49cac 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -112,6 +112,10 @@ private:
   void dump_feasible_graph (const exploded_node *target_enode,
const char *desc, unsigned diag_idx,
const feasible_graph );
+  void dump_feasible_path (const exploded_node *target_enode,
+  unsigned diag_idx,
+  const feasible_graph ,
+  const feasible_node ) const;
 
   const exploded_graph _eg;
   shortest_exploded_paths *m_sep;
@@ -510,6 +514,9 @@ epath_finder::process_worklist_item (feasible_worklist 
*worklist,
 target_enode->m_index, diag_idx,
 succ_fnode->get_path_length ());
  *out_best_path = fg->make_epath (succ_fnode);
+ if (flag_dump_analyzer_feasibility)
+   dump_feasible_path (target_enode, diag_idx, *fg, *succ_fnode);
+
  /* Success: stop the worklist iteration.  */
  return false;
}
@@ -608,6 +615,23 @@ epath_finder::dump_feasible_graph (const exploded_node 
*target_enode,
   free (filename);
 }
 
+/* Dump the path to FNODE to "BASE_NAME.DIAG_IDX.to-enN.fpath.txt".  */
+
+void
+epath_finder::dump_feasible_path (const exploded_node *target_enode,
+ unsigned diag_idx,
+ const feasible_graph ,
+ const feasible_node ) const
+{
+  auto_timevar tv (TV_ANALYZER_DUMP);
+  pretty_printer pp;
+  pp_printf (, "%s.%i.to-en%i.fpath.txt",
+dump_base_name, diag_idx, target_enode->m_index);
+  char *filename = xstrdup (pp_formatted_text ());
+  fg.dump_feasible_path (fnode, filename);
+  free (filename);
+}
+
 /* class saved_diagnostic.  */
 
 /* saved_diagnostic's ctor.
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index d8b61955aa6..e43406e3556 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -4605,6 +4605,15 @@ feasibility_state::maybe_update_for_edge (logger *logger,
   return true;
 }
 
+/* Dump this object to PP.  */
+
+void
+feasibility_state::dump_to_pp (pretty_printer *pp,
+  bool simple, bool multiline) const
+{
+  m_model.dump_to_pp (pp, simple, multiline);
+}
+
 /* A family of cluster subclasses for use when generating .dot output for
exploded graphs (-fdump-analyzer-exploded-graph), for grouping the
enodes into hierarchical boxes.
diff --git a/gcc/analyzer/exploded-graph.h b/gcc/analyzer/exploded-graph.h
index af0ab8d42c8..2dcdcc55b2a 100644
--- a/gcc/analyzer/exploded-graph.h
+++ b/gcc/analyzer/exploded-graph.h
@@ -1001,6 +1001,8 @@ public:
   const region_model _model () const { return m_model; }
   const auto_sbitmap _snodes_visited () const { return m_snodes_visited; }
 
+  void dump_to_pp (pretty_printer *pp, bool simple, bool multiline) const;
+
 private:
   region_model m_model;
   auto_sbitmap m_snodes_visited;
diff --git a/gcc/analyzer/feasible-graph.cc b/gcc/analyzer/feasible-graph.cc
index 0ac8484a7e4..fe7e79fe902 100644
--- a/gcc/analyzer/feasible-graph.cc
+++ b/gcc/analyzer/feasible-graph.cc
@@ -218,6 +218,71 @@ feasible_graph::make_epath (feasible_node *fnode) const
   return epath;
 }
 
+/* Dump the path to 

Re: [committed] Fix more problems with new linker warnings

[H.J. Lu via Gcc-patches]

On Thu, Apr 28, 2022 at 9:59 AM Jeff Law  wrote:
>
>
>
> On 4/28/2022 10:27 AM, H.J. Lu wrote:
> > On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches
> >  wrote:
> >> As I mentioned in the original thread, my change to pr94157_0 was an
> >> attempt to avoid these warnings by passing a magic flag to the linker.
> >> Of course we may not be using GNU ld.  Or we may be on a non-elf target
> >> where the flag I used doesn't exist.  Or we may even be on a ELF target
> >> where those bits weren't added to the linker (frv).  Furthermore, we
> >> need fixes to all the nested function tests as well.
> >>
> >> So even though I initially resisted pruning the warning, that seems like
> >> the best course of action.  So this patch removes my recent change to
> >> pr94157_0 and instead uses our pruning facilities.
> >>
> >> I'll be pushing this to the trunk and gcc-12 branch.
> >>
> > Can you backport it to other release branches?
> I wasn't planning to, but can if the RMs want it.
> jeff

Hi Jakub, Ricard,

Is it OK to backport the new linker support to GCC 11 and
GCC 10 branches?

Thanks.

-- 
H.J.

[PING wwwdocs PATCH v2] document zero-width field ABI changes on MIPS

[Xi Ruoyao via Gcc-patches]

Ping.

On Wed, 2022-04-06 at 23:26 +0800, Xi Ruoyao via Gcc-patches wrote:
> Document ABI changes in r12-7961, 7962, and 8023.  Ok for wwwdocs?
> 
> ---
>  htdocs/gcc-12/changes.html | 25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 4f2ee77f..c924bca3 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -50,6 +50,10 @@ a work-in-progress.
>  (so there is a C++ ABI incompatibility, GCC 4.4 and earlier compatible
>  with GCC 12 or later, incompatible with GCC 4.5 through GCC 11).
>  RISC-V has changed the handling of these already starting with GCC 10.
> +    As the ABI requires, MIPS takes them into account handling function
> +    return values so there is a C++ ABI incompatibility with GCC 4.5
> +    through 11.  For function arguments on MIPS, refer to
> +    the MIPS specific entry.
>  GCC 12 on the above targets will report such incompatibilities as
>  warnings or other diagnostics unless -Wno-psabi is used.
>    
> @@ -549,7 +553,26 @@ a work-in-progress.
>    
>  
>  
> -
> +MIPS
> +
> +  The ABI passing arguments
> +  containing zero-width fields (for example, C/C++ zero-width
> +  bit-fields, GNU C/C++ zero-length arrays, and GNU C empty structs)
> +  has changed.  Now a zero-width field will not prevent an aligned
> +  64-bit floating-point field next to it from being passed through
> +  FPR.  This is compatible with LLVM, but incompatible with previous
> +  GCC releases. GCC 12 on MIPS will report such incompatibilities as
> +  an inform unless -Wno-psabi is used.
> +  
> +  The ABI returning values
> +  containing C++17 empty bases has changed.  Now an empty base will
> +  not prevent an aggregate containing only one or two floating-point
> +  fields from being returned through FPR.  This is compatible with
> +  GCC 6 and earlier, but incompatible with GCC 7 through 11. GCC 12 on
> +  MIPS will report such incompatibilities as an inform unless
> +  -Wno-psabi is used.
> +  
> +
>  
>  
>  

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] c++: partial ordering and dependent operator expr [PR105425]

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 28, 2022 at 12:53:06PM -0400, Patrick Palka wrote:
> Here ever since r12-6022-gbb2a7f80a98de3 we stopped deeming the partial
> specialization #2 to be more specialized than #1 ultimately because
> dependent operator expressions now have a DEPENDENT_OPERATOR_TYPE type
> instead of an empty type, and this made unify stop deducing T(2) == 1
> for K during partial ordering for #1 and #2.
> 
> This minimal patch fixes this by making the relevant code in unify
> treat DEPENDENT_OPERATOR_TYPE like an empty type.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, and preapproved for
> trunk by Jason off-list.  Does this also look OK for the 12 branch?
> 
>   PR c++/105425
> 
> gcc/cp/ChangeLog:
> 
>   * pt.cc (unify) : Treat
>   DEPENDENT_OPERATOR_TYPE like an empty type.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/template/partial-specialization13.C: New test.

Ok for 12.1.

Jakub

Re: [patch, fortran, doc] Mention new CONVERT options for POWER

[Bernhard Reutner-Fischer via Gcc-patches]

Hi Thomas,

On 27 April 2022 22:34:39 CEST, Thomas Koenig via Fortran  
wrote:

+@item @code{'big_endian'}  Do all unformatted I/O in big_endian mod.e


ISTM that this should be s/mod.e/mode./ ?
thanks,

Re: [PATCH] fortran: use fpu-glibc on powerpc*-unknown-freebsd

[Piotr Kubaj via Gcc-patches]

Given that 12 has been branched off, is it OK now to commit this patch?

On 22-04-14 16:09:35, Piotr Kubaj wrote:
> On 22-04-14 09:05:17, FX wrote:
> > Hi,
> > 
> > > can you check the following patch?
> > 
> > Why restrict it to powerpc-freebsd only, and not all freebsd? Do they 
> > differ?
> amd64 and i386 on all systems use a different setting and are not affected.
> For FreeBSD-supported architectures that are not amd64, i386 or powerpc*, 
> there are also armv6, armv7, aarch64, riscv64 and riscv64sf.
> 
> However, GCC is currently not ported to riscv64 and riscv64sf (but it's 
> likely affected as well).
> aarch64 is confirmed to be affected (so armv6 and armv7 are probably also 
> affected), but I don't have any way to test whether it works on aarch64 that 
> way.
> 
> So currently limiting to powerpc*, but it will probably be extended to armv*, 
> aarch64 and riscv64* in the future.
> 
> > Otherwise it looks ok to me, but probably should be tested on a glibc 
> > non-x86 target.
> > 
> > In any case, this will be for the new branch, when stage 1 reopens.
> > 
> > FX
> 
> -- 



-- 


signature.asc
Description: PGP signature

Re: [PATCH] libstdc++: Update documentation about copyright and GPL notices in tests

[Jonathan Wakely via Gcc-patches]

On Thu, 28 Apr 2022 at 17:45, Koning, Paul via Libstdc++
 wrote:
>
>
>
> > On Apr 28, 2022, at 8:37 AM, Jonathan Wakely via Gcc-patches 
> >  wrote:
> >
> > I intend to commit this patch soon. This isn't changing the policy, just
> > adjusting the docs to match the current policy.
> >
> > I'm open to suggestions for better ways to phrase the second sentence,
> > clarifying that our tests generally have nothing novel or "authored".
> >
> > -- >8 --
> >
> > There is no need to require FSF copyright for tests that are just
> > "self-evident" ways to check the API and behaviour of the library.
> > This is consistent with tests for the compiler, which do not have
> > copyright and licence notices either.
>
> So is the theory that "self-evident" documents are in the public domain for 
> that reason?

Yes.

Let's look at a test I added this week:
libstdc++-v3/testsuite/30_threads/packaged_task/cons/deduction.cc
It has a copyright notice because (as I said in the commit log) it was
copied from an existing test that has one. But what part of that file
constituted original authorship? That code does nothing useful, it
doesn't even link. All it does is construct objects and verify that
the compiler deduced the correct type, which verifies that the library
has defined the deduction guides correctly.

Let's look at another one:
libstdc++-v3/testsuite/20_util/unique_ptr/comparison/constexpr.cc
What part of this is copyrightable? Is it where I create some
variables, or performs a series of repetitive and redundant
comparisons on them, or both?
This could almost be machine generated, and I assert that it's not
meaningful or useful or sensible to consider it as a copyrighted work.
So I didn't bother putting the notices on this one.

>  Or is the policy that for such file it is fine for the copyright to be held 
> by the author (which is the default when no assignment is made)?  And a 
> similar question applies to the license aspect also.
>
> I think I understand the intent, and that seems to make sense, but I'm 
> wondering if it has been verified by the appropriate FSF IP lawyers.

If there's a concern, why haven't they raised it for the compiler's
own testsuite? Why should libstdc++ tests have copyright notices or
GPL notices when gcc tests don't?

I count 83 *.[cChm] files under gcc/testsuite with a GPL notice, out
of some 64 THOUSAND files. The number with FSF copyright notices is
around 1100, e.g. gcc/testsuite/gcc.target/sparc/ultrasp2.c is
copyright FSF, but that seems ludicrous (yes, I know it says it's
simplified from another file which is copyright FSF, but so what ... a
left shift operation is not copyrightable).

Re: [committed] Fix more problems with new linker warnings

[Jeff Law via Gcc-patches]

On 4/28/2022 10:27 AM, H.J. Lu wrote:

On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches
 wrote:

As I mentioned in the original thread, my change to pr94157_0 was an
attempt to avoid these warnings by passing a magic flag to the linker.
Of course we may not be using GNU ld.  Or we may be on a non-elf target
where the flag I used doesn't exist.  Or we may even be on a ELF target
where those bits weren't added to the linker (frv).  Furthermore, we
need fixes to all the nested function tests as well.

So even though I initially resisted pruning the warning, that seems like
the best course of action.  So this patch removes my recent change to
pr94157_0 and instead uses our pruning facilities.

I'll be pushing this to the trunk and gcc-12 branch.


Can you backport it to other release branches?

I wasn't planning to, but can if the RMs want it.
jeff

[PATCH] c++: partial ordering and dependent operator expr [PR105425]

[Patrick Palka via Gcc-patches]

Here ever since r12-6022-gbb2a7f80a98de3 we stopped deeming the partial
specialization #2 to be more specialized than #1 ultimately because
dependent operator expressions now have a DEPENDENT_OPERATOR_TYPE type
instead of an empty type, and this made unify stop deducing T(2) == 1
for K during partial ordering for #1 and #2.

This minimal patch fixes this by making the relevant code in unify
treat DEPENDENT_OPERATOR_TYPE like an empty type.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and preapproved for
trunk by Jason off-list.  Does this also look OK for the 12 branch?

PR c++/105425

gcc/cp/ChangeLog:

* pt.cc (unify) : Treat
DEPENDENT_OPERATOR_TYPE like an empty type.

gcc/testsuite/ChangeLog:

* g++.dg/template/partial-specialization13.C: New test.
---
 gcc/cp/pt.cc   |  3 ++-
 .../g++.dg/template/partial-specialization13.C | 10 ++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/template/partial-specialization13.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 3cf1d7af8d2..cf24d482488 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -24276,7 +24276,8 @@ unify (tree tparms, tree targs, tree parm, tree arg, 
int strict,
}
}
 
-  if (!TREE_TYPE (arg))
+  if (!TREE_TYPE (arg)
+ || TREE_CODE (TREE_TYPE (arg)) == DEPENDENT_OPERATOR_TYPE)
/* Template-parameter dependent expression.  Just accept it for now.
   It will later be processed in convert_template_argument.  */
;
diff --git a/gcc/testsuite/g++.dg/template/partial-specialization13.C 
b/gcc/testsuite/g++.dg/template/partial-specialization13.C
new file mode 100644
index 000..e0a115cd06c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/partial-specialization13.C
@@ -0,0 +1,10 @@
+// PR c++/105425
+// { dg-do compile { target c++11 } }
+
+template struct when;
+template struct A;
+template struct A>;// #1
+template struct A> {}; // #2
+A> a1; // { dg-error "incomplete" }
+A> a2;
+A> a3;
-- 
2.36.0.rc2.10.g1ac7422e39

Re: [PATCH] libstdc++: Update documentation about copyright and GPL notices in tests

[Koning, Paul via Gcc-patches]

> On Apr 28, 2022, at 8:37 AM, Jonathan Wakely via Gcc-patches 
>  wrote:
> 
> I intend to commit this patch soon. This isn't changing the policy, just
> adjusting the docs to match the current policy.
> 
> I'm open to suggestions for better ways to phrase the second sentence,
> clarifying that our tests generally have nothing novel or "authored".
> 
> -- >8 --
> 
> There is no need to require FSF copyright for tests that are just
> "self-evident" ways to check the API and behaviour of the library.
> This is consistent with tests for the compiler, which do not have
> copyright and licence notices either.

So is the theory that "self-evident" documents are in the public domain for 
that reason?  Or is the policy that for such file it is fine for the copyright 
to be held by the author (which is the default when no assignment is made)?  
And a similar question applies to the license aspect also.

I think I understand the intent, and that seems to make sense, but I'm 
wondering if it has been verified by the appropriate FSF IP lawyers.

paul

[patch, wwwdocs] Mention POWER IEEE128 changes for gcc 12

[Thomas Koenig via Gcc-patches]

Hi,

the attached patch documents the support for IEEE long double for
Fortran.  OK?  Suggestions for better wording?

Best regards

Thomas


Mention support for IEEE 128-bit long double for Fortran.

* htdocs/gcc-12/changes.html: Mention support for IEEE
128-bit long double for Fortran.diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index e9f132c0..083d713e 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -497,6 +497,14 @@ function Multiply (S1, S2 : Sign) return Sign is
 conforming to the Fortran 2018 standard.  Previous versions
 used OPERATOR which conforms to TS 18508.
   
+  
+On POWER systems which support it, -mabi=ieeelongdouble
+now uses IEEE 128-bit for REAL(KIND=16).
+R16_IBM and R16_IEEE have been added to the
+-fconvert option, the CONVERT specifyer of
+the OPEN statement and the GFORTRAN_CONVERT_UNIT
+environment variable.
+  
 
 
 

[PATCH] Replace EVRP in DOM with ranger.

[Aldy Hernandez via Gcc-patches]

[Jeff, this is the same patch I sent you last week with minor tweaks
to the commit message.]

[Despite the verbosity of the message, this is actually a pretty
straightforward patch.  It should've gone in last cycle, but there
was a nagging regression I couldn't get to until after stage1
had closed.]

There are 3 uses of EVRP in DOM that must be converted.
Unfortunately, they need to be converted in one go, so further
splitting of this patch would be problematic.

There's nothing here earth shattering.  It's all pretty obvious in
retrospect, but I've added a short description of each use to aid in
reviewing:

* Convert evrp use in cprop to ranger.

  This is easy, as cprop in DOM was converted to the ranger API last
  cycle, so this is just a matter of using a ranger instead of an
  evrp_range_analyzer.

* Convert evrp use in threader to ranger.

  The idea here is to use the hybrid approach we used for the initial
  VRP threader conversion last cycle.  The DOM threader will continue
  using the forward threader infrastructure while continuing to query
  DOM data structures, and only if the conditional does not relsolve,
  using the ranger.  This gives us the best of both worlds, and is a
  proven approach.

  Furthermore, as frange and prange come live in the next cycle, we
  can move away from the forward threader altogether, and just add
  another backward threader.  This will not only remove the last use
  of the forward threader, but will allow us to remove at least 1 or 2
  threader instances.

* Convert conditional folding to use the method used by the ranger and
  evrp.  Previously DOM was calling into the guts of
  simplify_using_ranges::vrp_visit_cond_stmt.  The blessed way now is
  using fold_cond() which rewrites the conditional and edges
  automatically.

  When legacy is removed, simplify_using_ranges will be further
  cleaned up, and there will only be one entry point into simplifying
  a statement.

* DOM was setting global ranges determined from unreachable edges as a
  side-effect of using the evrp engine.  We must handle these cases
  before nuking evrp, and DOM seems like a good fit.  I've just moved
  the snippet to DOM, but it could live anywhere else we do a DOM
  walk.

  For the record, this is the case *vrp handled:

:
...
if (c_5(D) != 5)
goto ;
else
goto ;
:
__builtin_unreachable ();
:

  If M dominates all uses of c_5, we can set the global range of c_5
  to [5,5].

I have tested on x86-64, pcc64le, and aarch64 Linux.

I also ran threading benchmarks as well as performance benchmarks.

DOM threads 1.56% more paths which ultimately yields a miniscule total
increase of 0.03%.

The conversion to ranger brings a 7.87% performance drop in DOM, which
is a wash in overall compilation.  This is in line with other
replacements of legacy evrp with ranger.  We handle a lot more cases.
It's not free :).

There is a a regression on Wstringop-overflow-4.C which I'm planning
on XFAILing.  It's another variant of the usual middle-end false
positives: having no ranges produces no warnings, but slightly refined
ranges, or worse-- isolating specific problematic cases in the
threader causes flare-ups.

As an aside, as Richi has suggested, I think we should discuss
restricting the threader's ability to thread highly unlikely paths.
These cause no end of pain for middle-end warnings.  However,
I don't know if this would conflict with path isolation for
things like null dereferencing.  ISTR you were interested in this.

BTW, I think the Wstringop-overflow-4.C test is problematic and I've
attached my analysis.  Basically the regression is caused by a bad
interaction with the rounding/alignment that placement new has inlined
into the IL.  This happens for int16_r[] which the test is testing.
Ranger can glean some range info, which causes DOM threading to
isolate a path which causes a warning.

OK for trunk?

gcc/ChangeLog:

* tree-ssa-dom.cc (dom_jt_state): Pass ranger to constructor
instead of evrp.
(dom_jt_state::push): Remove m_evrp.
(dom_jt_state::pop): Same.
(dom_jt_state::record_ranges_from_stmt): Remove.
(dom_jt_state::register_equiv): Remove updating of evrp ranges.
(class dom_jt_simplifier): Pass ranger to constructor.
Inherit from hybrid_jt_simplifier.
(dom_jt_simplifier::simplify): Convert to ranger.
(pass_dominator::execute): Same.
(all_uses_feed_or_dominated_by_stmt): New.
(dom_opt_dom_walker::set_global_ranges_from_unreachable_edges): New.
(dom_opt_dom_walker::before_dom_children): Call
set_global_ranges_from_unreachable_edges.
Do not call record_ranges_from_stmt.
(dom_opt_dom_walker::after_dom_children): Remove evrp use.
(cprop_operand): Use int_range<> instead of value_range.
(dom_opt_dom_walker::fold_cond): New.
(dom_opt_dom_walker::optimize_stmt): Pass ranger to
   

Re: [committed] Fix more problems with new linker warnings

[H.J. Lu via Gcc-patches]

On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches
 wrote:
>
> As I mentioned in the original thread, my change to pr94157_0 was an
> attempt to avoid these warnings by passing a magic flag to the linker.
> Of course we may not be using GNU ld.  Or we may be on a non-elf target
> where the flag I used doesn't exist.  Or we may even be on a ELF target
> where those bits weren't added to the linker (frv).  Furthermore, we
> need fixes to all the nested function tests as well.
>
> So even though I initially resisted pruning the warning, that seems like
> the best course of action.  So this patch removes my recent change to
> pr94157_0 and instead uses our pruning facilities.
>
> I'll be pushing this to the trunk and gcc-12 branch.
>

Can you backport it to other release branches?

Thanks.

-- 
H.J.

[committed] Fix more problems with new linker warnings

[Jeff Law via Gcc-patches]

As I mentioned in the original thread, my change to pr94157_0 was an 
attempt to avoid these warnings by passing a magic flag to the linker.  
Of course we may not be using GNU ld.  Or we may be on a non-elf target 
where the flag I used doesn't exist.  Or we may even be on a ELF target 
where those bits weren't added to the linker (frv).  Furthermore, we 
need fixes to all the nested function tests as well.


So even though I initially resisted pruning the warning, that seems like 
the best course of action.  So this patch removes my recent change to 
pr94157_0 and instead uses our pruning facilities.


I'll be pushing this to the trunk and gcc-12 branch.

Jeffcommit af71f96631920f32ed9ec6c1c35d140dbe9992d1
Author: Jeff Law 
Date:   Thu Apr 28 12:03:52 2022 -0400

[committed] Fix more problems with new linker warnings

gcc/testsuite
* gcc.dg/lto/pr94157_0.c: Revert last change.
* lib/prune.exp (prune_gcc_output): Prune new linker warning.

diff --git a/gcc/testsuite/gcc.dg/lto/pr94157_0.c 
b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
index a76141b1809..a6e308b855b 100644
--- a/gcc/testsuite/gcc.dg/lto/pr94157_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr94157_0.c
@@ -1,6 +1,6 @@
 /* { dg-lto-do link } */
 /* { dg-require-effective-target gas } */
-/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack 
-Wa,--noexecstack -Wa,--execstack  -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wl,-z,execstack} } } */
+/* { dg-lto-options { { -O0 -fipa-vrp -flto -Wa,--noexecstack 
-Wa,--noexecstack -Wa,--execstack  -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack -Wa,--execstack 
-Wa,--execstack } } } */
 
 int main() {
 
diff --git a/gcc/testsuite/lib/prune.exp b/gcc/testsuite/lib/prune.exp
index 422498527aa..04c6a1dd7a1 100644
--- a/gcc/testsuite/lib/prune.exp
+++ b/gcc/testsuite/lib/prune.exp
@@ -82,6 +82,11 @@ proc prune_gcc_output { text } {
 regsub -all "(^|\n)\[^\n\]*file path prefix \[^\n\]* never used" $text "" 
text
 regsub -all "(^|\n)\[^\n\]*linker input file unused since linking not 
done" $text "" text
 
+# Ideally the tests would indicate that executable stacks were needed
+# to the linker.  But the option for that varies and may not even exist
+# on some targets.  So we're stuck pruning the warning.
+regsub -all "(^|\n)(\[^\n\]*: warning:\[^\n\]*requires executable 
stack\[^\n\]*\n?)+" $text "\\1" text
+
 # Ignore harmless warnings from Xcode 3.2.x.
 regsub -all "(^|\n)\[^\n\]*ld: warning: can't add line info to anonymous 
symbol\[^\n\]*" $text "" text
 regsub -all "(^|\n)\[^\n\]*warning: 
DWARFDebugInfoEntry::AppendDependants\[^\n\]*AT_\[^\n\]*FORM_ref4\[^\n\]*" 
$text "" text

Re: [PATCH] libstdc++: ppc: conditionalize vsx-only simd intrinsics

[Segher Boessenkool]

On Thu, Apr 28, 2022 at 03:56:18PM +0200, Matthias Kretz wrote:
> On Thursday, 28 April 2022 08:09:54 CEST Alexandre Oliva via Gcc-patches 
> wrote:
> > libstdc++'s bits/simd.h section for PPC (Altivec) defines various
> > intrinsic vector types that are only available along with VSX: 64-bit
> > long double, double, (un)signed long long, and 64-bit (un)signed long.
> 
> Oh, so uttering `__vector double` is ill-formed (now) without VSX? I'm fairly 
> certain I tested without VSX and the __intrinsic_type_impl definitions were 
> fine.

It always was undefined (and did not work):
  error: use of 'double' in AltiVec types is invalid without '-mvsx'


Segher

[PATCH] Disable tests that require fesetround() on platforms without it

[Palmer Dabbelt]

Some tests check for fenv and then proceed to use fesetround() directly,
but some platforms (at least RISC-V soft-float) have fenv but don't
support rounding modes.  This adds a DG check that fesetround() actually
functions, which is then used by all the tests that call fesetround()
explicitly.

gcc/testsuite/ChangeLog

* lib/target-supports.exp
(check_effective_target_fenv_setround): New function.
* gcc.dg/torture/fp-double-convert-float-1.c: Check
fenv_fesetround.
* gcc.dg/torture/fp-int-convert-float128-timode-3.c: Likewise.
* gcc.dg/torture/fp-int-convert-timode-2.c: Likewise.
* gcc.dg/torture/fp-int-convert-timode-3.c: Likewise.
* gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
* gcc.dg/torture/fp-uint64-convert-double-1.c: Likewise.
* gcc.dg/torture/fp-uint64-convert-double-2.c: Likewise.

---

I started getting a bunch of atomic-related failures with this patch,
but they persist when I've gone back and disabled it so I'm pretty sure
it's something in my environment.  Without this patch I get a bunch of
failures on the RISC-V soft float targets, I haven't tried anywhere
else.
---
 .../gcc.dg/torture/fp-double-convert-float-1.c |  2 +-
 .../torture/fp-int-convert-float128-timode-3.c |  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-2.c   |  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-3.c   |  2 +-
 .../gcc.dg/torture/fp-int-convert-timode-4.c   |  2 +-
 .../torture/fp-uint64-convert-double-1.c   |  2 +-
 .../torture/fp-uint64-convert-double-2.c   |  2 +-
 gcc/testsuite/lib/target-supports.exp  | 18 ++
 8 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c 
b/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c
index ec23274ea98..656e5c345e7 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c
@@ -1,6 +1,6 @@
 /* PR57245 */
 /* { dg-do run } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-additional-options "-frounding-math" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode-3.c 
b/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode-3.c
index c445d10522e..499e8c0cabf 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode-3.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode-3.c
@@ -4,7 +4,7 @@
 /* { dg-require-effective-target __float128 } */
 /* { dg-require-effective-target base_quadfloat_support } */
 /* { dg-require-effective-target int128 } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-options "-frounding-math" } */
 /* { dg-add-options __float128 } */
 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-2.c 
b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-2.c
index a82f03d079c..3f91f8f3833 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-2.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-2.c
@@ -2,7 +2,7 @@
float.  */
 /* { dg-do run } */
 /* { dg-require-effective-target int128 } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-options "-frounding-math" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-3.c 
b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-3.c
index 707d539335f..816fcb1120e 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-3.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-3.c
@@ -2,7 +2,7 @@
float.  */
 /* { dg-do run } */
 /* { dg-require-effective-target int128 } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-options "-frounding-math" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-4.c 
b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-4.c
index 09600f90903..6337a6d3f1e 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-4.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode-4.c
@@ -2,7 +2,7 @@
float.  */
 /* { dg-do run } */
 /* { dg-require-effective-target int128 } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-options "-frounding-math" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c 
b/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c
index fadad8c3198..43aeb81a602 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c
@@ -1,6 +1,6 @@
 /* PR84407 */
 /* { dg-do run } */
-/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target fenv_setround } */
 /* { dg-additional-options "-frounding-math 

Re: [PATCH] doc: Remove misleading text about multilibs for IEEE long double

[Michael Meissner via Gcc-patches]

On Thu, Apr 28, 2022 at 10:46:17AM +0100, Jonathan Wakely wrote:
> IIUC this text is not true (maybe it was back in 2018?)

Initially I thought the way to transition to IEEE 128-bit long double would be
through multilibs, but we never installed multilibs for the different long
double types.  So yeah, the comment doesn't make sense these days.

> OK for trunk?
> 
> Which branches should it be on too, all of them?
> 
> -- >8 --
> 
> The choice of ieee or ibm long double format is orthogonal to multilibs,
> as the two sets of symbols co-exist and don't need a separate multilib.
> 
> gcc/ChangeLog:
> 
>   * doc/install.texi (Configuration): Remove misleading text
>   around LE PowerPC Linux multilibs.
> ---
>  gcc/doc/install.texi | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 3192824bdc4..10bfceffceb 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -2139,17 +2139,6 @@ Until all of the libraries are converted to use IEEE 
> 128-bit floating
>  point, it is not recommended to use
>  @option{--with-long-double-format=ieee}.
> 
> -On little endian PowerPC Linux systems, if you explicitly set the
> -@code{long double} type, it will build multilibs to allow you to
> -select either @code{long double} format, unless you disable multilibs
> -with the @code{--disable-multilib} option.  At present,
> -@code{long double} multilibs are not built on big endian PowerPC Linux
> -systems.  If you are building multilibs, you will need to configure
> -the compiler using the @option{--with-system-zlib} option.
> -
> -If you do not set the @code{long double} type explicitly, no multilibs
> -will be generated.
> -
>  @item --enable-fdpic
>  On SH Linux systems, generate ELF FDPIC code.
> 
> -- 
> 2.34.1
> 

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH] tree-optimization/105219 - bogus max iters for vectorized epilogue

[Andre Vieira (lists) via Gcc-patches]

On 27/04/2022 15:03, Richard Biener wrote:

On Wed, 27 Apr 2022, Richard Biener wrote:


The following makes sure to take into account prologue peeling
when trying to narrow down the maximum number of iterations
computed for the epilogue of a vectorized epilogue.

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

I did not verify this solves the original aarch64 testcase yet
but it looks like a simpler fix and explains why I don't see
the issue on the 11 branch which does otherwise the same transforms.

Can you verify the original aarch64 case is fixed and maybe add
a testcase for that to gcc.target/aarch64?


Your committed patch fixes the original testcase, but I'll stick to the 
testcase you have as it's less fiddly, but I will add the options 
required to make it originally fail for aarch64.


Is the attached patch OK for trunk?


    gcc/ChangeLog:

    PR tree-optimization/105219
    * testsuite/gcc.dg/vect/pr105219.c: Add aarch64 target option.
diff --git a/gcc/testsuite/gcc.dg/vect/pr105219.c 
b/gcc/testsuite/gcc.dg/vect/pr105219.c
index 
0cb7ae2f4d6dc2a236740d34b59b771255b067b7..4bca5bbba30a9740a54e6205bc0d0c8011070977
 100644
--- a/gcc/testsuite/gcc.dg/vect/pr105219.c
+++ b/gcc/testsuite/gcc.dg/vect/pr105219.c
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-additional-options "-O3" } */
 /* { dg-additional-options "-mtune=intel" { target x86_64-*-* i?86-*-* } } */
+/* { dg-additional-options "-mtune=thunderx" { target aarch64*-*-* } } */
 
 #include "tree-vect.h"
 

Re: [PATCH v2] c++: ICE with temporary of class type in DMI [PR100252]

[Marek Polacek via Gcc-patches]

On Thu, Apr 28, 2022 at 10:12:04AM -0400, Patrick Palka wrote:
> On Wed, 27 Apr 2022, Marek Polacek wrote:
> 
> > On Wed, Apr 27, 2022 at 11:00:46AM -0400, Patrick Palka wrote:
> > > On Tue, 26 Apr 2022, Marek Polacek wrote:
> > > 
> > > > Consider
> > > > 
> > > >   struct A {
> > > > int x;
> > > > int y = x;
> > > >   };
> > > > 
> > > >   struct B {
> > > > int x = 0;
> > > > int y = A{x}.y; // #1
> > > >   };
> > > > 
> > > > where for #1 we end up with
> > > > 
> > > >   {.x=(&)->x, .y=(& > > > A>)->x}
> > > > 
> > > > that is, two PLACEHOLDER_EXPRs for different types on the same level in
> > > > a {}.  This crashes because our CONSTRUCTOR_PLACEHOLDER_BOUNDARY 
> > > > mechanism to
> > > > avoid replacing unrelated PLACEHOLDER_EXPRs cannot deal with it.
> > > > 
> > > > Here's why we wound up with those PLACEHOLDER_EXPRs: When we're 
> > > > performing
> > > > cp_parser_late_parsing_nsdmi for "int y = A{x}.y;" we use 
> > > > finish_compound_literal
> > > > on type=A, compound_literal={((struct B *) this)->x}.  When digesting 
> > > > this
> > > > initializer, we call get_nsdmi which creates a PLACEHOLDER_EXPR for A 
> > > > -- we don't
> > > > have any object to refer to yet.  After digesting, we have
> > > > 
> > > >   {.x=((struct B *) this)->x, .y=(&)->x}
> > > > 
> > > > and since we've created a PLACEHOLDER_EXPR inside it, we marked the 
> > > > whole ctor
> > > > CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  f_c_l creates a TARGET_EXPR and 
> > > > returns
> > > > 
> > > >   TARGET_EXPR x, 
> > > > .y=(&)->x}>
> > > > 
> > > > Then we get to
> > > > 
> > > >   B b = {};
> > > > 
> > > > and call store_init_value, which digest the {}, which produces
> > > > 
> > > >   {.x=NON_LVALUE_EXPR <0>, .y=(TARGET_EXPR  > > > {.x=(&)->x, .y=(& > > > A>)->x}>).y}
> > > > 
> > > > The call to replace_placeholders in store_init_value will not do 
> > > > anything:
> > > > we've marked the inner { } CONSTRUCTOR_PLACEHOLDER_BOUNDARY, and it's 
> > > > only
> > > > a sub-expression, so replace_placeholders does nothing, so the  > > > struct B>
> > > > stays even though now is the perfect time to replace it because we have 
> > > > an
> > > > object for it: 'b'.
> > > > 
> > > > Later, in cp_gimplify_init_expr the *expr_p is
> > > > 
> > > >   D.2395 = {.x=(&)->x, 
> > > > .y=(&)->x}
> > > > 
> > > > where D.2395 is of type A, but we crash because we hit , 
> > > > which
> > > > has a different type.
> > > > 
> > > > My idea was to replace  with D.2384 in f_c_l after 
> > > > creating the
> > > > TARGET_EXPR because that means we have an object we can refer to.  Then 
> > > > clear
> > > > CONSTRUCTOR_PLACEHOLDER_BOUNDARY because we no longer have a 
> > > > PLACEHOLDER_EXPR
> > > > in the {}.  Then store_init_value will be able to replace  > > > B> with
> > > > 'b', and we should be good to go.
> > > 
> > > Makes sense to me.  It seems all was well until break_out_target_exprs,
> > > called from get_nsdmi for B::y, replaced the 'this' in the initializer
> > > 
> > >   (TARGET_EXPR x, 
> > > .y=(&)->x}>).y;
> > > 
> > > with a PLACEHOLDER_EXPR;
> > > 
> > >   (TARGET_EXPR )->x, 
> > > .y=(&)->x}>).y;
> > > 
> > > This seems to be the wrong thing to do when the 'this' appears inside a
> > > CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructor because the new
> > > PLACEHOLDER_EXPR then can't be resolved correctly.
> > 
> > Exactly.
> > 
> > > So in light of this I wonder if we should instead perform this handling
> > > you added to finish_compound_literal in break_out_target_exprs /
> > > bot_manip instead?
> > 
> > Unfortunately that causes an ICE in gimplify_var_or_parm_decl on the new
> > testcase I've added here.  bot_manip is a different context and so I can't
> > use parsing_nsdmi anymore, and it seems we'd replace the placeholders too
> > aggressively in bot_manip.  So I'm not sure if that's the best place.
> 
> Ah :/ good catch...
> 
> FWIW the transformation itself (doing replace_placeholders followed by
> clearing CONSTRUCTOR_PLACEHOLDER_BOUNDARY) makes sense to me, and I'm
> happy with doing it in finish_compound_literal when parsing_nsdmi, so
> the patch LGTM.

Thanks for taking a look.
 
> (I guess we could also consider doing the transformation in get_nsdmi or
> digest_nsdmi_init via cp_walk_tree, but I don't have a preference either 
> way..)

I actually considered doing it in get_nsdmi, but it's either too early (don't
have a TARGET_EXPR yet, therefore no object to refer to), or too late -- we're
just about to introduce .  I felt like it may be
best to replace the  at the earliest opportunity,
which if f_c_l.

Marek

Re: libgomp GCN plugin: Clean up unused references to system-provided HSA Runtime library (was: [PATCH 1/4] Remove build dependence on HSA run-time)

[Andrew Stubbs]

On 06/04/2022 11:02, Thomas Schwinge wrote:

Hi!

On 2021-01-14T15:50:23+0100, I wrote:

I'm raising here an issue with HSA libgomp plugin code changes from a
while ago.  While HSA is now no longer relevant for GCC master branch,
the same code has also been copied into the GCN libgomp plugin.


Here is another small clean-up patch (to enable further clean-up):


This is commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove
build dependence on HSA run-time":

On 2016-11-22T14:27:44+0100, Martin Jambor  wrote:

--- a/libgomp/plugin/configfrag.ac
+++ b/libgomp/plugin/configfrag.ac



@@ -195,8 +183,8 @@ if test x"$enable_offload_targets" != x; then
  tgt_name=hsa
  PLUGIN_HSA=$tgt
  PLUGIN_HSA_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
-PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS $HSA_KMT_LDFLAGS"
-PLUGIN_HSA_LIBS="-lhsa-runtime64 -lhsakmt"
+PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
+PLUGIN_HSA_LIBS="-ldl"


So this switched from directly linking against 'libhsa-runtime64.so' to a
'libdl'-based runtime linking variant.


(Not intending to change anything regarding that.)

Given the 'PLUGIN_HSA_LIBS' change cited above, OK to push the attached
"libgomp GCN plugin: Clean up unused references to system-provided HSA
Runtime library"?


OK.

Andrew

Re: [PATCH v2] c++: ICE with temporary of class type in DMI [PR100252]

[Patrick Palka via Gcc-patches]

On Wed, 27 Apr 2022, Marek Polacek wrote:

> On Wed, Apr 27, 2022 at 11:00:46AM -0400, Patrick Palka wrote:
> > On Tue, 26 Apr 2022, Marek Polacek wrote:
> > 
> > > Consider
> > > 
> > >   struct A {
> > > int x;
> > > int y = x;
> > >   };
> > > 
> > >   struct B {
> > > int x = 0;
> > > int y = A{x}.y; // #1
> > >   };
> > > 
> > > where for #1 we end up with
> > > 
> > >   {.x=(&)->x, .y=(& > > A>)->x}
> > > 
> > > that is, two PLACEHOLDER_EXPRs for different types on the same level in
> > > a {}.  This crashes because our CONSTRUCTOR_PLACEHOLDER_BOUNDARY 
> > > mechanism to
> > > avoid replacing unrelated PLACEHOLDER_EXPRs cannot deal with it.
> > > 
> > > Here's why we wound up with those PLACEHOLDER_EXPRs: When we're performing
> > > cp_parser_late_parsing_nsdmi for "int y = A{x}.y;" we use 
> > > finish_compound_literal
> > > on type=A, compound_literal={((struct B *) this)->x}.  When digesting this
> > > initializer, we call get_nsdmi which creates a PLACEHOLDER_EXPR for A -- 
> > > we don't
> > > have any object to refer to yet.  After digesting, we have
> > > 
> > >   {.x=((struct B *) this)->x, .y=(&)->x}
> > > 
> > > and since we've created a PLACEHOLDER_EXPR inside it, we marked the whole 
> > > ctor
> > > CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  f_c_l creates a TARGET_EXPR and returns
> > > 
> > >   TARGET_EXPR x, .y=(& > > struct A>)->x}>
> > > 
> > > Then we get to
> > > 
> > >   B b = {};
> > > 
> > > and call store_init_value, which digest the {}, which produces
> > > 
> > >   {.x=NON_LVALUE_EXPR <0>, .y=(TARGET_EXPR  > > {.x=(&)->x, .y=(& > > A>)->x}>).y}
> > > 
> > > The call to replace_placeholders in store_init_value will not do anything:
> > > we've marked the inner { } CONSTRUCTOR_PLACEHOLDER_BOUNDARY, and it's only
> > > a sub-expression, so replace_placeholders does nothing, so the  > > struct B>
> > > stays even though now is the perfect time to replace it because we have an
> > > object for it: 'b'.
> > > 
> > > Later, in cp_gimplify_init_expr the *expr_p is
> > > 
> > >   D.2395 = {.x=(&)->x, .y=(& > > struct A>)->x}
> > > 
> > > where D.2395 is of type A, but we crash because we hit , 
> > > which
> > > has a different type.
> > > 
> > > My idea was to replace  with D.2384 in f_c_l after creating 
> > > the
> > > TARGET_EXPR because that means we have an object we can refer to.  Then 
> > > clear
> > > CONSTRUCTOR_PLACEHOLDER_BOUNDARY because we no longer have a 
> > > PLACEHOLDER_EXPR
> > > in the {}.  Then store_init_value will be able to replace  
> > > with
> > > 'b', and we should be good to go.
> > 
> > Makes sense to me.  It seems all was well until break_out_target_exprs,
> > called from get_nsdmi for B::y, replaced the 'this' in the initializer
> > 
> >   (TARGET_EXPR x, .y=(& > struct A>)->x}>).y;
> > 
> > with a PLACEHOLDER_EXPR;
> > 
> >   (TARGET_EXPR )->x, 
> > .y=(&)->x}>).y;
> > 
> > This seems to be the wrong thing to do when the 'this' appears inside a
> > CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructor because the new
> > PLACEHOLDER_EXPR then can't be resolved correctly.
> 
> Exactly.
> 
> > So in light of this I wonder if we should instead perform this handling
> > you added to finish_compound_literal in break_out_target_exprs /
> > bot_manip instead?
> 
> Unfortunately that causes an ICE in gimplify_var_or_parm_decl on the new
> testcase I've added here.  bot_manip is a different context and so I can't
> use parsing_nsdmi anymore, and it seems we'd replace the placeholders too
> aggressively in bot_manip.  So I'm not sure if that's the best place.

Ah :/ good catch...

FWIW the transformation itself (doing replace_placeholders followed by
clearing CONSTRUCTOR_PLACEHOLDER_BOUNDARY) makes sense to me, and I'm
happy with doing it in finish_compound_literal when parsing_nsdmi, so
the patch LGTM.

(I guess we could also consider doing the transformation in get_nsdmi or
digest_nsdmi_init via cp_walk_tree, but I don't have a preference either way..)

> 
> -- >8 --
> Consider
> 
>   struct A {
> int x;
> int y = x;
>   };
> 
>   struct B {
> int x = 0;
> int y = A{x}.y; // #1
>   };
> 
> where for #1 we end up with
> 
>   {.x=(&)->x, .y=(&)->x}
> 
> that is, two PLACEHOLDER_EXPRs for different types on the same level in
> a {}.  This crashes because our CONSTRUCTOR_PLACEHOLDER_BOUNDARY mechanism to
> avoid replacing unrelated PLACEHOLDER_EXPRs cannot deal with it.
> 
> Here's why we wound up with those PLACEHOLDER_EXPRs: When we're performing
> cp_parser_late_parsing_nsdmi for "int y = A{x}.y;" we use 
> finish_compound_literal
> on type=A, compound_literal={((struct B *) this)->x}.  When digesting this
> initializer, we call get_nsdmi which creates a PLACEHOLDER_EXPR for A -- we 
> don't
> have any object to refer to yet.  After digesting, we have
> 
>   {.x=((struct B *) this)->x, .y=(&)->x}
> 
> and since we've created a PLACEHOLDER_EXPR inside it, we marked the whole ctor
> CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  f_c_l creates a TARGET_EXPR 

Re: [PATCH] libstdc++: ppc: conditionalize vsx-only simd intrinsics

[Matthias Kretz via Gcc-patches]

On Thursday, 28 April 2022 08:09:54 CEST Alexandre Oliva via Gcc-patches 
wrote:
> libstdc++'s bits/simd.h section for PPC (Altivec) defines various
> intrinsic vector types that are only available along with VSX: 64-bit
> long double, double, (un)signed long long, and 64-bit (un)signed long.

Oh, so uttering `__vector double` is ill-formed (now) without VSX? I'm fairly 
certain I tested without VSX and the __intrinsic_type_impl definitions were 
fine.

> experimental/simd/standard_abi_usable{,_2}.cc tests error out reporting
> the unmet requirements when the target cpu doesn't enable VSX.  Make the
> reported instrinsic types conditional on VSX so that 
> can be used on ppc variants that do not have VSX support.

IIRC this will break other valid uses. You'd have to run `make check-simd` 
(see libstdc++-v3/testsuite/experimental/simd/README.md) to be certain nothing 
breaks. I will also take a look.

> Regstrapped on powerpc64el-linux-gnu.  Ok to install?
> 
> This is also relevant for gcc-11.  Tested with
> x86_64-linux-gnu-x-ppc64-vx7r2.  Ok for gcc-11?
> 
> 
> for  libstdc++-v3/ChangeLog
> 
>   * include/experimental/bits/simd.h [__ALTIVEC__]: Require VSX
>   for double, long long, and 64-bit long and 64-bit long double
>   intrinsic types.
> ---
>  libstdc++-v3/include/experimental/bits/simd.h |   11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libstdc++-v3/include/experimental/bits/simd.h
> b/libstdc++-v3/include/experimental/bits/simd.h index
> 82e9841195e1d..66c07127ec435 100644
> --- a/libstdc++-v3/include/experimental/bits/simd.h
> +++ b/libstdc++-v3/include/experimental/bits/simd.h
> @@ -2430,17 +2430,23 @@ template 
>template <>  
>\ struct __intrinsic_type_impl<_Tp> { using type = __vector _Tp; }
> _GLIBCXX_SIMD_PPC_INTRIN(float);
> +# ifdef __VSX__
>  _GLIBCXX_SIMD_PPC_INTRIN(double);
> +# endif
>  _GLIBCXX_SIMD_PPC_INTRIN(signed char);
>  _GLIBCXX_SIMD_PPC_INTRIN(unsigned char);
>  _GLIBCXX_SIMD_PPC_INTRIN(signed short);
>  _GLIBCXX_SIMD_PPC_INTRIN(unsigned short);
>  _GLIBCXX_SIMD_PPC_INTRIN(signed int);
>  _GLIBCXX_SIMD_PPC_INTRIN(unsigned int);
> +# if defined __VSX__ || __LONG_WIDTH__ == 32
>  _GLIBCXX_SIMD_PPC_INTRIN(signed long);
>  _GLIBCXX_SIMD_PPC_INTRIN(unsigned long);
> +# endif
> +# ifdef __VSX__
>  _GLIBCXX_SIMD_PPC_INTRIN(signed long long);
>  _GLIBCXX_SIMD_PPC_INTRIN(unsigned long long);
> +# endif
>  #undef _GLIBCXX_SIMD_PPC_INTRIN
> 
>  template 
> @@ -2452,8 +2458,9 @@ template 
>  static_assert(!(_S_is_ldouble && sizeof(long double) > sizeof(double)),
> "no __intrinsic_type support for long double on PPC");
>  #ifndef __VSX__
> -static_assert(!is_same_v<_Tp, double>,
> -   "no __intrinsic_type support for double on PPC w/o VSX");
> +static_assert(!(is_same_v<_Tp, double>
> + || (_S_is_ldouble && sizeof(long double) == 
sizeof(double))),
> +   "no __intrinsic_type support for [long] double on PPC w/o 
VSX");

The missing condition here was an incorrect omission. With -mlong-double-64 
and without VSX no assertion caught the issue.

IIRC, a user won't get to see this error message unless there's a bug in the 
simd library implementation, so the error message is good enough for me. (It's 
talking about __intrinsic_type, the user would be lost in any case.)

>  #endif
>  using type =
>typename __intrinsic_type_impl<


-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 stdₓ::simd
──

[PING] libgomp GCN plugin: Clean up unused references to system-provided HSA Runtime library (was: [PATCH 1/4] Remove build dependence on HSA run-time)

[Thomas Schwinge]

Hi!

Ping.

On 2022-04-06T12:02:08+0200, I wrote:
> On 2021-01-14T15:50:23+0100, I wrote:
>> I'm raising here an issue with HSA libgomp plugin code changes from a
>> while ago.  While HSA is now no longer relevant for GCC master branch,
>> the same code has also been copied into the GCN libgomp plugin.
>
> Here is another small clean-up patch (to enable further clean-up):
>
>> This is commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove
>> build dependence on HSA run-time":
>>
>> On 2016-11-22T14:27:44+0100, Martin Jambor  wrote:
>>> --- a/libgomp/plugin/configfrag.ac
>>> +++ b/libgomp/plugin/configfrag.ac
>>
>>> @@ -195,8 +183,8 @@ if test x"$enable_offload_targets" != x; then
>>> tgt_name=hsa
>>> PLUGIN_HSA=$tgt
>>> PLUGIN_HSA_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
>>> -   PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS $HSA_KMT_LDFLAGS"
>>> -   PLUGIN_HSA_LIBS="-lhsa-runtime64 -lhsakmt"
>>> +   PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
>>> +   PLUGIN_HSA_LIBS="-ldl"
>>
>> So this switched from directly linking against 'libhsa-runtime64.so' to a
>> 'libdl'-based runtime linking variant.
>
> (Not intending to change anything regarding that.)
>
> Given the 'PLUGIN_HSA_LIBS' change cited above, OK to push the attached
> "libgomp GCN plugin: Clean up unused references to system-provided HSA
> Runtime library"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 5e28a267a34282e4d6001e5f89a3b7bd7a0f20c7 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 6 Apr 2022 11:31:45 +0200
Subject: [PATCH] libgomp GCN plugin: Clean up unused references to
 system-provided HSA Runtime library

This is only active if GCC is 'configure'd with '--with-hsa-runtime=[...]' or
'--with-hsa-runtime-include=[...]', '--with-hsa-runtime-lib=[...]' -- which
nobody really is doing, as far as I can tell.

Originally changed for the libgomp HSA plugin in
commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749)
"Remove build dependence on HSA run-time", and later propagated into the GCN
plugin, these are no longer built against system-provided HSA Runtime library.
Instead, unconditionally built against the GCC-shipped 'include/hsa*.h' header
files, and at run time does 'dlopen("libhsa-runtime64.so.1")'.  It thus doesn't
make sense to consider references to system-provided HSA Runtime library during
libgomp GCN plugin build.

	libgomp/
	* plugin/configfrag.ac (HSA_RUNTIME_CPPFLAGS)
	(HSA_RUNTIME_LDFLAGS): Remove.
	* configure: Regenerate.
---
 libgomp/configure| 10 --
 libgomp/plugin/configfrag.ac | 10 --
 2 files changed, 20 deletions(-)

diff --git a/libgomp/configure b/libgomp/configure
index a73a6d44003..8bb67c650a6 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15244,8 +15244,6 @@ HSA_RUNTIME_INCLUDE=
 HSA_RUNTIME_LIB=
 
 
-HSA_RUNTIME_CPPFLAGS=
-HSA_RUNTIME_LDFLAGS=
 
 
 # Check whether --with-hsa-runtime was given.
@@ -15275,12 +15273,6 @@ fi
 if test "x$with_hsa_runtime_lib" != x; then
   HSA_RUNTIME_LIB=$with_hsa_runtime_lib
 fi
-if test "x$HSA_RUNTIME_INCLUDE" != x; then
-  HSA_RUNTIME_CPPFLAGS=-I$HSA_RUNTIME_INCLUDE
-fi
-if test "x$HSA_RUNTIME_LIB" != x; then
-  HSA_RUNTIME_LDFLAGS=-L$HSA_RUNTIME_LIB
-fi
 
 PLUGIN_GCN=0
 PLUGIN_GCN_CPPFLAGS=
@@ -15390,8 +15382,6 @@ rm -f core conftest.err conftest.$ac_objext \
 	  *)
 		tgt_plugin=gcn
 		PLUGIN_GCN=$tgt
-		PLUGIN_GCN_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
-		PLUGIN_GCN_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
 		PLUGIN_GCN_LIBS="-ldl"
 		PLUGIN_GCN=1
 		;;
diff --git a/libgomp/plugin/configfrag.ac b/libgomp/plugin/configfrag.ac
index da573bd8387..56461b89117 100644
--- a/libgomp/plugin/configfrag.ac
+++ b/libgomp/plugin/configfrag.ac
@@ -97,8 +97,6 @@ HSA_RUNTIME_INCLUDE=
 HSA_RUNTIME_LIB=
 AC_SUBST(HSA_RUNTIME_INCLUDE)
 AC_SUBST(HSA_RUNTIME_LIB)
-HSA_RUNTIME_CPPFLAGS=
-HSA_RUNTIME_LDFLAGS=
 
 AC_ARG_WITH(hsa-runtime,
 	[AS_HELP_STRING([--with-hsa-runtime=PATH],
@@ -121,12 +119,6 @@ fi
 if test "x$with_hsa_runtime_lib" != x; then
   HSA_RUNTIME_LIB=$with_hsa_runtime_lib
 fi
-if test "x$HSA_RUNTIME_INCLUDE" != x; then
-  HSA_RUNTIME_CPPFLAGS=-I$HSA_RUNTIME_INCLUDE
-fi
-if test "x$HSA_RUNTIME_LIB" != x; then
-  HSA_RUNTIME_LDFLAGS=-L$HSA_RUNTIME_LIB
-fi
 
 PLUGIN_GCN=0
 PLUGIN_GCN_CPPFLAGS=
@@ -225,8 +217,6 @@ if test x"$enable_offload_targets" != x; then
 	  *)
 		tgt_plugin=gcn
 		PLUGIN_GCN=$tgt
-		PLUGIN_GCN_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
-		PLUGIN_GCN_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
 		PLUGIN_GCN_LIBS="-ldl"
 		PLUGIN_GCN=1
 		;;
-- 
2.25.1

[PING] libgomp testsuite: Don't amend 'LD_LIBRARY_PATH' for system-provided HSA Runtime library (was: [PATCH 1/4] Remove build dependence on HSA run-time)

[Thomas Schwinge]

Hi!

Ping.

On 2022-04-06T11:20:47+0200, I wrote:
> On 2021-01-14T15:50:23+0100, I wrote:
>> I'm raising here an issue with HSA libgomp plugin code changes from a
>> while ago.  While HSA is now no longer relevant for GCC master branch,
>> the same code has also been copied into the GCN libgomp plugin.
>
> Here is another small clean-up patch (to enable further clean-up):
>
>> This is commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove
>> build dependence on HSA run-time":
>>
>> On 2016-11-22T14:27:44+0100, Martin Jambor  wrote:
>>> --- a/libgomp/plugin/configfrag.ac
>>> +++ b/libgomp/plugin/configfrag.ac
>>
>>> @@ -195,8 +183,8 @@ if test x"$enable_offload_targets" != x; then
>>> tgt_name=hsa
>>> PLUGIN_HSA=$tgt
>>> PLUGIN_HSA_CPPFLAGS=$HSA_RUNTIME_CPPFLAGS
>>> -   PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS $HSA_KMT_LDFLAGS"
>>> -   PLUGIN_HSA_LIBS="-lhsa-runtime64 -lhsakmt"
>>> +   PLUGIN_HSA_LDFLAGS="$HSA_RUNTIME_LDFLAGS"
>>> +   PLUGIN_HSA_LIBS="-ldl"
>>
>> So this switched from directly linking against 'libhsa-runtime64.so' to a
>> 'libdl'-based runtime linking variant.
>
> (Not intending to change anything regarding that.)
>
>> For avoidance of doubt, [an earlier] change doesn't affect (build-tree) 
>> testsuite
>> usage, where we have:
>>
>> libgomp/testsuite/libgomp-test-support.exp.in:set hsa_runtime_lib 
>> "@HSA_RUNTIME_LIB@"
>>
>> libgomp/testsuite/lib/libgomp.exp:  append 
>> always_ld_library_path ":$hsa_runtime_lib"
>
> But, as I argue in the attached "libgomp testsuite: Don't amend
> 'LD_LIBRARY_PATH' for system-provided HSA Runtime library", we should
> actually clean this up as well.  OK to push that?
>
>
> Grüße
>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 364d01339883f5276ef09d68a5d9a2e0010ab641 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 6 Apr 2022 10:39:56 +0200
Subject: [PATCH] libgomp testsuite: Don't amend 'LD_LIBRARY_PATH' for
 system-provided HSA Runtime library

This is only active if GCC is 'configure'd with '--with-hsa-runtime=[...]' or
'--with-hsa-runtime-lib=[...]' -- which nobody really is doing, as far as I can
tell.

'libgomp/testsuite/lib/libgomp.exp:libgomp_init' states:

# For build-tree testing, also consider the library paths used for builing.
# For installed testing, we assume all that to be provided in the sysroot.
if { $blddir != "" } {
[...]
global hsa_runtime_lib
if { $hsa_runtime_lib != "" } {
append always_ld_library_path ":$hsa_runtime_lib"
}
}

However, the libgomp GCN plugin is unconditionally built against the
GCC-shipped 'include/hsa*.h' header files, and at run time does
'dlopen("libhsa-runtime64.so.1")', so there is no system-provided HSA Runtime
library "used for builing".  It thus doesn't make sense to amend
'LD_LIBRARY_PATH' for system-provided HSA Runtime library.

	libgomp/
	* testsuite/lib/libgomp.exp (libgomp_init): Don't
	'append always_ld_library_path ":$hsa_runtime_lib"'.
	* testsuite/libgomp-test-support.exp.in (hsa_runtime_lib): Don't set.
---
 libgomp/testsuite/lib/libgomp.exp | 4 
 libgomp/testsuite/libgomp-test-support.exp.in | 1 -
 2 files changed, 5 deletions(-)

diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index 8c5ecfff0ac..0aaa58f19c5 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -202,10 +202,6 @@ proc libgomp_init { args } {
 	lappend ALWAYS_CFLAGS "additional_flags=-L$cuda_driver_lib"
 	append always_ld_library_path ":$cuda_driver_lib"
 	}
-	global hsa_runtime_lib
-	if { $hsa_runtime_lib != "" } {
-	append always_ld_library_path ":$hsa_runtime_lib"
-	}
 }
 
 # We use atomic operations in the testcases to validate results.
diff --git a/libgomp/testsuite/libgomp-test-support.exp.in b/libgomp/testsuite/libgomp-test-support.exp.in
index 98fb442b537..3c88d1d5a62 100644
--- a/libgomp/testsuite/libgomp-test-support.exp.in
+++ b/libgomp/testsuite/libgomp-test-support.exp.in
@@ -1,6 +1,5 @@
 set cuda_driver_include "@CUDA_DRIVER_INCLUDE@"
 set cuda_driver_lib "@CUDA_DRIVER_LIB@"
-set hsa_runtime_lib "@HSA_RUNTIME_LIB@"
 
 set offload_plugins "@offload_plugins@"
 set offload_targets "@offload_targets@"
-- 
2.35.1

Re: libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'

[Thomas Schwinge]

Hi Tom!

On 2022-04-08T09:35:44+0200, Tom de Vries  wrote:
> On 4/8/22 00:27, Thomas Schwinge wrote:
>> On 2017-01-13T19:11:23+0100, Jakub Jelinek  wrote:
>>> Especially for distributions it is undesirable to need to have proprietary
>>> CUDA libraries and headers installed when building GCC.
>>
>>> --- libgomp/plugin/configfrag.ac.jj   2017-01-13 12:07:56.0 +0100
>>> +++ libgomp/plugin/configfrag.ac  2017-01-13 17:33:26.608240936 +0100
>>
>>> +   PLUGIN_NVPTX_CPPFLAGS='-I$(srcdir)/plugin/cuda'
>>> +   PLUGIN_NVPTX_LIBS='-ldl'
>>> +   PLUGIN_NVPTX_DYNAMIC=1
>>
>>> +AC_DEFINE_UNQUOTED([PLUGIN_NVPTX_DYNAMIC], [$PLUGIN_NVPTX_DYNAMIC],
>>> +  [Define to 1 if the NVIDIA plugin should dlopen libcuda.so.1, 0 if it 
>>> should be linked against it.])
>>
>> Actually, the conditionals leading to 'PLUGIN_NVPTX_DYNAMIC=1' here do
>> control two orthogonal aspects; OK to disentangle that with the attached
>> "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into
>> 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"?

> we discussed dropping --with-cuda, so do I understand it correctly that
> you now propose to drop --with-cuda and --with-cuda-driver-lib but
> intend to keep --with-cuda-driver-include ?

No, I think you're reading too much into this first patch.  ;-)

The goal with this patch is just to help disentangle two orthogonal
concepts (as described in the commit log), and then...

> Can you explain what user or maintainer scenario is served by this?

... in a next step, we may indeed remove the current user-visible
'--with-cuda-driver' etc., but keep the underlying functionality
available for the developers.  That's to address the point you'd made in
the "Proposal to remove '--with-cuda-driver'" thread: that it still
"could be useful for debugging / comparison purposes" -- and especially
for development purposes, in my opinion: if you develop CUDA API-level
changes in the libgomp nvptx plugin, it's likely to be easier to just use
the full CUDA toolkit 'cuda.h' and directly link against libcuda (so that
you've got all symbols etc. available), and only once you know what
exactly you need, update GCC's 'include/cuda/cuda.h' and
'libgomp/plugin/cuda-lib.def'.

With that hopefully clarified, OK to push the re-attached
"libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into
'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"?

> Is
> there a problem with using gcc's cuda.h?

No, all good.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From c455522ac5d8ab41e5d11f8997678e042ff48e87 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 7 Apr 2022 23:10:16 +0200
Subject: [PATCH] libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into
 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'

Including the GCC-shipped 'include/cuda/cuda.h' vs. system  and
'dlopen'ing the CUDA Driver library vs. linking it are separate concerns.

	libgomp/
	* plugin/Makefrag.am: Handle 'PLUGIN_NVPTX_DYNAMIC'.
	* plugin/configfrag.ac (PLUGIN_NVPTX_DYNAMIC): Change
	'AC_DEFINE_UNQUOTED' into 'AM_CONDITIONAL'.
	* plugin/plugin-nvptx.c: Split 'PLUGIN_NVPTX_DYNAMIC' into
	'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and
	'PLUGIN_NVPTX_LINK_LIBCUDA'.
	* Makefile.in: Regenerate.
	* config.h.in: Likewise.
	* configure: Likewise.
---
 libgomp/Makefile.in   | 26 +++---
 libgomp/config.h.in   |  4 
 libgomp/configure | 21 +++--
 libgomp/plugin/Makefrag.am| 16 +++-
 libgomp/plugin/configfrag.ac  |  3 +--
 libgomp/plugin/plugin-nvptx.c |  4 ++--
 6 files changed, 52 insertions(+), 22 deletions(-)

diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 22cb2136a08..d43c584a32d 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -119,8 +119,16 @@ build_triplet = @build@
 host_triplet = @host@
 target_triplet = @target@
 @PLUGIN_NVPTX_TRUE@am__append_1 = libgomp-plugin-nvptx.la
-@PLUGIN_GCN_TRUE@am__append_2 = libgomp-plugin-gcn.la
-@USE_FORTRAN_TRUE@am__append_3 = openacc.f90
+
+# Including the GCC-shipped 'include/cuda/cuda.h' vs. system .
+@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_2 = -DPLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H \
+@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@	-DPLUGIN_NVPTX_LINK_LIBCUDA
+
+# 'dlopen'ing the CUDA Driver library vs. linking it.
+@PLUGIN_NVPTX_DYNAMIC_TRUE@@PLUGIN_NVPTX_TRUE@am__append_3 = $(PLUGIN_NVPTX_LIBS)
+@PLUGIN_NVPTX_DYNAMIC_FALSE@@PLUGIN_NVPTX_TRUE@am__append_4 = $(PLUGIN_NVPTX_LIBS)
+@PLUGIN_GCN_TRUE@am__append_5 = libgomp-plugin-gcn.la
+@USE_FORTRAN_TRUE@am__append_6 = openacc.f90
 subdir = .
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
 am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \

Re: Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

[Jeff Law via Gcc-patches]

On 4/28/2022 4:31 AM, Richard Biener wrote:

On Thu, 28 Apr 2022, Jakub Jelinek wrote:


On Thu, Apr 28, 2022 at 10:39:39AM +0200, Uros Bizjak wrote:

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

2022-04-22  Jakub Jelinek  

   PR target/105331
   * config/i386/i386.cc (ix86_gimplify_va_arg): Mark va_arg_tmp
   temporary TREE_ADDRESSABLE before trying to gimplify ADDR_EXPR
   of it.

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

Sorry, I have no idea if this patch is correct or not.

Richard or Jeff, could you please review it instead?

OK.

Agreed.  In fact I'd fixed something very similar in our port a while ago.

Jeff

Re: [PATCH] libstdc++: ppc: conditionalize vsx-only simd intrinsics

[Segher Boessenkool]

Hi!

On Thu, Apr 28, 2022 at 03:09:54AM -0300, Alexandre Oliva wrote:
> libstdc++'s bits/simd.h section for PPC (Altivec) defines various
> intrinsic vector types that are only available along with VSX: 64-bit
> long double, double, (un)signed long long, and 64-bit (un)signed long.
> 
> experimental/simd/standard_abi_usable{,_2}.cc tests error out reporting
> the unmet requirements when the target cpu doesn't enable VSX.  Make the
> reported instrinsic types conditional on VSX so that 
> can be used on ppc variants that do not have VSX support.

>   * include/experimental/bits/simd.h [__ALTIVEC__]: Require VSX
>   for double, long long, and 64-bit long and 64-bit long double
>   intrinsic types.

> --- a/libstdc++-v3/include/experimental/bits/simd.h
> +++ b/libstdc++-v3/include/experimental/bits/simd.h
> @@ -2430,17 +2430,23 @@ template 
>template <>
>   \
>  struct __intrinsic_type_impl<_Tp> { using type = __vector _Tp; }
>  _GLIBCXX_SIMD_PPC_INTRIN(float);
> +# ifdef __VSX__

No space after # (here and everywhere else).

>  #ifndef __VSX__
> -static_assert(!is_same_v<_Tp, double>,
> -   "no __intrinsic_type support for double on PPC w/o VSX");
> +static_assert(!(is_same_v<_Tp, double>
> + || (_S_is_ldouble && sizeof(long double) == 
> sizeof(double))),
> +   "no __intrinsic_type support for [long] double on PPC w/o 
> VSX");
>  #endif

This change isn't in the changelog.  The message should not say "long
double" without qualifying it as "64-bit long double".  It is probably
best to just keep the message as-is, the other possibilities for long
double aren't supported either, not even with VSX, and all this becomes
much too complicated to put in a simple error message.  It confuses the
poor user, as well.

Alternatively you can make it two separate error messages, one for
double, one for 64-bit long double.

Okay for trunk without this part of the patch, and the spaces after the
hash signs deleted.  Or send a new patch with the "[long] double" thing
fixed?

Thanks!


Segher

[pushed] testsuite,X86: Fix missing USER_LABEL_PREFIX cases.

[Iain Sandoe via Gcc-patches]

Yet another set of testcases that do not account for targets that
use __USER_LABEL_PREFIX__.

tested on x86_64 Linux and Darwin, pushed to master,
thanks,
Iain

Signed-off-by: Iain Sandoe 

gcc/testsuite/ChangeLog:

* gcc.target/i386/memcpy-strategy-10.c: Account for
__USER_LABEL_PREFIX__.
* gcc.target/i386/memcpy-strategy-5.c: Likewise.
* gcc.target/i386/memset-strategy-5.c: Likewise.
* gcc.target/i386/memset-strategy-7.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c | 4 ++--
 gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c  | 4 ++--
 gcc/testsuite/gcc.target/i386/memset-strategy-5.c  | 4 ++--
 gcc/testsuite/gcc.target/i386/memset-strategy-7.c  | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c 
b/gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c
index 970aa741971..860fcc9f801 100644
--- a/gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c
+++ b/gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=skylake -mno-sse" } */
-/* { dg-final { scan-assembler "jmp\tmemcpy" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "call\tmemcpy" { target ia32 } } } */
+/* { dg-final { scan-assembler "jmp\t_?memcpy" { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler "call\t_?memcpy" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "rep movsb" } } */
 
 void
diff --git a/gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c 
b/gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c
index 83c333b551d..833e37fa325 100644
--- a/gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c
+++ b/gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=tigerlake -mno-sse" } */
-/* { dg-final { scan-assembler "jmp\tmemcpy" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "call\tmemcpy" { target ia32 } } } */
+/* { dg-final { scan-assembler "jmp\t_?memcpy" { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler "call\t_?memcpy" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "rep movsb" } } */
 
 void
diff --git a/gcc/testsuite/gcc.target/i386/memset-strategy-5.c 
b/gcc/testsuite/gcc.target/i386/memset-strategy-5.c
index dc1de8e79c2..73ce2df6060 100644
--- a/gcc/testsuite/gcc.target/i386/memset-strategy-5.c
+++ b/gcc/testsuite/gcc.target/i386/memset-strategy-5.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=tigerlake -mno-sse" } */
-/* { dg-final { scan-assembler "jmp\tmemset" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "call\tmemset" { target ia32 } } } */
+/* { dg-final { scan-assembler "jmp\t_?memset" { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler "call\t_?memset" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "rep stosb" } } */
 
 void
diff --git a/gcc/testsuite/gcc.target/i386/memset-strategy-7.c 
b/gcc/testsuite/gcc.target/i386/memset-strategy-7.c
index 07c2816910c..653829e6fc7 100644
--- a/gcc/testsuite/gcc.target/i386/memset-strategy-7.c
+++ b/gcc/testsuite/gcc.target/i386/memset-strategy-7.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=skylake -mno-sse" } */
-/* { dg-final { scan-assembler "jmp\tmemset" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "call\tmemset" { target ia32 } } } */
+/* { dg-final { scan-assembler "jmp\t_?memset" { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler "call\t_?memset" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "rep stosb" } } */
 
 void
-- 
2.24.3 (Apple Git-128)

[pushed] testsuite: Add target requires for ifuncs to mv31.C.

[Iain Sandoe via Gcc-patches]

g++.target/i386/mv31.C fails on targets without ifuncs support so add
the necessary target supports guard.

tested on x86_64 linux and darwin.
pushed to master, thanks,
Iain

Signed-off-by: Iain Sandoe 

gcc/testsuite/ChangeLog:

* g++.target/i386/mv31.C: Add target supports guard for ifuncs.
---
 gcc/testsuite/g++.target/i386/mv31.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.target/i386/mv31.C 
b/gcc/testsuite/g++.target/i386/mv31.C
index 5d8fd1ddf75..70a40f1e28a 100644
--- a/gcc/testsuite/g++.target/i386/mv31.C
+++ b/gcc/testsuite/g++.target/i386/mv31.C
@@ -1,4 +1,5 @@
 // PR c++/104669
+// { dg-require-ifunc "" }
 
 void bar()
 {
-- 
2.24.3 (Apple Git-128)

[PATCH] libstdc++: Update documentation about copyright and GPL notices in tests

[Jonathan Wakely via Gcc-patches]

I intend to commit this patch soon. This isn't changing the policy, just
adjusting the docs to match the current policy.

I'm open to suggestions for better ways to phrase the second sentence,
clarifying that our tests generally have nothing novel or "authored".

-- >8 --

There is no need to require FSF copyright for tests that are just
"self-evident" ways to check the API and behaviour of the library.
This is consistent with tests for the compiler, which do not have
copyright and licence notices either.

libstdc++-v3/ChangeLog:

* doc/xml/manual/test.xml: Remove requirement for copyright and
GPL notice in tests.
* doc/html/manual/test.html: Regenerate.
---
 libstdc++-v3/doc/html/manual/test.html | 8 ++--
 libstdc++-v3/doc/xml/manual/test.xml   | 8 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/test.html 
b/libstdc++-v3/doc/html/manual/test.html
index ef56a305687..10ae4ed5e1b 100644
--- a/libstdc++-v3/doc/html/manual/test.html
+++ b/libstdc++-v3/doc/html/manual/test.html
@@ -371,8 +371,12 @@ cat 27_io/objects/char/3_xin.in | 
a.out
-All files are copyright the FSF, and GPL'd: this is very
-important.  The first copyright year should correspond to the date
+Historically all test files were copyright the FSF, and GPL licensed.
+We no longer require that, because most tests are uninteresting
+and contain no "original authorship", and so would not be protected
+by copyright anyway.
+If you do want to add the FSF copyright notice and GPL licence text,
+then the first copyright year should correspond to the date
 the file was checked in to version control. If a test is copied from
 an existing file it should retain the copyright years from the
 original file.
diff --git a/libstdc++-v3/doc/xml/manual/test.xml 
b/libstdc++-v3/doc/xml/manual/test.xml
index ee00b06e385..7bc6e339723 100644
--- a/libstdc++-v3/doc/xml/manual/test.xml
+++ b/libstdc++-v3/doc/xml/manual/test.xml
@@ -630,8 +630,12 @@ cat 27_io/objects/char/3_xin.in | a.out

 

-All files are copyright the FSF, and GPL'd: this is very
-important.  The first copyright year should correspond to the date
+Historically all test files were copyright the FSF, and GPL licensed.
+We no longer require that, because most tests are uninteresting
+and contain no "original authorship", and so would not be protected
+by copyright anyway.
+If you do want to add the FSF copyright notice and GPL licence text,
+then the first copyright year should correspond to the date
 the file was checked in to version control. If a test is copied from
 an existing file it should retain the copyright years from the
 original file.
-- 
2.34.1

[committed] libstdc++: Fix error reporting in filesystem::copy [PR99290]

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux, pushed to trunk. I'll backport this too.

-- >8 --

The recursive calls to filesystem::copy should stop if any of them
reports an error.

libstdc++-v3/ChangeLog:

PR libstdc++/99290
* src/c++17/fs_ops.cc (fs::copy): Pass error_code to
directory_iterator constructor, and check on each iteration.
* src/filesystem/ops.cc (fs::copy): Likewise.
* testsuite/27_io/filesystem/operations/copy.cc: Check for
errors during recursion.
* testsuite/experimental/filesystem/operations/copy.cc:
Likewise.
---
 libstdc++-v3/src/c++17/fs_ops.cc  |  8 +++--
 libstdc++-v3/src/filesystem/ops.cc|  8 +++--
 .../27_io/filesystem/operations/copy.cc   | 29 +++
 .../filesystem/operations/copy.cc | 29 +++
 4 files changed, 70 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 4552a730bf2..435368fa5c5 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -408,8 +408,12 @@ fs::copy(const path& from, const path& to, copy_options 
options,
   // set an unused bit in options to disable further recursion
   if (!is_set(options, copy_options::recursive))
options |= static_cast(4096);
-  for (const directory_entry& x : directory_iterator(from))
-   copy(x.path(), to/x.path().filename(), options, ec);
+  for (const directory_entry& x : directory_iterator(from, ec))
+   {
+ copy(x.path(), to/x.path().filename(), options, ec);
+ if (ec)
+   return;
+   }
 }
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
   // 2683. filesystem::copy() says "no effects"
diff --git a/libstdc++-v3/src/filesystem/ops.cc 
b/libstdc++-v3/src/filesystem/ops.cc
index e2a2cefdf49..98ddff5a66e 100644
--- a/libstdc++-v3/src/filesystem/ops.cc
+++ b/libstdc++-v3/src/filesystem/ops.cc
@@ -350,8 +350,12 @@ fs::copy(const path& from, const path& to, copy_options 
options,
   // set an unused bit in options to disable further recursion
   if (!is_set(options, copy_options::recursive))
options |= static_cast(4096);
-  for (const directory_entry& x : directory_iterator(from))
-   copy(x.path(), to/x.path().filename(), options, ec);
+  for (const directory_entry& x : directory_iterator(from, ec))
+   {
+ copy(x.path(), to/x.path().filename(), options, ec);
+ if (ec)
+   return;
+   }
 }
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
   // 2683. filesystem::copy() says "no effects"
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc
index b85628cdf30..b936e04493b 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc
@@ -193,6 +193,34 @@ test05()
   VERIFY( !ec );  // Previous value should be cleared (LWG 2683)
 }
 
+void
+test_pr99290()
+{
+  auto dir = __gnu_test::nonexistent_path();
+  auto source = dir/"source";
+  auto dest = dir/"dest";
+  create_directories(source/"emptydir");
+  create_directories(dest/"emptydir");
+  std::ofstream{source/"file"} << 'a';
+  std::ofstream{dest/"file"} << 'b';
+  // PR libstdc++/99290
+  // std::filesystem::copy does not always report errors for recursion
+  std::error_code ec;
+  copy(source, dest, ec);
+  VERIFY( ec == std::errc::file_exists );
+
+#if __cpp_exceptions
+  try {
+copy(source, dest);
+VERIFY( false );
+  } catch (const fs::filesystem_error& e) {
+VERIFY( e.code() == std::errc::file_exists );
+  }
+#endif
+
+  remove_all(dir);
+}
+
 int
 main()
 {
@@ -201,4 +229,5 @@ main()
   test03();
   test04();
   test05();
+  test_pr99290();
 }
diff --git a/libstdc++-v3/testsuite/experimental/filesystem/operations/copy.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/copy.cc
index 319632a5a76..5cd6b483c26 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/operations/copy.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/copy.cc
@@ -190,6 +190,34 @@ test05()
   VERIFY( !ec );  // Previous value should be cleared (LWG 2683)
 }
 
+void
+test_pr99290()
+{
+  auto dir = __gnu_test::nonexistent_path();
+  auto source = dir/"source";
+  auto dest = dir/"dest";
+  create_directories(source/"emptydir");
+  create_directories(dest/"emptydir");
+  std::ofstream{source/"file"} << 'a';
+  std::ofstream{dest/"file"} << 'b';
+  // PR libstdc++/99290
+  // std::filesystem::copy does not always report errors for recursion
+  std::error_code ec;
+  copy(source, dest, ec);
+  VERIFY( ec == std::errc::file_exists );
+
+#if __cpp_exceptions
+  try {
+copy(source, dest);
+VERIFY( false );
+  } catch (const fs::filesystem_error& e) {
+VERIFY( e.code() == std::errc::file_exists );
+  }
+#endif
+
+  remove_all(dir);
+}
+
 int
 main()
 {
@@ -198,4 +226,5 @@ main()
   test03();
   

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Ilya Leoshkevich via Gcc-patches]

On Thu, 2022-04-28 at 13:27 +0200, Jakub Jelinek wrote:
> On Thu, Apr 28, 2022 at 01:03:26PM +0200, Ilya Leoshkevich wrote:
> > This is determined by default_elf_select_rtx_section ().  If we
> > don't
> > want to mix non-reloc and reloc constants, we need to define a
> > special
> > section there.
> > 
> > It seems to me, however, that this all would be made purely for the
> > sake of .LASANPC, which is quite special: it's local, but at the
> > same
> > time it might need to be comdat.  I don't think anything like this
> > can
> > appear from compiling C/C++ code.
> > 
> > Therefore I wonder if we could just drop it altogether like this?
> > 
> > @@ -1928,22 +1919,7 @@ asan_emit_stack_protection (rtx base, rtx
> > pbase,
> > unsigned int alignb,
> > ...
> > -  emit_move_insn (mem, expand_normal (build_fold_addr_expr
> > (decl)));
> > +  emit_move_insn (mem, expand_normal (build_fold_addr_expr
> > (current_function_decl)));
> > ...
> > 
> > That's what LLVM is already doing.  This will also solve the
> > alignment
> > problem I referred to earlier.
> 
> LLVM is doing a wrong thing here.  The global symbol can be
> overridden by
> a symbol in another shared library, that is definitely not what we
> want,
> because the ASAN record is for the particular implementation, not the
> other
> one which could be quite different.

I see; this must be relevant when the overriding library calls
the original one through dlsym (RTLD_NEXT).

> I think the right fix would be:
> --- gcc/varasm.cc.jj2022-03-07 15:00:17.255592497 +0100
> +++ gcc/varasm.cc   2022-04-28 13:22:44.463147066 +0200
> @@ -7326,6 +7326,9 @@ default_elf_select_rtx_section (machine_
> return get_named_section (NULL, ".data.rel.ro", 3);
>  }
>  
> +  if (reloc)
> +    return readonly_data_section;
> +
>    return mergeable_constant_section (mode, align, 0);
>  }
>  
> which matches what we do in categorize_decl_for_section:
>   else if (reloc & targetm.asm_out.reloc_rw_mask ())
>     ret = reloc == 1 ? SECCAT_DATA_REL_RO_LOCAL :
> SECCAT_DATA_REL_RO;
>   else if (reloc || flag_merge_constants < 2
> ...
>     /* C and C++ don't allow different variables to share the
> same
>    location.  -fmerge-all-constants allows even that (at the
>    expense of not conforming).  */
>     ret = SECCAT_RODATA;
>   else if (DECL_INITIAL (decl)
>    && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
>     ret = SECCAT_RODATA_MERGE_STR_INIT;
>   else
>     ret = SECCAT_RODATA_MERGE_CONST;
> i.e. if reloc is true, it goes into .data.rel.ro* for -fpic and
> .rodata
> for non-pic, and mergeable sections are only used if there are no
> relocations.

This doesn't resolve the problem, unfortunately, because
references to discarded comdat symbols are still kept in .rodata:

`.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_' referenced in
section `.rodata' of ../lib/libgtest.a(gtest-all.cc.o): defined in
discarded section
`.text._ZN7testing15AssertionResultlsIPKcEERS0_RKT_[_ZN7testing15Assert
ionResultlsIPKcEERS0_RKT_]' of ../lib/libgtest.a(gtest-all.cc.o)

(That's from building zlib-ng with ASan and your patch on s390).

So I was rather thinking about adding a reloc parameter to
mergeable_constant_section () and slightly changing the section
name when it's nonzero, e.g. from .cst to .cstrel.

> Anyway, I'd feel much safer to change it only in GCC 13, at least
> initially.

That's fine with me.

> Or are some linkers (say lld or mold, fod ld.bfd I'm pretty sure it
> doesn't,
> for gold no idea but unlikely) able to merge even constants with
> relocations against them?

I'm not sure, but putting constants with relocations into a separate
mergeable section shouldn't hurt too much.  And if such a linker is
implemented some day, there would be no need to tweak gcc.

Re: [PATCH] cgraph: Don't verify semantic_interposition flag for aliases [PR105399]

[Jan Hubicka via Gcc-patches]

> On Thu, Apr 28, 2022 at 01:54:51PM +0200, Jan Hubicka wrote:
> > > --- gcc/cgraph.cc.jj  2022-04-20 09:24:12.194579146 +0200
> > > +++ gcc/cgraph.cc 2022-04-27 11:53:52.102173154 +0200
> > > @@ -3488,7 +3488,9 @@ cgraph_node::verify_node (void)
> > >"returns a pointer");
> > >error_found = true;
> > >  }
> > > -  if (definition && externally_visible
> > > +  if (definition
> > > +  && externally_visible
> > > +  && (!alias || thunk || !in_lto_p)
> > 
> > The alias check seems OK to me.
> > Why we need thunk?  Here thunk may eventually gain a gimple body and we
> > will be interested in its opt_for_fn flags.  So if we do not set
> > DECL_FUNCTION_SPECIFIC_OPTIMIZATION we may get unexpected surprises
> > (such as blocked inlining).
> 
> I've added || thunk because free_lang_data sets 
> DECL_FUNCTION_SPECIFIC_OPTIMIZATION
> for thunks, the guarding condition is:
> if (gimple_has_body_p (decl) || (node && node->thunk))
> I wasn't sure if node->alias and node->thunk can be both set or not.
> If they can't, I can take it out.

Aha, I misread is as !alias || !thunk.
But node can not be both alias and thunk, so I would leave it out.

Honza

> 
>   Jakub
> 

Re: [PATCH] cgraph: Don't verify semantic_interposition flag for aliases [PR105399]

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 28, 2022 at 01:54:51PM +0200, Jan Hubicka wrote:
> > --- gcc/cgraph.cc.jj2022-04-20 09:24:12.194579146 +0200
> > +++ gcc/cgraph.cc   2022-04-27 11:53:52.102173154 +0200
> > @@ -3488,7 +3488,9 @@ cgraph_node::verify_node (void)
> >  "returns a pointer");
> >error_found = true;
> >  }
> > -  if (definition && externally_visible
> > +  if (definition
> > +  && externally_visible
> > +  && (!alias || thunk || !in_lto_p)
> 
> The alias check seems OK to me.
> Why we need thunk?  Here thunk may eventually gain a gimple body and we
> will be interested in its opt_for_fn flags.  So if we do not set
> DECL_FUNCTION_SPECIFIC_OPTIMIZATION we may get unexpected surprises
> (such as blocked inlining).

I've added || thunk because free_lang_data sets 
DECL_FUNCTION_SPECIFIC_OPTIMIZATION
for thunks, the guarding condition is:
if (gimple_has_body_p (decl) || (node && node->thunk))
I wasn't sure if node->alias and node->thunk can be both set or not.
If they can't, I can take it out.

Jakub

Re: [PATCH] cgraph: Don't verify semantic_interposition flag for aliases [PR105399]

[Jan Hubicka via Gcc-patches]

Hello,
> Hi!
> 
> The following testcase ICEs, because the ctors during cc1plus all have
> !opt_for_fn (decl, flag_semantic_interposition) - they have NULL
> DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) and optimization_default_node
> is for -Ofast and so has flag_semantic_interposition cleared.
> During free lang data, we set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
> for the ctor which has body (or for thunks), but don't touch it for
> aliases.

Hmm, this is bit interesting.  We definitly want to preserve original
semantic interposition behaviour of aliases and it works here since we
move the flag to symbol table, but it is bit of accident (I added the
flag because variables does not have their ovn
DECL_VAR_SPECIFIC_OPTIMIZATION so it needs to be part of symbol table).

Looking for current uses of opt_for_fn we seems to care about properties
of the actual function bodies, not aliases, but it feels a bit fragile.
Next stage1 I should make opt_for_fn to bomb on all aliases so we know
we are not using it wrongly.

> During lto1 optimization_default_node reflects the lto1 flags which
> are -O2 rather than -Ofast and so has flag_semantic_interposition
> set, for the ctor which has body that makes no difference, but as the
> alias doesn't still have DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) set,
> we now trigger this verification check.
> 
> The following patch just doesn't verify it for aliases during lto1.
> Another possibility would be to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
> during free lang data even for aliases.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2022-04-28  Jakub Jelinek  
> 
>   PR lto/105399
>   * cgraph.cc (cgraph_node::verify_node): Don't verify
>   semantic_interposition flag against
>   opt_for_fn (decl, flag_semantic_interposition) for aliases in lto1.
> 
>   * g++.dg/lto/pr105399_0.C: New test.
> 
> --- gcc/cgraph.cc.jj  2022-04-20 09:24:12.194579146 +0200
> +++ gcc/cgraph.cc 2022-04-27 11:53:52.102173154 +0200
> @@ -3488,7 +3488,9 @@ cgraph_node::verify_node (void)
>"returns a pointer");
>error_found = true;
>  }
> -  if (definition && externally_visible
> +  if (definition
> +  && externally_visible
> +  && (!alias || thunk || !in_lto_p)

The alias check seems OK to me.
Why we need thunk?  Here thunk may eventually gain a gimple body and we
will be interested in its opt_for_fn flags.  So if we do not set
DECL_FUNCTION_SPECIFIC_OPTIMIZATION we may get unexpected surprises
(such as blocked inlining).
>&& semantic_interposition
>!= opt_for_fn (decl, flag_semantic_interposition))
>  {
> --- gcc/testsuite/g++.dg/lto/pr105399_0.C.jj  2022-04-27 11:54:25.659703199 
> +0200
> +++ gcc/testsuite/g++.dg/lto/pr105399_0.C 2022-04-27 11:48:31.387664565 
> +0200
> @@ -0,0 +1,9 @@
> +// PR lto/105399
> +// { dg-lto-do link }
> +// { dg-lto-options { { -fPIC -flto -Ofast } } }
> +// { dg-require-effective-target shared }
> +// { dg-require-effective-target fpic }
> +// { dg-extra-ld-options "-shared -O2" }
> +
> +struct S { S (); };
> +S::S () {}
> 
>   Jakub
> 

Re: [PATCH] c++, coroutines: Avoid expanding within templates [PR103868]

[Jason Merrill via Gcc-patches]

On 4/28/22 04:24, Iain Sandoe wrote:

Hi Jason,


On 20 Apr 2022, at 04:45, Jason Merrill  wrote:

On 4/18/22 15:49, Eric Gallager via Gcc-patches wrote:

On Mon, Apr 18, 2022 at 10:01 AM Iain Sandoe via Gcc-patches
 wrote:


From: Nathan Sidwell 

This is a forward-port of a patch by Nathan (against 10.x) which fixes an open
PR.

We are ICEing because we ended up tsubst_copying something that had already
been tsubst, leading to an assert failure (mostly such repeated tsubsting is
harmless).


I wouldn't say "mostly".  It should always be avoided, it frequently causes 
problems.  Pretty much any time there's a class prvalue.


We had a non-dependent co_await in a non-dependent-type template fn, so we
processed it at definition time, and then reprocessed at instantiation time.
We fix this here by deferring substitution while processing templates.

Additional observations (for a better future fix, in the GCC13 timescale):

Exprs only have dependent type if at least one operand is dependent which was
what the current code was intending to do.  Coroutines have the additional
wrinkle, that the current fn's type is an implicit operand.

So, if the coroutine function's type is not dependent, and the operand is not
dependent, we should determine the type of the co_await expression using the
DEPENDENT_EXPR wrapper machinery.  That allows us to determine the
subexpression type, but leave its operand unchanged and then instantiate it
later.


Sure, like what build_x_binary_op and the like do.


Tested on x86_64-darwin (it does also fix the original testcase, but that is
far too time-consuming for the testsuite).


The compiler change seems fine as a temporary workaround.  Is it not feasible 
to write a new short testcase that reproduces the problem, now that you 
understand it?


With the fix it was possible to write a reduction test that fails for the bad 
compiler and passes for the fixed without other issues.  Threw that at cvice 
and we have now a 149 line test which is quick to run.

OK now?


Let's add a FIXME note to the comment about your GCC13 plan.  OK with 
that change.



thanks
Iain

From: Nathan Sidwell 
Date: Sun, 3 Apr 2022 11:35:03 +0100
Subject: [PATCH] c++, coroutines: Avoid expanding within templates [PR103868]

This is a forward-port of a patch by Nathan (against 10.x) which fixes an open
PR.

We are ICEing because we ended up tsubst_copying something that had already
been tsubst, leading to an assert failure (mostly such repeated tsubsting is
harmless).

We had a non-dependent co_await in a non-dependent-type template fn, so we
processed it at definition time, and then reprocessed at instantiation time.
We fix this here by deferring substitution while processing templates.

Additional observations (for a better future fix, in the GCC13 timescale):

Exprs only have dependent type if at least one operand is dependent which was
what the current code was intending to do.  Coroutines have the additional
wrinkle, that the current fn's type is an implicit operand.

So, if the coroutine function's type is not dependent, and the operand is not
dependent, we should determine the type of the co_await expression using the
DEPENDENT_EXPR wrapper machinery.  That allows us to determine the
subexpression type, but leave its operand unchanged and then instantiate it
later.

PR c++/103868

gcc/cp/ChangeLog:

* coroutines.cc (finish_co_await_expr): Do not process non-dependent
coroutine expressions at template definition time.
(finish_co_yield_expr): Likewise.
(finish_co_return_stmt): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr103868.C: New test.

Co-Authored-by: Iain Sandoe 
---
  gcc/cp/coroutines.cc   |  18 +--
  gcc/testsuite/g++.dg/coroutines/pr103868.C | 150 +
  2 files changed, 156 insertions(+), 12 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/coroutines/pr103868.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index cdf6503c4d3..a9ce6e050dd 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1148,10 +1148,8 @@ finish_co_await_expr (location_t kw, tree expr)
   extraneous warnings during substitution.  */
suppress_warning (current_function_decl, OPT_Wreturn_type);
  
-  /* If we don't know the promise type, we can't proceed, build the

- co_await with the expression unchanged.  */
-  tree functype = TREE_TYPE (current_function_decl);
-  if (dependent_type_p (functype) || type_dependent_expression_p (expr))
+  /* Defer processing when we have dependent types.  */
+  if (processing_template_decl)
  {
tree aw_expr = build5_loc (kw, CO_AWAIT_EXPR, unknown_type_node, expr,
 NULL_TREE, NULL_TREE, NULL_TREE,
@@ -1222,10 +1220,8 @@ finish_co_yield_expr (location_t kw, tree expr)
   extraneous warnings during substitution.  */
suppress_warning (current_function_decl, OPT_Wreturn_type);
  
-  /* If we don't know the 

Re: [PATCH] c++, coroutines: Make sure our temporaries are in a bind expr [PR105287]

[Jason Merrill via Gcc-patches]

On 4/28/22 04:28, Iain Sandoe wrote:

Hi Jason,


On 20 Apr 2022, at 03:14, Jason Merrill  wrote:

On 4/18/22 10:02, Iain Sandoe wrote:

There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral).  The
intent was that unnamed temporaries should not be 'promoted' to coroutine
frame entries.  However there was a thinko and these were not actually ever
added to the bind expressions being generated for the expanded awaits.  This
meant that they were showing in the global namspace, leading to an empty
DECL_CONTEXT and the ICE reported.
tested on x86_64-darwin, OK for mainline? / Backports? (when?)
thanks,
Iain
Signed-off-by: Iain Sandoe 
PR c++/105287
gcc/cp/ChangeLog:
* coroutines.cc (maybe_promote_temps): Ensure generated temporaries
are added to the bind expr.
(add_var_to_bind): Fix local var naming to use portable punctuation.
(register_local_var_uses): Do not add synthetic names to unnamed
temporaries.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr105287.C: New test.
---
  gcc/cp/coroutines.cc   | 17 
  gcc/testsuite/g++.dg/coroutines/pr105287.C | 48 ++
  2 files changed, 56 insertions(+), 9 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/coroutines/pr105287.C
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index a9ce6e050dd..dcc2284171b 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3103,7 +3103,7 @@ maybe_promote_temps (tree *stmt, void *d)
 If the initializer is a conditional expression, we need to collect
 and declare any promoted variables nested within it.  DTORs for such
 variables must be run conditionally too.  */
-  if (t->var && DECL_NAME (t->var))
+  if (t->var)
{
  tree var = t->var;
  DECL_CHAIN (var) = vlist;
@@ -3304,7 +3304,7 @@ add_var_to_bind (tree& bind, tree var_type,
tree b_vars = BIND_EXPR_VARS (bind);
/* Build a variable to hold the condition, this will be included in the
   frame as a local var.  */
-  char *nam = xasprintf ("%s.%d", nam_root, nam_vers);
+  char *nam = xasprintf ("`__%s_%d", nam_root, nam_vers);


` is portable?


nope, it’s a typo - apparently accepted by GAS and Darwin’s assembler tho…
thanks for catching that.


tree newvar = build_lang_decl (VAR_DECL, get_identifier (nam), var_type);
free (nam);
DECL_CHAIN (newvar) = b_vars;
@@ -3949,7 +3949,7 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
 scopes with identically named locals and still be able to
 identify them in the coroutine frame.  */
  tree lvname = DECL_NAME (lvar);
- char *buf;
+ char *buf = NULL;
  /* The outermost bind scope contains the artificial variables that
 we inject to implement the coro state machine.  We want to be able
@@ -3959,14 +3959,13 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
  else if (lvname != NULL_TREE)
buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
 lvd->nest_depth, lvd->bind_indx);
- else
-   buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
-lvd->bind_indx);
  /* TODO: Figure out if we should build a local type that has any
 excess alignment or size from the original decl.  */
- local_var.field_id
-   = coro_make_frame_entry (lvd->field_list, buf, lvtype, lvd->loc);
- free (buf);
+ if (buf) {


Brace should be on the next line.


that was careless, too much rushing, fixed as below,
OK now?


OK.


-

[PATCH] c++, coroutines: Make sure our temporaries are in a bind expr
  [PR105287]

There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral).  The
intent was that unnamed temporaries should not be 'promoted' to coroutine
frame entries.  However there was a thinko and these were not actually ever
added to the bind expressions being generated for the expanded awaits.  This
meant that they were showing in the global namspace, leading to an empty
DECL_CONTEXT and the ICE reported.

Signed-off-by: Iain Sandoe 

PR c++/105287

gcc/cp/ChangeLog:

* coroutines.cc (maybe_promote_temps): Ensure generated temporaries
are added to the bind expr.
(add_var_to_bind): Fix local var naming to use portable punctuation.
(register_local_var_uses): Do not add synthetic names to unnamed
temporaries.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105287.C: New test.
---
  gcc/cp/coroutines.cc   | 18 
  gcc/testsuite/g++.dg/coroutines/pr105287.C | 48 ++
  2 files changed, 57 insertions(+), 9 deletions(-)
  create mode 100644 

Re: [PATCH] ipa: Release body of clone_of when removing its last clone (PR 100413)

[Jan Hubicka via Gcc-patches]

> Hi,
> 
> In the PR, the verifier complains that we did not manage to remove the
> body of a node and it is right.  The node is kept for materialization
> of two clones but after one is materialized, the other one is removed
> as unneeded (as a part of delete_unreachable_blocks_update_callgraph).
> The problem is that the node removal does not check for this situation
> and can leave the clone_of node there with a body attached to it even
> though there is no use for it any more.  This patch does checks for it
> and handles the situation in a simlar way that
> cgraph_node::materialize_clone does it, except that it also has to be
> careful that the removed node itself does not have any clones, which
> would still need the clone_of's body.  Failing to do that results in a
> bootstrap failure.
> 
> Bootstrapped and tested and LTO-bootstrapped on x86_64-linux.
> 
> OK for master and GCC 11?  Or should I perhaps wait for GCC 12 to
> branch and only backport to 12.2 after some time on GCC 13 master?
> 
> Thanks,
> 
> Martin
> 
> 
> gcc/ChangeLog:
> 
> 2022-04-27  Martin Jambor  
> 
>   PR ipa/100413
>   * cgraph.cc (cgraph_node::remove): Release body of the node this
>   is clone_of if appropriate.
> 
> gcc/testsuite/ChangeLog:
> 
> 2022-04-27  Martin Jambor  
> 
>   PR ipa/100413
>   * g++.dg/ipa/pr100413.C: New test.

OK, thanks!
I think it should be good for gcc 12 as well.

Honza

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 28, 2022 at 01:03:26PM +0200, Ilya Leoshkevich wrote:
> This is determined by default_elf_select_rtx_section ().  If we don't
> want to mix non-reloc and reloc constants, we need to define a special
> section there.
> 
> It seems to me, however, that this all would be made purely for the
> sake of .LASANPC, which is quite special: it's local, but at the same
> time it might need to be comdat.  I don't think anything like this can
> appear from compiling C/C++ code.
> 
> Therefore I wonder if we could just drop it altogether like this?
> 
> @@ -1928,22 +1919,7 @@ asan_emit_stack_protection (rtx base, rtx pbase,
> unsigned int alignb,
> ...
> -  emit_move_insn (mem, expand_normal (build_fold_addr_expr (decl)));
> +  emit_move_insn (mem, expand_normal (build_fold_addr_expr
> (current_function_decl)));
> ...
> 
> That's what LLVM is already doing.  This will also solve the alignment
> problem I referred to earlier.

LLVM is doing a wrong thing here.  The global symbol can be overridden by
a symbol in another shared library, that is definitely not what we want,
because the ASAN record is for the particular implementation, not the other
one which could be quite different.

I think the right fix would be:
--- gcc/varasm.cc.jj2022-03-07 15:00:17.255592497 +0100
+++ gcc/varasm.cc   2022-04-28 13:22:44.463147066 +0200
@@ -7326,6 +7326,9 @@ default_elf_select_rtx_section (machine_
return get_named_section (NULL, ".data.rel.ro", 3);
 }
 
+  if (reloc)
+return readonly_data_section;
+
   return mergeable_constant_section (mode, align, 0);
 }
 
which matches what we do in categorize_decl_for_section:
  else if (reloc & targetm.asm_out.reloc_rw_mask ())
ret = reloc == 1 ? SECCAT_DATA_REL_RO_LOCAL : SECCAT_DATA_REL_RO;
  else if (reloc || flag_merge_constants < 2
...
/* C and C++ don't allow different variables to share the same
   location.  -fmerge-all-constants allows even that (at the
   expense of not conforming).  */
ret = SECCAT_RODATA;
  else if (DECL_INITIAL (decl)
   && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
ret = SECCAT_RODATA_MERGE_STR_INIT;
  else
ret = SECCAT_RODATA_MERGE_CONST;
i.e. if reloc is true, it goes into .data.rel.ro* for -fpic and .rodata
for non-pic, and mergeable sections are only used if there are no
relocations.

Anyway, I'd feel much safer to change it only in GCC 13, at least initially.
Or are some linkers (say lld or mold, fod ld.bfd I'm pretty sure it doesn't,
for gold no idea but unlikely) able to merge even constants with
relocations against them?

Jakub

[committed] d: Merge upstream dmd 313d28b3d, druntime e361d200.

[Iain Buclaw via Gcc-patches]

Hi,

This patches merges the D front-end with upstream dmd 313d28b3d, and the
D runtime library with upstream druntime e361d200.

D front-end changes:

- Import latest bug fixes from the 2.100 release branch.
- Fix signatures of extern C++ functions that have size_t
  parameters.

Bootstrapped and regression tested on x86_64-linux-gnu, and
i686-apple-darwin14.  Committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 313d28b3d.
* d-port.cc (Port::memicmp): Use d_size_t instead of size_t.
(Port::valcpy): Likewise.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime e361d200.
---
 gcc/d/d-port.cc   |  8 +-
 gcc/d/dmd/MERGE   |  2 +-
 gcc/d/dmd/cparse.d| 95 +++
 gcc/d/dmd/dscope.d|  2 +
 gcc/d/dmd/expression.h|  6 +-
 gcc/d/dmd/expressionsem.d | 29 --
 gcc/d/dmd/root/port.h |  5 +-
 .../gdc.test/compilable/revert_dip1000.d  |  7 ++
 libphobos/libdruntime/MERGE   |  2 +-
 9 files changed, 121 insertions(+), 35 deletions(-)
 create mode 100644 gcc/testsuite/gdc.test/compilable/revert_dip1000.d

diff --git a/gcc/d/d-port.cc b/gcc/d/d-port.cc
index a0e06b37683..a908cc8dbb0 100644
--- a/gcc/d/d-port.cc
+++ b/gcc/d/d-port.cc
@@ -31,11 +31,11 @@ along with GCC; see the file COPYING3.  If not see
 /* Compare the first N bytes of S1 and S2 without regard to the case.  */
 
 int
-Port::memicmp (const char *s1, const char *s2, size_t n)
+Port::memicmp (const char *s1, const char *s2, d_size_t n)
 {
   int result = 0;
 
-  for (size_t i = 0; i < n; i++)
+  for (d_size_t i = 0; i < n; i++)
 {
   char c1 = s1[i];
   char c2 = s2[i];
@@ -143,9 +143,9 @@ Port::readlongBE (const void *buffer)
 /* Write an SZ-byte sized VALUE to BUFFER, ignoring endian-ness.  */
 
 void
-Port::valcpy (void *buffer, uint64_t value, size_t sz)
+Port::valcpy (void *buffer, uint64_t value, d_size_t sz)
 {
-  gcc_assert (((size_t) buffer) % sz == 0);
+  gcc_assert (((d_size_t) buffer) % sz == 0);
 
   switch (sz)
 {
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index 2bc9b95b5e2..d18119193d4 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-eb7bee331a13026eeb4dcbf9d43d5d4e744a4d26
+313d28b3db7523e67880ae3baf8ef28ce9abe9bd
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/cparse.d b/gcc/d/dmd/cparse.d
index 53bf26ec927..2b2046f3da3 100644
--- a/gcc/d/dmd/cparse.d
+++ b/gcc/d/dmd/cparse.d
@@ -213,16 +213,12 @@ final class CParser(AST) : Parser!AST
 goto Lexp;
 
 case TOK.leftParenthesis:
-{
-/* If tokens look like a function call, assume it is one,
- * As any type-name won't be resolved until semantic, this
- * could be rewritten later.
- */
-auto tk = 
-if (isFunctionCall(tk))
-goto Lexp;
-goto default;
-}
+if (auto pt = lookupTypedef(token.ident))
+{
+if (*pt)
+goto Ldeclaration;
+}
+goto Lexp;  // function call
 
 default:
 {
@@ -1626,10 +1622,21 @@ final class CParser(AST) : Parser!AST
  */
 if (token.value == TOK.semicolon)
 {
-nextToken();
 if (!tspec)
+{
+nextToken();
 return; // accept empty declaration as an extension
+}
+
+if (auto ti = tspec.isTypeIdentifier())
+{
+// C11 6.7.2-2
+error("type-specifier missing for declaration of `%s`", 
ti.ident.toChars());
+nextToken();
+return;
+}
 
+nextToken();
 auto tt = tspec.isTypeTag();
 if (!tt ||
 !tt.id && (tt.tok == TOK.struct_ || tt.tok == TOK.union_))
@@ -1661,6 +1668,22 @@ final class CParser(AST) : Parser!AST
 specifier.mod &= ~MOD.xnone;  // 'used' it
 }
 
+void scanPastSemicolon()
+{
+while (token.value != TOK.semicolon && token.value != 
TOK.endOfFile)
+nextToken();
+nextToken();
+}
+
+if (token.value == TOK.assign && tspec && tspec.isTypeIdentifier())
+{
+/* C11 6.7.2-2
+ * Special check for `const b = 1;` because some compilers allow it
+ */
+error("type-specifier omitted for declaration of `%s`", 
tspec.isTypeIdentifier().ident.toChars());
+   

Re: [PATCH] Honor COMDAT for mergeable constant sections

[Ilya Leoshkevich via Gcc-patches]

On Wed, 2022-04-27 at 14:46 +0200, Jakub Jelinek wrote:
> On Wed, Apr 27, 2022 at 02:23:00PM +0200, Jakub Jelinek wrote:
> > On Wed, Apr 27, 2022 at 11:59:49AM +0200, Ilya Leoshkevich wrote:
> > > I get a .LASANPC reloc there in the first place because of
> > > https://patchwork.ozlabs.org/project/gcc/patch/20190702085154.26981-1-...@linux.ibm.com/
> > > but of course it may happen for other reasons as well.
> > 
> > In that case I don't see any benefit to put that into a mergeable
> > section.
> > Why does that happen?
> 
> Because, when a mergeable section doesn't contain any relocations, I
> don't
> see any point in making it comdat.  Because mergeable sections
> themselves
> are garbage collected, if some constant isn't referenced at all, it
> isn't
> emitted, or if referenced, multiple copies of the constant are merged
> (or
> for mergeable strings even string tail merging is performed).
> 
> Jakub
> 

This is determined by default_elf_select_rtx_section ().  If we don't
want to mix non-reloc and reloc constants, we need to define a special
section there.

It seems to me, however, that this all would be made purely for the
sake of .LASANPC, which is quite special: it's local, but at the same
time it might need to be comdat.  I don't think anything like this can
appear from compiling C/C++ code.

Therefore I wonder if we could just drop it altogether like this?

@@ -1928,22 +1919,7 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
...
-  emit_move_insn (mem, expand_normal (build_fold_addr_expr (decl)));
+  emit_move_insn (mem, expand_normal (build_fold_addr_expr
(current_function_decl)));
...

That's what LLVM is already doing.  This will also solve the alignment
problem I referred to earlier.

Re: Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

[Richard Biener via Gcc-patches]

On Thu, 28 Apr 2022, Jakub Jelinek wrote:

> On Thu, Apr 28, 2022 at 10:39:39AM +0200, Uros Bizjak wrote:
> > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > > >
> > > > 2022-04-22  Jakub Jelinek  
> > > >
> > > >   PR target/105331
> > > >   * config/i386/i386.cc (ix86_gimplify_va_arg): Mark va_arg_tmp
> > > >   temporary TREE_ADDRESSABLE before trying to gimplify ADDR_EXPR
> > > >   of it.
> > > >
> > > >   * gcc.dg/pr105331.c: New test.
> > 
> > Sorry, I have no idea if this patch is correct or not.
> 
> Richard or Jeff, could you please review it instead?

OK.

Thanks,
Richard.

Re: Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 28, 2022 at 10:39:39AM +0200, Uros Bizjak wrote:
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > >
> > > 2022-04-22  Jakub Jelinek  
> > >
> > >   PR target/105331
> > >   * config/i386/i386.cc (ix86_gimplify_va_arg): Mark va_arg_tmp
> > >   temporary TREE_ADDRESSABLE before trying to gimplify ADDR_EXPR
> > >   of it.
> > >
> > >   * gcc.dg/pr105331.c: New test.
> 
> Sorry, I have no idea if this patch is correct or not.

Richard or Jeff, could you please review it instead?

Thanks.

Jakub

Re: [PATCH] doc: Remove misleading text about multilibs for IEEE long double

[Jakub Jelinek via Gcc-patches]

On Thu, Apr 28, 2022 at 10:46:17AM +0100, Jonathan Wakely via Gcc-patches wrote:
> IIUC this text is not true (maybe it was back in 2018?)
> 
> OK for trunk?
> 
> Which branches should it be on too, all of them?
> 
> -- >8 --
> 
> The choice of ieee or ibm long double format is orthogonal to multilibs,
> as the two sets of symbols co-exist and don't need a separate multilib.
> 
> gcc/ChangeLog:
> 
>   * doc/install.texi (Configuration): Remove misleading text
>   around LE PowerPC Linux multilibs.

Ok.

Jakub

[PATCH 12/12] arm: implement bti injection

[Andrea Corallo via Gcc-patches]

Hi all,

this patch enables Branch Target Identification Armv8.1-M Mechanism
[1].

This is achieved by using the bti pass made common with Aarch64.

The pass iterates through the instructions and adds the necessary BTI
instructions at the beginning of every function and at every landing
pads targeted by indirect jumps.

Best Regards

  Andrea

[1]


gcc/ChangeLog

* config.gcc (arm*-*-*): Add 'aarch-bti-insert.o' object.
* config/arm/arm-protos.h: Update.
* config/arm/arm.cc (aarch_bti_enabled, aarch_bti_j_insn_p)
(aarch_pac_insn_p, aarch_gen_bti_c, aarch_gen_bti_j): New
functions.
* config/arm/arm.md (bti_nop): New insn.
* config/arm/t-arm (PASSES_EXTRA): Add 'arm-passes.def'.
(aarch-bti-insert.o): New target.
* config/arm/unspecs.md (UNSPEC_BTI_NOP): New unspec.

gcc/testsuite/ChangeLog

* gcc.target/arm/bti-1.c: New testcase.
* gcc.target/arm/bti-2.c: Likewise.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 2021bdf9d2f..004e1dfa8d8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -353,7 +353,7 @@ arc*-*-*)
;;
 arm*-*-*)
cpu_type=arm
-   extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o"
+   extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o 
aarch-bti-insert.o"
extra_headers="mmintrin.h arm_neon.h arm_acle.h arm_fp16.h arm_cmse.h 
arm_bf16.h arm_mve_types.h arm_mve.h arm_cde.h"
target_type_format_char='%'
c_target_objs="arm-c.o"
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index cff7ff1da2a..da23e0a4735 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -24,6 +24,8 @@
 
 #include "sbitmap.h"
 
+rtl_opt_pass *make_pass_insert_bti (gcc::context *ctxt);
+
 extern enum unwind_info_type arm_except_unwind_info (struct gcc_options *);
 extern int use_return_insn (int, rtx);
 extern bool use_simple_return_p (void);
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index c91dae292c8..a2b720a6660 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -23361,11 +23361,6 @@ output_probe_stack_range (rtx reg1, rtx reg2)
   return "";
 }
 
-static bool  aarch_bti_enabled ()
-{
-  return false;
-}
-
 /* Generate the prologue instructions for entry into an ARM or Thumb-2
function.  */
 void
@@ -32981,6 +32976,56 @@ arm_current_function_pac_enabled_p (void)
&& !crtl->is_leaf);
 }
 
+/* Return TRUE if Branch Target Identification Mechanism is enabled.  */
+bool
+aarch_bti_enabled (void)
+{
+  return aarch_enable_bti == 1;
+}
+
+/* Check if INSN is a BTI J insn.  */
+bool
+aarch_bti_j_insn_p (rtx_insn *insn)
+{
+  if (!insn || !INSN_P (insn))
+return false;
+
+  rtx pat = PATTERN (insn);
+  return GET_CODE (pat) == UNSPEC_VOLATILE && XINT (pat, 1) == UNSPEC_BTI_NOP;
+}
+
+/* Check if X (or any sub-rtx of X) is a PACIASP/PACIBSP instruction.  */
+bool
+aarch_pac_insn_p (rtx x)
+{
+  if (!x || !INSN_P (x))
+return false;
+
+  rtx pat = PATTERN (x);
+
+  if (GET_CODE (pat) == SET)
+{
+  rtx tmp = XEXP (pat, 1);
+  if (tmp
+ && GET_CODE (tmp) == UNSPEC
+ && (XINT (tmp, 1) == UNSPEC_PAC_NOP
+ || XINT (tmp, 1) == UNSPEC_PACBTI_NOP))
+   return true;
+}
+
+  return false;
+}
+
+rtx aarch_gen_bti_c (void)
+{
+  return gen_bti_nop ();
+}
+
+rtx aarch_gen_bti_j (void)
+{
+  return gen_bti_nop ();
+}
+
 /* Implement TARGET_SCHED_CAN_SPECULATE_INSN.  Return true if INSN can be
scheduled for speculative execution.  Reject the long-running division
and square-root instructions.  */
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index b480f76a876..2221bc68f35 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -12913,6 +12913,12 @@
   "aut\t%|ip, %|lr, %|sp"
   [(set_attr "length" "2")])
 
+(define_insn "bti_nop"
+  [(unspec_volatile [(const_int 0)] UNSPEC_BTI_NOP)]
+  "TARGET_THUMB2"
+  "bti"
+  [(set_attr "type" "mov_reg")])
+
 ;; Vector bits common to IWMMXT, Neon and MVE
 (include "vec-common.md")
 ;; Load the Intel Wireless Multimedia Extension patterns
diff --git a/gcc/config/arm/t-arm b/gcc/config/arm/t-arm
index 041cc6ec045..683342cb528 100644
--- a/gcc/config/arm/t-arm
+++ b/gcc/config/arm/t-arm
@@ -175,3 +175,13 @@ arm-d.o: $(srcdir)/config/arm/arm-d.cc
 arm-common.o: arm-cpu-cdata.h
 
 driver-arm.o: arm-native.h
+
+PASSES_EXTRA += $(srcdir)/config/arm/arm-passes.def
+
+aarch-bti-insert.o: $(srcdir)/config/arm/aarch-bti-insert.cc \
+$(CONFIG_H) $(SYSTEM_H) $(TM_H) $(REGS_H) insn-config.h $(RTL_BASE_H) \
+dominance.h cfg.h cfganal.h $(BASIC_BLOCK_H) $(INSN_ATTR_H) $(RECOG_H) \
+output.h hash-map.h $(DF_H) $(OBSTACK_H) $(TARGET_H) $(RTL_H) \
+$(CONTEXT_H) $(TREE_PASS_H) regrename.h
+   $(COMPILER) -c 

[PATCH 11/12] aarch64: Make bti pass generic so it can be used by the arm backend

[Andrea Corallo via Gcc-patches]

Hi all,

this patch splits and restructures the aarch64 bti pass code in order
to have it usable by the arm backend as well.  These changes have no
functional impact.

Best Regards

  Andrea

gcc/Changelog

* config.gcc (aarch64*-*-*): Rename 'aarch64-bti-insert.o' into
'aarch-bti-insert.o'.
* config/aarch64/aarch64-protos.h: Remove 'aarch64_bti_enabled'
proto.
* config/aarch64/aarch64.cc (aarch_bti_enabled): Rename.
(aarch_bti_j_insn_p, aarch_pac_insn_p): New functions.
(aarch64_output_mi_thunk)
(aarch64_print_patchable_function_entry)
(aarch64_file_end_indicate_exec_stack): Update renamed function
calls to renamed functions.
* config/aarch64/t-aarch64 (aarch-bti-insert.o): Update target.
* config/arm/aarch-bti-insert.cc: New file including and
generalizing code from aarch64-bti-insert.cc.
* config/arm/aarch-common-protos.h: Update.
* config/arm/arm-passes.def: New file.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7b58e1314ff..2021bdf9d2f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -329,7 +329,7 @@ aarch64*-*-*)
c_target_objs="aarch64-c.o"
cxx_target_objs="aarch64-c.o"
d_target_objs="aarch64-d.o"
-   extra_objs="aarch64-builtins.o aarch-common.o aarch64-sve-builtins.o 
aarch64-sve-builtins-shapes.o aarch64-sve-builtins-base.o 
aarch64-sve-builtins-sve2.o cortex-a57-fma-steering.o aarch64-speculation.o 
falkor-tag-collision-avoidance.o aarch64-bti-insert.o aarch64-cc-fusion.o"
+   extra_objs="aarch64-builtins.o aarch-common.o aarch64-sve-builtins.o 
aarch64-sve-builtins-shapes.o aarch64-sve-builtins-base.o 
aarch64-sve-builtins-sve2.o cortex-a57-fma-steering.o aarch64-speculation.o 
falkor-tag-collision-avoidance.o aarch-bti-insert.o aarch64-cc-fusion.o"
target_gtfiles="\$(srcdir)/config/aarch64/aarch64-builtins.cc 
\$(srcdir)/config/aarch64/aarch64-sve-builtins.h 
\$(srcdir)/config/aarch64/aarch64-sve-builtins.cc"
target_has_targetm_common=yes
;;
diff --git a/gcc/config/aarch64/aarch64-c.cc b/gcc/config/aarch64/aarch64-c.cc
index b0c5a4fd6b6..a9aad3abdc2 100644
--- a/gcc/config/aarch64/aarch64-c.cc
+++ b/gcc/config/aarch64/aarch64-c.cc
@@ -179,7 +179,7 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
   aarch64_def_or_undef (TARGET_RNG, "__ARM_FEATURE_RNG", pfile);
   aarch64_def_or_undef (TARGET_MEMTAG, "__ARM_FEATURE_MEMORY_TAGGING", pfile);
 
-  aarch64_def_or_undef (aarch64_bti_enabled (),
+  aarch64_def_or_undef (aarch_bti_enabled (),
"__ARM_FEATURE_BTI_DEFAULT", pfile);
 
   cpp_undef (pfile, "__ARM_FEATURE_PAC_DEFAULT");
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index fe2180e95ea..9fdf7f9cc9c 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -891,7 +891,6 @@ void aarch64_register_pragmas (void);
 void aarch64_relayout_simd_types (void);
 void aarch64_reset_previous_fndecl (void);
 bool aarch64_return_address_signing_enabled (void);
-bool aarch64_bti_enabled (void);
 void aarch64_save_restore_target_globals (tree);
 void aarch64_addti_scratch_regs (rtx, rtx, rtx *,
 rtx *, rtx *,
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index eec743024c1..2f67f3872f6 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -8534,11 +8534,61 @@ aarch64_return_address_signing_enabled (void)
 
 /* Return TRUE if Branch Target Identification Mechanism is enabled.  */
 bool
-aarch64_bti_enabled (void)
+aarch_bti_enabled (void)
 {
   return (aarch_enable_bti == 1);
 }
 
+/* Check if INSN is a BTI J insn.  */
+bool
+aarch_bti_j_insn_p (rtx_insn *insn)
+{
+  if (!insn || !INSN_P (insn))
+return false;
+
+  rtx pat = PATTERN (insn);
+  return GET_CODE (pat) == UNSPEC_VOLATILE && XINT (pat, 1) == UNSPECV_BTI_J;
+}
+
+/* Check if X (or any sub-rtx of X) is a PACIASP/PACIBSP instruction.  */
+bool
+aarch_pac_insn_p (rtx x)
+{
+  if (!INSN_P (x))
+return false;
+
+  subrtx_var_iterator::array_type array;
+  FOR_EACH_SUBRTX_VAR (iter, array, PATTERN (x), ALL)
+{
+  rtx sub = *iter;
+  if (sub && GET_CODE (sub) == UNSPEC)
+   {
+ int unspec_val = XINT (sub, 1);
+ switch (unspec_val)
+   {
+   case UNSPEC_PACIASP:
+case UNSPEC_PACIBSP:
+ return true;
+
+   default:
+ return false;
+   }
+ iter.skip_subrtxes ();
+   }
+}
+  return false;
+}
+
+rtx aarch_gen_bti_c (void)
+{
+  return gen_bti_c ();
+}
+
+rtx aarch_gen_bti_j (void)
+{
+  return gen_bti_j ();
+}
+
 /* The caller is going to use ST1D or LD1D to save or restore an SVE
register in mode MODE at BASE_RTX + OFFSET, where OFFSET is in
the range [1, 16] * GET_MODE_SIZE (MODE).  Prepare for this by:
@@ -9918,7 +9968,7 @@ aarch64_output_mi_thunk (FILE *file, 

[PATCH 10/12] arm: Implement cortex-M return signing address codegen

[Andrea Corallo via Gcc-patches]

Hi all,

this patch enables address return signature and verification based on
Armv8.1-M Pointer Authentication [1].

To sign the return address, we use the PAC R12, LR, SP instruction
upon function entry.  This is signing LR using SP and storing the
result in R12.  R12 will be pushed into the stack.

During function epilogue R12 will be popped and AUT R12, LR, SP will
be used to verify that the content of LR is still valid before return.

Here an example of PAC instrumented function prologue and epilogue:

void foo (void);

int main()
{
  foo ();
  return 0;
}

Compiled with '-march=armv8.1-m.main -mbranch-protection=pac-ret
-mthumb' translates into:

main:
pac ip, lr, sp
push{r3, r7, ip, lr}
add r7, sp, #0
bl  foo
movsr3, #0
mov r0, r3
pop {r3, r7, ip, lr}
aut ip, lr, sp
bx  lr

The patch also takes care of generating a PACBTI instruction in place
of the sequence BTI+PAC when Branch Target Identification is enabled
contextually.

Ex. the previous example compiled with '-march=armv8.1-m.main
-mbranch-protection=pac-ret+bti -mthumb' translates into:

main:
pacbti  ip, lr, sp
push{r3, r7, ip, lr}
add r7, sp, #0
bl  foo
movsr3, #0
mov r0, r3
pop {r3, r7, ip, lr}
aut ip, lr, sp
bx  lr

As part of previous upstream suggestions a test for varargs has been
added and '-mtpcs-frame' is deemed being incompatible with this return
signing address feature being introduced.

[1] 


gcc/Changelog

* config/arm/arm.c: (arm_compute_frame_layout)
(arm_expand_prologue, thumb2_expand_return, arm_expand_epilogue)
(arm_conditional_register_usage): Update for pac codegen.
(arm_current_function_pac_enabled_p): New function.
* config/arm/arm.md (pac_ip_lr_sp, pacbti_ip_lr_sp, aut_ip_lr_sp):
Add new patterns.
* config/arm/unspecs.md (UNSPEC_PAC_IP_LR_SP)
(UNSPEC_PACBTI_IP_LR_SP, UNSPEC_AUT_IP_LR_SP): Add unspecs.

gcc/testsuite/Changelog

* gcc.target/arm/pac.h : New file.
* gcc.target/arm/pac-1.c : New test case.
* gcc.target/arm/pac-2.c : Likewise.
* gcc.target/arm/pac-3.c : Likewise.
* gcc.target/arm/pac-4.c : Likewise.
* gcc.target/arm/pac-5.c : Likewise.
* gcc.target/arm/pac-6.c : Likewise.
* gcc.target/arm/pac-7.c : Likewise.
* gcc.target/arm/pac-8.c : Likewise.

diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index ceec14f84b6..c91dae292c8 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -302,6 +302,7 @@ static bool arm_vectorize_vec_perm_const (machine_mode, 
rtx, rtx, rtx,
  const vec_perm_indices &);
 
 static bool aarch_macro_fusion_pair_p (rtx_insn*, rtx_insn*);
+static bool arm_current_function_pac_enabled_p (void);
 
 static int arm_builtin_vectorization_cost (enum vect_cost_for_stmt 
type_of_cost,
   tree vectype,
@@ -21139,6 +21140,14 @@ arm_compute_save_core_reg_mask (void)
 
   save_reg_mask |= arm_compute_save_reg0_reg12_mask ();
 
+  if (arm_current_function_pac_enabled_p ())
+{
+  if (TARGET_TPCS_FRAME
+ || (TARGET_TPCS_LEAF_FRAME && crtl->is_leaf))
+   error ("TPCS incompatible with return address signing.");
+  save_reg_mask |= 1 << IP_REGNUM;
+}
+
   /* Decide if we need to save the link register.
  Interrupt routines have their own banked link register,
  so they never need to save it.
@@ -22302,7 +22311,7 @@ arm_emit_multi_reg_pop (unsigned long saved_regs_mask)
 par = emit_insn (par);
 
   REG_NOTES (par) = dwarf;
-  if (!return_in_pc)
+  if (!return_in_pc && !frame_pointer_needed)
 arm_add_cfa_adjust_cfa_note (par, UNITS_PER_WORD * num_regs,
 stack_pointer_rtx, stack_pointer_rtx);
 }
@@ -23352,6 +23361,11 @@ output_probe_stack_range (rtx reg1, rtx reg2)
   return "";
 }
 
+static bool  aarch_bti_enabled ()
+{
+  return false;
+}
+
 /* Generate the prologue instructions for entry into an ARM or Thumb-2
function.  */
 void
@@ -23431,11 +23445,12 @@ arm_expand_prologue (void)
   /* The static chain register is the same as the IP register.  If it is
  clobbered when creating the frame, we need to save and restore it.  */
   clobber_ip = IS_NESTED (func_type)
-  && ((TARGET_APCS_FRAME && frame_pointer_needed && TARGET_ARM)
-  || ((flag_stack_check == STATIC_BUILTIN_STACK_CHECK
-   || flag_stack_clash_protection)
-  && !df_regs_ever_live_p (LR_REGNUM)
-  && arm_r3_live_at_start_p ()));
+&& (((TARGET_APCS_FRAME && 

[PATCH 9/12] arm: Make libgcc bti compatible

[Andrea Corallo via Gcc-patches]

This change add bti instructions at the beginning of arm specific
libgcc hand written assembly routines.

2022-03-31  Andrea Corallo  

* libgcc/config/arm/crti.S (FUNC_START): Add bti instruction if
necessary.
* libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START):
Likewise.

diff --git a/libgcc/config/arm/crti.S b/libgcc/config/arm/crti.S
index 0192972a7e6..bac2d87fbb9 100644
--- a/libgcc/config/arm/crti.S
+++ b/libgcc/config/arm/crti.S
@@ -51,7 +51,9 @@
 .macro FUNC_START
 #ifdef __thumb__
.thumb
-   
+#if defined(__ARM_FEATURE_BTI)
+   bti
+#endif
push{r3, r4, r5, r6, r7, lr}
 #else
.arm
diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
index 8c39c9f20a2..45dfb5da9ee 100644
--- a/libgcc/config/arm/lib1funcs.S
+++ b/libgcc/config/arm/lib1funcs.S
@@ -345,6 +345,9 @@ LSYM(Ldiv0):
TYPE(\name)
.thumb_func
 SYM (\name):
+#if defined(__ARM_FEATURE_BTI)
+   bti
+#endif
 .endm
 
 /* Function start macros.  Variants for ARM and Thumb.  */
@@ -372,6 +375,9 @@ SYM (\name):
THUMB_FUNC
THUMB_SYNTAX
 SYM (__\name):
+#if defined(__ARM_FEATURE_BTI)
+   bti
+#endif
 .endm
 
 .macro ARM_SYM_START name

[PATCH 8/12] arm: Introduce multilibs for PACBTI target feature

[Andrea Corallo via Gcc-patches]

This patch add the following new multilibs.

thumb/v8.1-m.main+pacbti/mbranch-protection/nofp
thumb/v8.1-m.main+pacbti+dp/mbranch-protection/soft
thumb/v8.1-m.main+pacbti+dp/mbranch-protection/hard
thumb/v8.1-m.main+pacbti+fp/mbranch-protection/soft
thumb/v8.1-m.main+pacbti+fp/mbranch-protection/hard
thumb/v8.1-m.main+pacbti+mve/mbranch-protection/hard

Triggering the following compiler flags:

-mthumb -march=armv8.1-m.main+pacbti -mbranch-protection=standard 
-mfloat-abi=soft
-mthumb -march=armv8.1-m.main+pacbti+fp -mbranch-protection=standard 
-mfloat-abi=softfp
-mthumb -march=armv8.1-m.main+pacbti+fp -mbranch-protection=standard 
-mfloat-abi=hard
-mthumb -march=armv8.1-m.main+pacbti+fp.dp -mbranch-protection=standard 
-mfloat-abi=softfp
-mthumb -march=armv8.1-m.main+pacbti+fp.dp -mbranch-protection=standard 
-mfloat-abi=hard
-mthumb -march=armv8.1-m.main+pacbti+mve -mbranch-protection=standard 
-mfloat-abi=hard

gcc/ChangeLog:

* config/arm/t-rmprofile: Add multilib rules for +pacbti.

diff --git a/gcc/config/arm/t-rmprofile b/gcc/config/arm/t-rmprofile
index eb321e832f1..542ff874b2e 100644
--- a/gcc/config/arm/t-rmprofile
+++ b/gcc/config/arm/t-rmprofile
@@ -27,8 +27,11 @@
 
 # Arch and FPU variants to build libraries with
 
-MULTI_ARCH_OPTS_RM = 
march=armv6s-m/march=armv7-m/march=armv7e-m/march=armv7e-m+fp/march=armv7e-m+fp.dp/march=armv8-m.base/march=armv8-m.main/march=armv8-m.main+fp/march=armv8-m.main+fp.dp/march=armv8.1-m.main+mve
-MULTI_ARCH_DIRS_RM = v6-m v7-m v7e-m v7e-m+fp v7e-m+dp v8-m.base v8-m.main 
v8-m.main+fp v8-m.main+dp v8.1-m.main+mve
+MULTI_ARCH_OPTS_RM = 
march=armv6s-m/march=armv7-m/march=armv7e-m/march=armv7e-m+fp/march=armv7e-m+fp.dp/march=armv8-m.base/march=armv8-m.main/march=armv8-m.main+fp/march=armv8-m.main+fp.dp/march=armv8.1-m.main+mve/march=armv8.1-m.main+pacbti/march=armv8.1-m.main+pacbti+fp/march=armv8.1-m.main+pacbti+fp.dp/march=armv8.1-m.main+pacbti+mve
+MULTI_ARCH_DIRS_RM = v6-m v7-m v7e-m v7e-m+fp v7e-m+dp v8-m.base v8-m.main 
v8-m.main+fp v8-m.main+dp v8.1-m.main+mve v8.1-m.main+pacbti 
v8.1-m.main+pacbti+fp v8.1-m.main+pacbti+dp 8.1-m.main+pacbti+mve
+
+MULTI_ARCH_OPTS_RM += mbranch-protection=pac-ret+bti
+MULTI_ARCH_DIRS_RM += mbranch-protection
 
 # Base M-profile (no fp)
 MULTILIB_REQUIRED  += mthumb/march=armv6s-m/mfloat-abi=soft
@@ -50,6 +53,14 @@ MULTILIB_REQUIRED+= 
mthumb/march=armv8-m.main+fp.dp/mfloat-abi=hard
 MULTILIB_REQUIRED  += mthumb/march=armv8-m.main+fp.dp/mfloat-abi=softfp
 MULTILIB_REQUIRED  += mthumb/march=armv8.1-m.main+mve/mfloat-abi=hard
 
+MULTILIB_REQUIRED  += 
mthumb/march=armv8.1-m.main+pacbti/mbranch-protection=standard/mfloat-abi=soft
+MULTILIB_REQUIRED  += 
mthumb/march=armv8.1-m.main+pacbti+fp/mbranch-protection=standard/mfloat-abi=softfp
+MULTILIB_REQUIRED  += 
mthumb/march=armv8.1-m.main+pacbti+fp/mbranch-protection=standard/mfloat-abi=hard
+MULTILIB_REQUIRED  += 
mthumb/march=armv8.1-m.main+pacbti+fp.dp/mbranch-protection=standard/mfloat-abi=softfp
+MULTILIB_REQUIRED  += 
mthumb/march=armv8.1-m.main+pacbti+fp.dp/mbranch-protection=standard/mfloat-abi=hard
+MULTILIB_REQUIRED  += 
mthumb/march=armv8.1-m.main+pacbti+mve/mbranch-protection=standard/mfloat-abi=hard
+
+
 # Arch Matches
 MULTILIB_MATCHES   += march?armv6s-m=march?armv6-m
 
@@ -93,3 +104,4 @@ MULTILIB_MATCHES += 
march?armv8-m.main=mlibarch?armv8-m.main
 MULTILIB_MATCHES   += march?armv8-m.main+fp=mlibarch?armv8-m.main+fp
 MULTILIB_MATCHES   += march?armv8-m.main+fp.dp=mlibarch?armv8-m.main+fp.dp
 MULTILIB_MATCHES   += march?armv8.1-m.main+mve=mlibarch?armv8.1-m.main+mve
+MULTILIB_MATCHES   += 
march?armv8.1-m.main+pacbti=mlibarch?armv8.1-m.main+pacbti

[PATCH] doc: Remove misleading text about multilibs for IEEE long double

[Jonathan Wakely via Gcc-patches]

IIUC this text is not true (maybe it was back in 2018?)

OK for trunk?

Which branches should it be on too, all of them?

-- >8 --

The choice of ieee or ibm long double format is orthogonal to multilibs,
as the two sets of symbols co-exist and don't need a separate multilib.

gcc/ChangeLog:

* doc/install.texi (Configuration): Remove misleading text
around LE PowerPC Linux multilibs.
---
 gcc/doc/install.texi | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 3192824bdc4..10bfceffceb 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2139,17 +2139,6 @@ Until all of the libraries are converted to use IEEE 
128-bit floating
 point, it is not recommended to use
 @option{--with-long-double-format=ieee}.
 
-On little endian PowerPC Linux systems, if you explicitly set the
-@code{long double} type, it will build multilibs to allow you to
-select either @code{long double} format, unless you disable multilibs
-with the @code{--disable-multilib} option.  At present,
-@code{long double} multilibs are not built on big endian PowerPC Linux
-systems.  If you are building multilibs, you will need to configure
-the compiler using the @option{--with-system-zlib} option.
-
-If you do not set the @code{long double} type explicitly, no multilibs
-will be generated.
-
 @item --enable-fdpic
 On SH Linux systems, generate ELF FDPIC code.
 
-- 
2.34.1

[PATCH 7/12] arm: Emit build attributes for PACBTI target feature

[Andrea Corallo via Gcc-patches]

This patch emits assembler directives for PACBTI build attributes as
defined by the
ABI.



gcc/ChangeLog:

* config/arm/arm.c (arm_file_start): Emit EABI attributes for
Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use, TAG_PACRET_use.

gcc/testsuite/ChangeLog:

* gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-3: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-6.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-7.c: Likewise.

Co-Authored-By: Tejas Belagod  

diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 0068817b0f2..ceec14f84b6 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -28349,6 +28349,8 @@ static void
 arm_file_start (void)
 {
   int val;
+  bool pac = (aarch_ra_sign_scope != AARCH_FUNCTION_NONE);
+  bool bti = (aarch_enable_bti == 1);
 
   arm_print_asm_arch_directives
 (asm_out_file, TREE_TARGET_OPTION (target_option_default_node));
@@ -28419,6 +28421,22 @@ arm_file_start (void)
arm_emit_eabi_attribute ("Tag_ABI_FP_16bit_format", 38,
 (int) arm_fp16_format);
 
+  if (TARGET_HAVE_PACBTI)
+   {
+ arm_emit_eabi_attribute ("Tag_PAC_extension", 50, 2);
+ arm_emit_eabi_attribute ("Tag_BTI_extension", 52, 2);
+   }
+  else if (pac || bti)
+   {
+ arm_emit_eabi_attribute ("Tag_PAC_extension", 50, 1);
+ arm_emit_eabi_attribute ("Tag_BTI_extension", 52, 1);
+   }
+
+  if (bti)
+arm_emit_eabi_attribute ("TAG_BTI_use", 74, 1);
+  if (pac)
+   arm_emit_eabi_attribute ("TAG_PACRET_use", 76, 1);
+
   if (arm_lang_output_object_attributes_hook)
arm_lang_output_object_attributes_hook();
 }
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-1.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-1.c
new file mode 100644
index 000..75d3e00ef64
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-1.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-additional-options " -mbranch-protection=pac-ret+bti --save-temps" } */
+
+#if !defined (__ARM_FEATURE_BTI_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined."
+#endif
+
+#if !defined (__ARM_FEATURE_PAC_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_PAC_DEFAULT should be defined."
+#endif
+
+/* { dg-final { scan-assembler-not "\.arch_extension pacbti" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 50, 1" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 52, 1" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 74, 1" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 76, 1" } } */
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-3.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-3.c
new file mode 100644
index 000..bf6c3ba90c9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-3.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-additional-options " -mbranch-protection=pac-ret+leaf --save-temps" } 
*/
+
+#if defined (__ARM_FEATURE_BTI_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be undefined."
+#endif
+
+#if !defined (__ARM_FEATURE_PAC_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_PAC_DEFAULT should be defined."
+#endif
+
+/* { dg-final { scan-assembler-not "\.arch_extension pacbti" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 50, 1" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 52, 1" } } */
+/* { dg-final { scan-assembler-not "\.eabi_attribute 74" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 76, 1" } } */
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-6.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-6.c
new file mode 100644
index 000..82af11ee407
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-6.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-additional-options " -mbranch-protection=bti --save-temps" } */
+
+#if !defined (__ARM_FEATURE_BTI_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined."
+#endif
+
+#if defined (__ARM_FEATURE_PAC_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_PAC_DEFAULT should be undefined."
+#endif
+/* { dg-final { scan-assembler-not "\.arch_extension pacbti" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 50, 1" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 52, 1" } } */
+/* { dg-final { scan-assembler "\.eabi_attribute 74, 1" } } */
+/* { dg-final { scan-assembler-not "\.eabi_attribute 76" } } */
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
new file mode 100644
index 000..48a40e64c11
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { 

[PATCH 6/12] arm: Add pointer authentication for stack-unwinding runtime

[Andrea Corallo via Gcc-patches]

This patch adds authentication for when the stack is unwound when an
exception is taken.  All the changes here are done to the runtime code
in libgcc's unwinder code for Arm target. All the changes are guarded
under defined (__ARM_FEATURE_PAC_DEFAULT) and activated only if the
+pacbti feature is switched on for the architecture. This means that
switching on the target feature via -march or -mcpu is sufficient and
-mbranch-protection need not be enabled. This ensures that the
unwinder is authenticated only if the PACBTI instructions are
available in the non-NOP space as it uses AUTG.  Just generating
PAC/AUT instructions using -mbranch-protection will not enable
authentication on the unwinder.

Pre-approved with the requested changes here
.

gcc/ChangeLog:

* ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass): Introduce
new pseudo register class _UVRSC_PAC.
* libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode
exception opcode (0xb4) for saving RA_AUTH_CODE and authenticate
with AUTG if found.
* libgcc/config/arm/unwind-arm.c (struct pseudo_regs): New.
(phase1_vrs): Introduce new field to store pseudo-reg state.
(phase2_vrs): Likewise.
(_Unwind_VRS_Get): Load pseudo register state from virtual reg set.
(_Unwind_VRS_Set): Store pseudo register state to virtual reg set.
(_Unwind_VRS_Pop): Load pseudo register value from stack into VRS.

Co-Authored-By: Tejas Belagod  

diff --git a/gcc/ginclude/unwind-arm-common.h b/gcc/ginclude/unwind-arm-common.h
index d3831f6c60a..f26702e8c6c 100644
--- a/gcc/ginclude/unwind-arm-common.h
+++ b/gcc/ginclude/unwind-arm-common.h
@@ -127,7 +127,8 @@ extern "C" {
   _UVRSC_VFP = 1,   /* vfp */
   _UVRSC_FPA = 2,   /* fpa */
   _UVRSC_WMMXD = 3, /* Intel WMMX data register */
-  _UVRSC_WMMXC = 4  /* Intel WMMX control register */
+  _UVRSC_WMMXC = 4, /* Intel WMMX control register */
+  _UVRSC_PAC = 5/* Armv8.1-M Mainline PAC/AUTH pseudo-register */
 }
   _Unwind_VRS_RegClass;
 
diff --git a/libgcc/config/arm/pr-support.c b/libgcc/config/arm/pr-support.c
index 2de96c2a447..e48854587c6 100644
--- a/libgcc/config/arm/pr-support.c
+++ b/libgcc/config/arm/pr-support.c
@@ -106,6 +106,7 @@ __gnu_unwind_execute (_Unwind_Context * context, 
__gnu_unwind_state * uws)
 {
   _uw op;
   int set_pc;
+  int set_pac = 0;
   _uw reg;
 
   set_pc = 0;
@@ -114,6 +115,27 @@ __gnu_unwind_execute (_Unwind_Context * context, 
__gnu_unwind_state * uws)
   op = next_unwind_byte (uws);
   if (op == CODE_FINISH)
{
+ /* When we reach end, we have to authenticate R12 we just popped
+earlier.
+
+Note: while the check provides additional security against a
+corrupted unwind chain, it isn't essential for correct unwinding
+of an uncorrupted chain.  */
+#if defined(TARGET_HAVE_PACBTI)
+ if (set_pac)
+   {
+ _uw sp;
+ _uw lr;
+ _uw pac;
+ _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, );
+ _Unwind_VRS_Get (context, _UVRSC_CORE, R_LR, _UVRSD_UINT32, );
+ _Unwind_VRS_Get (context, _UVRSC_PAC, R_IP,
+  _UVRSD_UINT32, );
+ __asm__ __volatile__
+   ("autg %0, %1, %2" : : "r"(pac), "r"(lr), "r"(sp) :);
+   }
+#endif
+
  /* If we haven't already set pc then copy it from lr.  */
  if (!set_pc)
{
@@ -227,6 +249,16 @@ __gnu_unwind_execute (_Unwind_Context * context, 
__gnu_unwind_state * uws)
return _URC_FAILURE;
  continue;
}
+ /* Pop PAC off the stack into VRS pseudo.pac.  */
+ if (op == 0xb4)
+   {
+ if (_Unwind_VRS_Pop (context, _UVRSC_PAC, 0, _UVRSD_UINT32)
+ != _UVRSR_OK)
+   return _URC_FAILURE;
+ set_pac = 1;
+ continue;
+   }
+
  if ((op & 0xfc) == 0xb4)  /* Obsolete FPA.  */
return _URC_FAILURE;
 
diff --git a/libgcc/config/arm/unwind-arm.c b/libgcc/config/arm/unwind-arm.c
index 386406564af..89f945d047e 100644
--- a/libgcc/config/arm/unwind-arm.c
+++ b/libgcc/config/arm/unwind-arm.c
@@ -64,6 +64,12 @@ struct wmmxc_regs
   _uw wc[4];
 };
 
+/*  Holds value of pseudo registers eg. PAC.  */
+struct pseudo_regs
+{
+  _uw pac;
+};
+
 /* The ABI specifies that the unwind routines may only use core registers,
except when actually manipulating coprocessor state.  This allows
us to write one implementation that works on all platforms by
@@ -78,6 +84,9 @@ typedef struct
   /* The first fields must be the same as a phase2_vrs.  */
   _uw demand_save_flags;
   struct core_regs core;
+  /* Armv8.1-M Mainline PAC/AUTH values.  This field should be in the same 
field
+ order as 

[PATCH 5/12] arm: Implement target feature macros for PACBTI

[Andrea Corallo via Gcc-patches]

This patch implements target feature macros when PACBTI is enabled
through the -march option or -mbranch-protection.  The target feature
macros __ARM_FEATURE_PAC_DEFAULT and __ARM_FEATURE_BTI_DEFAULT are
specified in ARM ACLE

__ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI are specified in the
pull-request .

Approved here
.

gcc/ChangeLog:

* config/arm/arm-c.c (arm_cpu_builtins): Define
__ARM_FEATURE_BTI_DEFAULT, __ARM_FEATURE_PAC_DEFAULT,
__ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI.

gcc/testsuite/ChangeLog:

* gcc.target/arm/acle/pacbti-m-predef-2.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-4.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-5.c: New test.

Co-Authored-By: Tejas Belagod  

diff --git a/gcc/config/arm/arm-c.cc b/gcc/config/arm/arm-c.cc
index a8697b8c62f..190099b2c37 100644
--- a/gcc/config/arm/arm-c.cc
+++ b/gcc/config/arm/arm-c.cc
@@ -212,6 +212,24 @@ arm_cpu_builtins (struct cpp_reader* pfile)
   def_or_undef_macro (pfile, "__ARM_FEATURE_COMPLEX", TARGET_COMPLEX);
   def_or_undef_macro (pfile, "__ARM_32BIT_STATE", TARGET_32BIT);
 
+  def_or_undef_macro (pfile, "__ARM_FEATURE_PAUTH", TARGET_HAVE_PACBTI);
+  def_or_undef_macro (pfile, "__ARM_FEATURE_BTI", TARGET_HAVE_PACBTI);
+  def_or_undef_macro (pfile, "__ARM_FEATURE_BTI_DEFAULT",
+ aarch_enable_bti == 1);
+
+  cpp_undef (pfile, "__ARM_FEATURE_PAC_DEFAULT");
+  if (aarch_ra_sign_scope != AARCH_FUNCTION_NONE)
+  {
+unsigned int pac = 1;
+
+gcc_assert (aarch_ra_sign_key == AARCH_KEY_A);
+
+if (aarch_ra_sign_scope == AARCH_FUNCTION_ALL)
+  pac |= 0x4;
+
+builtin_define_with_int_value ("__ARM_FEATURE_PAC_DEFAULT", pac);
+  }
+
   cpp_undef (pfile, "__ARM_FEATURE_MVE");
   if (TARGET_HAVE_MVE && TARGET_HAVE_MVE_FLOAT)
 {
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-2.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-2.c
new file mode 100644
index 000..4394fd147d7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-2.c
@@ -0,0 +1,24 @@
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_pacbti_hw } */
+/* { dg-additional-options " -mbranch-protection=bti+pac-ret+leaf" } */
+
+#if !defined (__ARM_FEATURE_BTI_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined."
+#endif
+
+#if !defined (__ARM_FEATURE_PAC_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_PAC_DEFAULT should be defined."
+#endif
+
+int
+main()
+{
+  if (__ARM_FEATURE_BTI_DEFAULT != 1)
+__builtin_abort ();
+
+  if (__ARM_FEATURE_PAC_DEFAULT != 5)
+__builtin_abort ();
+
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-4.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-4.c
new file mode 100644
index 000..90f0c724b9e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-4.c
@@ -0,0 +1,21 @@
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_pacbti_hw } */
+/* { dg-additional-options " -mbranch-protection=pac-ret" } */
+
+#if !defined (__ARM_FEATURE_PAC_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined."
+#endif
+
+#if defined (__ARM_FEATURE_BTI_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be undefined."
+#endif
+
+int
+main()
+{
+  if (__ARM_FEATURE_PAC_DEFAULT != 1)
+__builtin_abort ();
+
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-5.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-5.c
new file mode 100644
index 000..c865809b8b0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-5.c
@@ -0,0 +1,24 @@
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_pacbti_hw } */
+/* { dg-additional-options " -mbranch-protection=bti+pac-ret" } */
+
+#if !defined (__ARM_FEATURE_BTI_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined."
+#endif
+
+#if !defined (__ARM_FEATURE_PAC_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_PAC_DEFAULT should be defined."
+#endif
+
+int
+main()
+{
+  if (__ARM_FEATURE_BTI_DEFAULT != 1)
+__builtin_abort ();
+
+  if (__ARM_FEATURE_PAC_DEFAULT != 1)
+__builtin_abort ();
+
+  return 0;
+}

[PATCH 4/12] arm: Add testsuite library support for PACBTI target

[Andrea Corallo via Gcc-patches]

Add targeting-checking entities for PACBTI in testsuite
framework.

Pre-approved with the requested changes here
.

gcc/testsuite/ChangeLog:

* testsuite/lib/target-supports.exp:
(check_effective_target_arm_pacbti_hw): New.
* doc/sourcebuild.texi: Document arm_pacbti_hw.

Co-Authored-By: Tejas Belagod  

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 613ac29967b..e8cbd8e4aef 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2167,6 +2167,10 @@ ARM target supports options to generate instructions 
from ARMv8.1-M with
 the Custom Datapath Extension (CDE) and M-Profile Vector Extension (MVE).
 Some multilibs may be incompatible with these options.
 
+@item arm_pacbti_hw
+Test system supports executing Pointer Authentication and Branch Target
+Identification instructions.
+
 @item arm_prefer_ldrd_strd
 ARM target prefers @code{LDRD} and @code{STRD} instructions over
 @code{LDM} and @code{STM} instructions.
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ff8edbd3e17..df8ab037fb3 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5090,6 +5090,22 @@ proc check_effective_target_arm_cmse_clear_ok {} {
 } "-mcmse"];
 }
 
+# Return 1 if the target supports executing PACBTI instructions, 0
+# otherwise.
+
+proc check_effective_target_arm_pacbti_hw {} {
+return [check_runtime arm_pacbti_hw_available {
+   __attribute__ ((naked)) int
+   main (void)
+   {
+ asm ("pac r12, lr, sp");
+ asm ("mov r0, #0");
+ asm ("autg r12, lr, sp");
+ asm ("bx lr");
+   }
+} ""]
+}
+
 # Return 1 if this compilation turns on string_ops_prefer_neon on.
 
 proc check_effective_target_arm_tune_string_ops_prefer_neon { } {

[PATCH 3/12] arm: Add option -mbranch-protection

[Andrea Corallo via Gcc-patches]

[PATCH 3/12] arm: Add option -mbranch-protection

Add -mbranch-protection option.  This option enables the
code-generation of pointer signing and authentication instructions in
function prologues and epilogues.

gcc/ChangeLog:

* config/arm/arm.c (arm_configure_build_target): Parse and validate
-mbranch-protection option and initialize appropriate data structures.
* config/arm/arm.opt (-mbranch-protection): New option.
* doc/invoke.texi (Arm Options): Document it.

Co-Authored-By: Tejas Belagod  
Co-Authored-By: Richard Earnshaw 

diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 60f3eae82a4..0068817b0f2 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -3263,6 +3263,17 @@ arm_configure_build_target (struct arm_build_target 
*target,
   tune_opts = strchr (opts->x_arm_tune_string, '+');
 }
 
+  if (opts->x_arm_branch_protection_string)
+{
+  aarch_validate_mbranch_protection (opts->x_arm_branch_protection_string);
+
+  if (aarch_ra_sign_key != AARCH_KEY_A)
+   {
+ warning (0, "invalid key type for %<-mbranch-protection=%>");
+ aarch_ra_sign_key = AARCH_KEY_A;
+   }
+}
+
   if (arm_selected_arch)
 {
   arm_initialize_isa (target->isa, arm_selected_arch->common.isa_bits);
diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt
index f54ec8356c3..d292e23ea11 100644
--- a/gcc/config/arm/arm.opt
+++ b/gcc/config/arm/arm.opt
@@ -323,6 +323,10 @@ mbranch-cost=
 Target RejectNegative Joined UInteger Var(arm_branch_cost) Init(-1)
 Cost to assume for a branch insn.
 
+mbranch-protection=
+Target RejectNegative Joined Var(arm_branch_protection_string) Save
+Use branch-protection features.
+
 mgeneral-regs-only
 Target RejectNegative Mask(GENERAL_REGS_ONLY) Save
 Generate code which uses the core registers only (r0-r14).
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 079e34ed98c..f6f724af26e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -825,7 +825,9 @@ Objective-C and Objective-C++ Dialects}.
 -mcmse @gol
 -mfix-cmse-cve-2021-35465 @gol
 -mstack-protector-guard=@var{guard} 
-mstack-protector-guard-offset=@var{offset} @gol
--mfdpic}
+-mfdpic @gol
+-mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}]
+[+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]}
 
 @emph{AVR Options}
 @gccoptlist{-mmcu=@var{mcu}  -mabsdata  -maccumulate-args @gol
@@ -21521,6 +21523,37 @@ The opposite @option{-mno-fdpic} option is useful (and 
required) to
 build the Linux kernel using the same (@code{arm-*-uclinuxfdpiceabi})
 toolchain as the one used to build the userland programs.
 
+@item
+-mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}][+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]
+@opindex mbranch-protection
+Enable branch protection features (armv8.1-m.main only).
+@samp{none} generate code without branch protection or return address
+signing.
+@samp{standard[+@var{leaf}]} generate code with all branch protection
+features enabled at their standard level.
+@samp{pac-ret[+@var{leaf}]} generate code with return address signing
+set to its standard level, which is to sign all functions that save
+the return address to memory.
+@samp{leaf} When return address signing is enabled, also sign leaf
+functions even if they do not write the return address to memory.
++@samp{bti} Add landing-pad instructions at the permitted targets of
+indirect branch instructions.
+
+If the @samp{+pacbti} architecture extension is not enabled, then all
+branch protection and return address signing operations are
+constrained to use only the instructions defined in the
+architectural-NOP space. The generated code will remain
+backwards-compatible with earlier versions of the architecture, but
+the additional security can be enabled at run time on processors that
+support the @samp{PACBTI} extension.
+
+Branch target enforcement using BTI can only be enabled at runtime if
+all code in the application has been compiled with at least
+@samp{-mbranch-protection=bti}.
+
+The default is to generate code without branch protection or return
+address signing.
+
 @end table
 
 @node AVR Options

[PATCH 2/12] arm: Add Armv8.1-M Mainline target feature +pacbti

[Andrea Corallo via Gcc-patches]

This patch adds the -march feature +pacbti to Armv8.1-M Mainline.

This feature enables pointer signing and authentication instructions
on M-class architectures.

Pre-approved here
.

gcc/Changelog:

* config/arm/arm.h (TARGET_HAVE_PACBTI): New macro.
* config/arm/arm-cpus.in (pacbti): New feature.
* doc/invoke.texi (Arm Options): Document it.

Co-Authored-By: Tejas Belagod  

diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
index 0d3082b569f..6c1dffe56e3 100644
--- a/gcc/config/arm/arm-cpus.in
+++ b/gcc/config/arm/arm-cpus.in
@@ -229,6 +229,10 @@ define feature cdecp5
 define feature cdecp6
 define feature cdecp7
 
+# M-profile control flow integrity extensions (PAC/AUT/BTI).
+# Optional from Armv8.1-M Mainline.
+define feature pacbti
+
 # Feature groups.  Conventionally all (or mostly) upper case.
 # ALL_FPU lists all the feature bits associated with the floating-point
 # unit; these will all be removed if the floating-point unit is disabled
@@ -748,6 +752,7 @@ begin arch armv8.1-m.main
  option nofp remove ALL_FP
  option mve add MVE
  option mve.fp add MVE_FP
+ option pacbti add pacbti
  option cdecp0 add cdecp0
  option cdecp1 add cdecp1
  option cdecp2 add cdecp2
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index f479540812a..3495ab857ea 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -335,6 +335,12 @@ emission of floating point pcs attributes.  */
isa_bit_mve_float) \
   && !TARGET_GENERAL_REGS_ONLY)
 
+/* Non-zero if this target supports Armv8.1-M Mainline pointer-signing
+   extension.  */
+#define TARGET_HAVE_PACBTI (arm_arch8_1m_main \
+   && bitmap_bit_p (arm_active_target.isa, \
+isa_bit_pacbti))
+
 /* MVE have few common instructions as VFP, like VLDM alias VPOP, VLDR, VSTM
alia VPUSH, VSTR and VMOV, VMSR and VMRS.  In the same manner it updates few
registers such as FPCAR, FPCCR, FPDSCR, FPSCR, MVFR0, MVFR1 and MVFR2.  All
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3936aef69d0..079e34ed98c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -21002,6 +21002,9 @@ Disable the floating-point extension.
 @item +cdecp0, +cdecp1, ... , +cdecp7
 Enable the Custom Datapath Extension (CDE) on selected coprocessors according
 to the numbers given in the options in the range 0 to 7.
+
+@item +pacbti
+Enable the Pointer Authentication and Branch Target Identification Extension.
 @end table
 
 @item  armv8-m.main

Re: [PATCH]middle-end testsuite: Backport testsuite changes from GCC 12 to GCC 11

[Richard Biener via Gcc-patches]

On Thu, 28 Apr 2022, Tamar Christina wrote:

> Hi All,
> 
> This backports the testsuite changes from mainline to GCC 11.
> This enables some tests that were not running and fix some
> unresolved cases. The test output are adjusted to what GCC 11 could detect.
> 
> Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for GCC 11?

OK if you verified the testcases pass on the branch.

Richard.

> Thanks,
> Tamar
> 
> gcc/testsuite/ChangeLog:
> 
>   PR testsuite/105095
>   * gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c: Update for
>   codegen.
>   * gcc.dg/vect/complex/fast-math-complex-add-double.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-add-float.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-add-half-float.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-add-pattern-double.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-add-pattern-float.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-add-pattern-half-float.c:
>   Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-mla-half-float.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-mls-double.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-mls-float.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-mls-half-float.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-mul-double.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-mul-float.c: Likewise.
>   * gcc.dg/vect/complex/fast-math-complex-mul-half-float.c: Likewise.
>   * gcc.dg/vect/vect.exp: Add extra letter to filter.
> 
> --- inline copy of patch -- 
> diff --git 
> a/gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c 
> b/gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c
> index 
> 827687b92fa7a8e68bf3eaa101ab67a5d07901f3..8eb8baceb31f86d4a3c35276870769d673f1fd36
>  100644
> --- a/gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c
> +++ b/gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c
> @@ -1,10 +1,11 @@
>  /* { dg-do compile } */
>  /* { dg-require-effective-target vect_complex_add_float } */
> +/* { dg-additional-options "-fno-tree-loop-vectorize" } */
>  /* { dg-add-options arm_v8_3a_complex_neon } */
>  
>  #define TYPE float
>  #define N 16
>  #include "complex-mul-template.c"
>  
> -/* { dg-final { scan-tree-dump "Found COMPLEX_MUL_CONJ" "vect" } } */
> -/* { dg-final { scan-tree-dump "Found COMPLEX_MUL" "vect" } } */
> +/* { dg-final { scan-tree-dump "Found COMPLEX_MUL_CONJ" "slp1" { xfail *-*-* 
> } } } */
> +/* { dg-final { scan-tree-dump "Found COMPLEX_MUL" "slp1" } } */
> diff --git a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-double.c 
> b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-double.c
> index 
> f935405e3d942cc68e49b2b21ca543e23076e0c9..5cff373b80d2eb8d3945ac38a656d081faea3737
>  100644
> --- a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-double.c
> +++ b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-double.c
> @@ -6,7 +6,7 @@
>  #define N 200
>  #include "complex-add-template.c"
>  
> -/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT270" 2 "vect" { 
> target { vect_complex_add_double } } } } */
> -/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT90" 2 "vect"  { 
> target { vect_complex_add_double } } } } */
> +/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT270" 1 "vect" { 
> target { vect_complex_add_double } } } } */
> +/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT90" 1 "vect"  { 
> target { vect_complex_add_double } } } } */
>  /* { dg-final { scan-tree-dump "Found COMPLEX_ADD_ROT270" "vect" } } */
>  /* { dg-final { scan-tree-dump "Found COMPLEX_ADD_ROT90" "vect" } } */
> diff --git a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-float.c 
> b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-float.c
> index 
> 71f391db7bba8ac7c4ce090f650c32d9180ee4f9..312df88ee689438487263bbd9e42415ba77ec456
>  100644
> --- a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-float.c
> +++ b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-float.c
> @@ -6,7 +6,7 @@
>  #define N 200
>  #include "complex-add-template.c"
>  
> -/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT270" 2 "vect" { 
> target { vect_complex_add_float } } } } */
> -/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT90" 2 "vect" { 
> target { vect_complex_add_float } } } } */
> +/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT270" 1 "vect" { 
> target { vect_complex_add_float } } } } */
> +/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT90" 1 "vect" { 
> target { vect_complex_add_float } } } } */
>  /* { dg-final { scan-tree-dump "Found COMPLEX_ADD_ROT270" "vect" } } */
>  /* { dg-final { scan-tree-dump "Found COMPLEX_ADD_ROT90" "vect" } } */
> diff --git 
> 

Re: [PATCH][_GLIBCXX_INLINE_VERSION] Fix std::random_device definition

[Jonathan Wakely via Gcc-patches]

On Thu, 28 Apr 2022 at 05:56, François Dumont via Libstdc++
 wrote:
>
> Hi
>
>  Still time for this fix for gcc 12 ?

What needs fixing?

std::random_device is already declared in the versioned namespace in
:

namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
...
  /**
   * A standard interface to a platform-specific non-deterministic
   * random number generator (if any are available).
   */
  class random_device
  {

So that means the definitions of its member functions will be exported
as std::__8::random_device::* already, the macros are not needed in
the src/*/*.cc files.

So it seems to me that the only "problem" is a redundant line in
config/abi/pre/gnu-versioned-namespace.ver. That line has no effect,
and can be removed.

I've pushed the attached patch instead.

>
>  If so I'll make sure to run tests quickly, especially the abi.exp
> one to confirm that the cleanup in gnu-versioned-namespace.ver do not
> need to be replaced by the same in __8 namespace.
>
> libstdc++: [_GLIBCXX_INLINE_VERSION] Fix std::random_device definition
>
> Definition shall be put in _GLIBCXX_BEGIN_VERSION_NAMESPACE/
> _GLIBCXX_END_VERSION_NAMESPACE like the declaration.
>
> libstdc++-v3/ChangeLog
>
>  * src/c++11/cow-string-inst.cc: Put random_device member definitions
>  in versioned namespace.
>  * src/c++11/random.cc: Likewise.
>  * config/abi/pre/gnu-versioned-namespace.ver: Remove std::random_device
>  symbols.
>
> François
commit f39fcafbc0d2c49593dd8351b87cf43da9227953
Author: François Dumont 
Date:   Thu Apr 28 10:01:14 2022

libstdc++: Remove redundant line in versioned namespace linker script

This doesn't match anything.

libstdc++-v3/ChangeLog:

* config/abi/pre/gnu-versioned-namespace.ver: Remove
std::random_device::* pattern.

diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver 
b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
index e9520a6421e..b37199ece72 100644
--- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
+++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
@@ -28,7 +28,6 @@ GLIBCXX_8.0 {
 {
   std::*;
   std::__8::*;
-  std::random_device::*
 };
 
 # operator new(size_t)

[PATCH] ipa: Release body of clone_of when removing its last clone (PR 100413)

[Martin Jambor]

Hi,

In the PR, the verifier complains that we did not manage to remove the
body of a node and it is right.  The node is kept for materialization
of two clones but after one is materialized, the other one is removed
as unneeded (as a part of delete_unreachable_blocks_update_callgraph).
The problem is that the node removal does not check for this situation
and can leave the clone_of node there with a body attached to it even
though there is no use for it any more.  This patch does checks for it
and handles the situation in a simlar way that
cgraph_node::materialize_clone does it, except that it also has to be
careful that the removed node itself does not have any clones, which
would still need the clone_of's body.  Failing to do that results in a
bootstrap failure.

Bootstrapped and tested and LTO-bootstrapped on x86_64-linux.

OK for master and GCC 11?  Or should I perhaps wait for GCC 12 to
branch and only backport to 12.2 after some time on GCC 13 master?

Thanks,

Martin


gcc/ChangeLog:

2022-04-27  Martin Jambor  

PR ipa/100413
* cgraph.cc (cgraph_node::remove): Release body of the node this
is clone_of if appropriate.

gcc/testsuite/ChangeLog:

2022-04-27  Martin Jambor  

PR ipa/100413
* g++.dg/ipa/pr100413.C: New test.
---
 gcc/cgraph.cc   |  6 ++-
 gcc/testsuite/g++.dg/ipa/pr100413.C | 64 +
 2 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr100413.C

diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
index b923a59ab0c..7a70619412b 100644
--- a/gcc/cgraph.cc
+++ b/gcc/cgraph.cc
@@ -1892,7 +1892,11 @@ cgraph_node::remove (void)
   if (prev_sibling_clone)
 prev_sibling_clone->next_sibling_clone = next_sibling_clone;
   else if (clone_of)
-clone_of->clones = next_sibling_clone;
+{
+  clone_of->clones = next_sibling_clone;
+  if (!clone_of->analyzed && !clone_of->clones && !clones)
+   clone_of->release_body ();
+}
   if (next_sibling_clone)
 next_sibling_clone->prev_sibling_clone = prev_sibling_clone;
   if (clones)
diff --git a/gcc/testsuite/g++.dg/ipa/pr100413.C 
b/gcc/testsuite/g++.dg/ipa/pr100413.C
new file mode 100644
index 000..96d71e7cf35
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr100413.C
@@ -0,0 +1,64 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c++11 -O2 -fno-guess-branch-probability 
-fno-inline-functions-called-once -fipa-cp-clone -fipa-pta 
-fnon-call-exceptions --param=ipa-cp-eval-threshold=0" } */
+
+
+template  class allocator {
+public:
+  ~allocator();
+};
+template  struct allocator_traits;
+template  struct allocator_traits> {
+  using allocator_type = allocator<_Tp>;
+  template  using rebind_alloc = allocator<_Up>;
+  static void deallocate(allocator_type);
+};
+template 
+void _Destroy(_ForwardIterator, _ForwardIterator, _Tp);
+struct __alloc_traits : allocator_traits> {
+  struct rebind {
+typedef rebind_alloc other;
+  };
+};
+struct _Vector_base {
+  struct _Vector_impl_data {
+int _M_start;
+int _M_finish;
+  };
+  struct _Vector_impl : __alloc_traits::rebind::other, _Vector_impl_data {};
+  __alloc_traits::rebind::other _M_get_Tp_allocator();
+  ~_Vector_base() { _M_deallocate(); }
+  _Vector_impl _M_impl;
+  void _M_deallocate() { __alloc_traits::deallocate(_M_impl); }
+};
+class vector : _Vector_base {
+public:
+  vector() noexcept {
+allocator __trans_tmp_1 = _M_get_Tp_allocator();
+_Destroy(_M_impl._M_start, _M_impl._M_finish, __trans_tmp_1);
+  }
+  void size();
+};
+struct HTTPCallback {
+  virtual void OnFailure();
+};
+struct ContentCallback {
+  virtual void OnDownloadProgress();
+};
+class ClientNetworkContentSocketHandler : ContentCallback, HTTPCallback {
+  vector requested;
+  vector infos;
+  vector lastActivity;
+  void OnFailure();
+public:
+  int IDLE_TIMEOUT = 0;
+  ClientNetworkContentSocketHandler();
+  void DownloadSelectedContent();
+} _network_content_client;
+void ClientNetworkContentSocketHandler::DownloadSelectedContent() {
+  vector content;
+  content.size();
+}
+void ClientNetworkContentSocketHandler::OnFailure() {
+  DownloadSelectedContent();
+}
+ClientNetworkContentSocketHandler::ClientNetworkContentSocketHandler() {}
-- 
2.36.0

[PATCH]middle-end testsuite: Backport testsuite changes from GCC 12 to GCC 11

[Tamar Christina via Gcc-patches]

Hi All,

This backports the testsuite changes from mainline to GCC 11.
This enables some tests that were not running and fix some
unresolved cases. The test output are adjusted to what GCC 11 could detect.

Regtested on aarch64-none-linux-gnu and no issues.

Ok for GCC 11?

Thanks,
Tamar

gcc/testsuite/ChangeLog:

PR testsuite/105095
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c: Update for
codegen.
* gcc.dg/vect/complex/fast-math-complex-add-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-half-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-complex-mla-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-half-float.c: Likewise.
* gcc.dg/vect/vect.exp: Add extra letter to filter.

--- inline copy of patch -- 
diff --git 
a/gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c 
b/gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c
index 
827687b92fa7a8e68bf3eaa101ab67a5d07901f3..8eb8baceb31f86d4a3c35276870769d673f1fd36
 100644
--- a/gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c
+++ b/gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c
@@ -1,10 +1,11 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_complex_add_float } */
+/* { dg-additional-options "-fno-tree-loop-vectorize" } */
 /* { dg-add-options arm_v8_3a_complex_neon } */
 
 #define TYPE float
 #define N 16
 #include "complex-mul-template.c"
 
-/* { dg-final { scan-tree-dump "Found COMPLEX_MUL_CONJ" "vect" } } */
-/* { dg-final { scan-tree-dump "Found COMPLEX_MUL" "vect" } } */
+/* { dg-final { scan-tree-dump "Found COMPLEX_MUL_CONJ" "slp1" { xfail *-*-* } 
} } */
+/* { dg-final { scan-tree-dump "Found COMPLEX_MUL" "slp1" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-double.c 
b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-double.c
index 
f935405e3d942cc68e49b2b21ca543e23076e0c9..5cff373b80d2eb8d3945ac38a656d081faea3737
 100644
--- a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-double.c
+++ b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-double.c
@@ -6,7 +6,7 @@
 #define N 200
 #include "complex-add-template.c"
 
-/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT270" 2 "vect" { 
target { vect_complex_add_double } } } } */
-/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT90" 2 "vect"  { 
target { vect_complex_add_double } } } } */
+/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT270" 1 "vect" { 
target { vect_complex_add_double } } } } */
+/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT90" 1 "vect"  { 
target { vect_complex_add_double } } } } */
 /* { dg-final { scan-tree-dump "Found COMPLEX_ADD_ROT270" "vect" } } */
 /* { dg-final { scan-tree-dump "Found COMPLEX_ADD_ROT90" "vect" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-float.c 
b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-float.c
index 
71f391db7bba8ac7c4ce090f650c32d9180ee4f9..312df88ee689438487263bbd9e42415ba77ec456
 100644
--- a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-float.c
+++ b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-float.c
@@ -6,7 +6,7 @@
 #define N 200
 #include "complex-add-template.c"
 
-/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT270" 2 "vect" { 
target { vect_complex_add_float } } } } */
-/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT90" 2 "vect" { 
target { vect_complex_add_float } } } } */
+/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT270" 1 "vect" { 
target { vect_complex_add_float } } } } */
+/* { dg-final { scan-tree-dump-times "stmt.*COMPLEX_ADD_ROT90" 1 "vect" { 
target { vect_complex_add_float } } } } */
 /* { dg-final { scan-tree-dump "Found COMPLEX_ADD_ROT270" "vect" } } */
 /* { dg-final { scan-tree-dump "Found COMPLEX_ADD_ROT90" "vect" } } */
diff --git 
a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-half-float.c 
b/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-half-float.c
index 
e5b826f1ca77d262c7d0a39b6b8446255a9dea36..046f014240bf5c88e34a9140f598ef280303c43c
 100644
--- a/gcc/testsuite/gcc.dg/vect/complex/fast-math-complex-add-half-float.c
+++ 

[PATCH 1/12] arm: Make mbranch-protection opts parsing common to AArch32/64

[Andrea Corallo via Gcc-patches]

Hi all,

This change refactors all the mbranch-protection option parsing code and
types to make it common to both AArch32 and AArch64 backends.

This change also pulls in some supporting types from AArch64 to make
it common (aarch_parse_opt_result).

The significant changes in this patch are the movement of all branch
protection parsing routines from aarch64.c to aarch-common.c and
supporting data types and static data structures.

This patch also pre-declares variables and types required in the
aarch32 back-end for moved variables for function sign scope and key
to prepare for the impending series of patches that support parsing
the feature mbranch-protection in the aarch32 back-end.

This patch implements the changes requested and was pre-approved here
.

gcc/ChangeLog:

* common/config/aarch64/aarch64-common.cc: Include aarch-common.h.
(all_architectures): Fix comment.
(aarch64_parse_extension): Rename return type, enum value names.
* config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins): Rename
factored out aarch_ra_sign_scope and aarch_ra_sign_key variables.
Also rename corresponding enum values.
* config/aarch64/aarch64-opts.h (aarch64_function_type): Factor
out aarch64_function_type and move it to common code as
aarch_function_type in aarch-common.h.
* config/aarch64/aarch64-protos.h: Include common types header,
move out types aarch64_parse_opt_result and aarch64_key_type to
aarch-common.h
* config/aarch64/aarch64.cc: Move mbranch-protection parsing types
and functions out into aarch-common.h and aarch-common.cc.  Fix up
all the name changes resulting from the move.
* config/aarch64/aarch64.md: Fix up aarch64_ra_sign_key type name change
and enum value.
* config/aarch64/aarch64.opt: Include aarch-common.h to import
type move.  Fix up name changes from factoring out common code and
data.
* config/arm/aarch-common-protos.h: Export factored out routines to both
backends.
* config/arm/aarch-common.cc: Include newly factored out types.  Move 
all
mbranch-protection code and data structures from aarch64.cc.
* config/arm/aarch-common.h: New header that declares types shared
between aarch32 and aarch64 backends.
* config/arm/arm-protos.h: Declare types and variables that are
made common to aarch64 and aarch32 backends - aarch_ra_sign_key,
aarch_ra_sign_scope and aarch_enable_bti.

Co-Authored-By: Tejas Belagod  

diff --git a/gcc/common/config/aarch64/aarch64-common.cc 
b/gcc/common/config/aarch64/aarch64-common.cc
index dfda5b8372a..70a5cf98b75 100644
--- a/gcc/common/config/aarch64/aarch64-common.cc
+++ b/gcc/common/config/aarch64/aarch64-common.cc
@@ -30,6 +30,7 @@
 #include "opts.h"
 #include "flags.h"
 #include "diagnostic.h"
+#include "config/arm/aarch-common.h"
 
 #ifdef  TARGET_BIG_ENDIAN_DEFAULT
 #undef  TARGET_DEFAULT_TARGET_FLAGS
@@ -192,11 +193,11 @@ static const struct arch_to_arch_name all_architectures[] 
=
 
 /* Parse the architecture extension string STR and update ISA_FLAGS
with the architecture features turned on or off.  Return a
-   aarch64_parse_opt_result describing the result.
+   aarch_parse_opt_result describing the result.
When the STR string contains an invalid extension,
a copy of the string is created and stored to INVALID_EXTENSION.  */
 
-enum aarch64_parse_opt_result
+enum aarch_parse_opt_result
 aarch64_parse_extension (const char *str, uint64_t *isa_flags,
 std::string *invalid_extension)
 {
@@ -229,7 +230,7 @@ aarch64_parse_extension (const char *str, uint64_t 
*isa_flags,
adding_ext = 1;
 
   if (len == 0)
-   return AARCH64_PARSE_MISSING_ARG;
+   return AARCH_PARSE_MISSING_ARG;
 
 
   /* Scan over the extensions table trying to find an exact match.  */
@@ -251,13 +252,13 @@ aarch64_parse_extension (const char *str, uint64_t 
*isa_flags,
  /* Extension not found in list.  */
  if (invalid_extension)
*invalid_extension = std::string (str, len);
- return AARCH64_PARSE_INVALID_FEATURE;
+ return AARCH_PARSE_INVALID_FEATURE;
}
 
   str = ext;
 };
 
-  return AARCH64_PARSE_OK;
+  return AARCH_PARSE_OK;
 }
 
 /* Append all architecture extension candidates to the CANDIDATES vector.  */
diff --git a/gcc/config/aarch64/aarch64-c.cc b/gcc/config/aarch64/aarch64-c.cc
index caf8e332ea0..b0c5a4fd6b6 100644
--- a/gcc/config/aarch64/aarch64-c.cc
+++ b/gcc/config/aarch64/aarch64-c.cc
@@ -183,14 +183,14 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
"__ARM_FEATURE_BTI_DEFAULT", pfile);
 
   cpp_undef (pfile, "__ARM_FEATURE_PAC_DEFAULT");
-  if (aarch64_ra_sign_scope != AARCH64_FUNCTION_NONE)
+  if (aarch_ra_sign_scope != AARCH_FUNCTION_NONE)

[PATCH 0/12] arm: Enables return address verification and branch target identification on Cortex-M

[Andrea Corallo via Gcc-patches]

Hi all,

this series enables return address verification and branch target
identification based on Armv8.1-M Pointer Authentication and Branch
Target Identification Extension [1] for Arm Cortex-M.

This feature is controlled by the newly introduced '-mbranch-protection'
option, contextually the Armv8.1-M Mainline target feature '+pacbti' is
added.

Best Regards

  Andrea

[1] 

Re: Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

[Uros Bizjak via Gcc-patches]

On Thu, Apr 28, 2022 at 10:31 AM Jakub Jelinek  wrote:
>
> Hi!
>
> I'd like to ping this patch.  I know it isn't a full week yet, but we are
> almost out of P1s and GCC 12 branching is any time now.
>
> Thanks:
> On Fri, Apr 22, 2022 at 09:25:04AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On the following testcase we emit a bogus
> > 'va_arg_tmp.5' may be used uninitialized
> > warning.  The reason is that when gimplifying the addr = 
> > statement, the va_arg_tmp temporary var for which we emit ADDR_EXPR
> > is not TREE_ADDRESSABLE, prepare_gimple_addressable emits some extra
> > code to initialize the newly addressable var from its previous value,
> > but it is a new variable which hasn't been initialized yet and will
> > be later, so we end up initializing it with uninitialized SSA_NAME:
> >   va_arg_tmp.6 = va_arg_tmp.5_14(D);
> >   addr.2_16 = _arg_tmp.6;
> >   _17 = MEM[(double *)sse_addr.4_13];
> >   MEM[(double * {ref-all})addr.2_16] = _17;
> > and with -O1 we actually don't DSE it before the warning is emitted.
> > If we make the temp TREE_ADDRESSABLE before the gimplification, then
> > this prepare_gimple_addressable path isn't taken and we effectively
> > omit the first statement above and so the bogus warning is gone.
> >
> > I went through other backends and didn't find another instance of this
> > problem.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > 2022-04-22  Jakub Jelinek  
> >
> >   PR target/105331
> >   * config/i386/i386.cc (ix86_gimplify_va_arg): Mark va_arg_tmp
> >   temporary TREE_ADDRESSABLE before trying to gimplify ADDR_EXPR
> >   of it.
> >
> >   * gcc.dg/pr105331.c: New test.

Sorry, I have no idea if this patch is correct or not.

Uros.

Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

[Jakub Jelinek via Gcc-patches]

Hi!

I'd like to ping this patch.  I know it isn't a full week yet, but we are
almost out of P1s and GCC 12 branching is any time now.

Thanks:
On Fri, Apr 22, 2022 at 09:25:04AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On the following testcase we emit a bogus
> 'va_arg_tmp.5' may be used uninitialized
> warning.  The reason is that when gimplifying the addr = 
> statement, the va_arg_tmp temporary var for which we emit ADDR_EXPR
> is not TREE_ADDRESSABLE, prepare_gimple_addressable emits some extra
> code to initialize the newly addressable var from its previous value,
> but it is a new variable which hasn't been initialized yet and will
> be later, so we end up initializing it with uninitialized SSA_NAME:
>   va_arg_tmp.6 = va_arg_tmp.5_14(D);
>   addr.2_16 = _arg_tmp.6;
>   _17 = MEM[(double *)sse_addr.4_13];
>   MEM[(double * {ref-all})addr.2_16] = _17;
> and with -O1 we actually don't DSE it before the warning is emitted.
> If we make the temp TREE_ADDRESSABLE before the gimplification, then
> this prepare_gimple_addressable path isn't taken and we effectively
> omit the first statement above and so the bogus warning is gone.
> 
> I went through other backends and didn't find another instance of this
> problem.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2022-04-22  Jakub Jelinek  
> 
>   PR target/105331
>   * config/i386/i386.cc (ix86_gimplify_va_arg): Mark va_arg_tmp
>   temporary TREE_ADDRESSABLE before trying to gimplify ADDR_EXPR
>   of it.
> 
>   * gcc.dg/pr105331.c: New test.

Jakub

Re: [PATCH] c++, coroutines: Make sure our temporaries are in a bind expr [PR105287]

[Iain Sandoe]

Hi Jason,

> On 20 Apr 2022, at 03:14, Jason Merrill  wrote:
> 
> On 4/18/22 10:02, Iain Sandoe wrote:
>> There are a few cases where we can generate a temporary that does not need
>> to be added to the coroutine frame (i.e. these are genuinely ephemeral).  The
>> intent was that unnamed temporaries should not be 'promoted' to coroutine
>> frame entries.  However there was a thinko and these were not actually ever
>> added to the bind expressions being generated for the expanded awaits.  This
>> meant that they were showing in the global namspace, leading to an empty
>> DECL_CONTEXT and the ICE reported.
>> tested on x86_64-darwin, OK for mainline? / Backports? (when?)
>> thanks,
>> Iain
>> Signed-off-by: Iain Sandoe 
>>  PR c++/105287
>> gcc/cp/ChangeLog:
>>  * coroutines.cc (maybe_promote_temps): Ensure generated temporaries
>>  are added to the bind expr.
>>  (add_var_to_bind): Fix local var naming to use portable punctuation.
>>  (register_local_var_uses): Do not add synthetic names to unnamed
>>  temporaries.
>> gcc/testsuite/ChangeLog:
>>  * g++.dg/coroutines/pr105287.C: New test.
>> ---
>>  gcc/cp/coroutines.cc   | 17 
>>  gcc/testsuite/g++.dg/coroutines/pr105287.C | 48 ++
>>  2 files changed, 56 insertions(+), 9 deletions(-)
>>  create mode 100644 gcc/testsuite/g++.dg/coroutines/pr105287.C
>> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
>> index a9ce6e050dd..dcc2284171b 100644
>> --- a/gcc/cp/coroutines.cc
>> +++ b/gcc/cp/coroutines.cc
>> @@ -3103,7 +3103,7 @@ maybe_promote_temps (tree *stmt, void *d)
>>   If the initializer is a conditional expression, we need to collect
>>   and declare any promoted variables nested within it.  DTORs for such
>>   variables must be run conditionally too.  */
>> -  if (t->var && DECL_NAME (t->var))
>> +  if (t->var)
>>  {
>>tree var = t->var;
>>DECL_CHAIN (var) = vlist;
>> @@ -3304,7 +3304,7 @@ add_var_to_bind (tree& bind, tree var_type,
>>tree b_vars = BIND_EXPR_VARS (bind);
>>/* Build a variable to hold the condition, this will be included in the
>>   frame as a local var.  */
>> -  char *nam = xasprintf ("%s.%d", nam_root, nam_vers);
>> +  char *nam = xasprintf ("`__%s_%d", nam_root, nam_vers);
> 
> ` is portable?

nope, it’s a typo - apparently accepted by GAS and Darwin’s assembler tho… 
thanks for catching that.

>>tree newvar = build_lang_decl (VAR_DECL, get_identifier (nam), var_type);
>>free (nam);
>>DECL_CHAIN (newvar) = b_vars;
>> @@ -3949,7 +3949,7 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
>> void *d)
>>   scopes with identically named locals and still be able to
>>   identify them in the coroutine frame.  */
>>tree lvname = DECL_NAME (lvar);
>> -  char *buf;
>> +  char *buf = NULL;
>>/* The outermost bind scope contains the artificial variables that
>>   we inject to implement the coro state machine.  We want to be able
>> @@ -3959,14 +3959,13 @@ register_local_var_uses (tree *stmt, int 
>> *do_subtree, void *d)
>>else if (lvname != NULL_TREE)
>>  buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
>>   lvd->nest_depth, lvd->bind_indx);
>> -  else
>> -buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
>> - lvd->bind_indx);
>>/* TODO: Figure out if we should build a local type that has any
>>   excess alignment or size from the original decl.  */
>> -  local_var.field_id
>> -= coro_make_frame_entry (lvd->field_list, buf, lvtype, lvd->loc);
>> -  free (buf);
>> +  if (buf) {
> 
> Brace should be on the next line.

that was careless, too much rushing, fixed as below,
OK now?
thanks
Iain

- 

[PATCH] c++, coroutines: Make sure our temporaries are in a bind expr
 [PR105287]

There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral).  The
intent was that unnamed temporaries should not be 'promoted' to coroutine
frame entries.  However there was a thinko and these were not actually ever
added to the bind expressions being generated for the expanded awaits.  This
meant that they were showing in the global namspace, leading to an empty
DECL_CONTEXT and the ICE reported.

Signed-off-by: Iain Sandoe 

PR c++/105287

gcc/cp/ChangeLog:

* coroutines.cc (maybe_promote_temps): Ensure generated temporaries
are added to the bind expr.
(add_var_to_bind): Fix local var naming to use portable punctuation.
(register_local_var_uses): Do not add synthetic names to unnamed
temporaries.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105287.C: New test.
---
 gcc/cp/coroutines.cc   | 18 
 gcc/testsuite/g++.dg/coroutines/pr105287.C | 48 ++
 

Re: [PATCH] c++, coroutines: Avoid expanding within templates [PR103868]

[Iain Sandoe]

Hi Jason,

> On 20 Apr 2022, at 04:45, Jason Merrill  wrote:
> 
> On 4/18/22 15:49, Eric Gallager via Gcc-patches wrote:
>> On Mon, Apr 18, 2022 at 10:01 AM Iain Sandoe via Gcc-patches
>>  wrote:
>>> 
>>> From: Nathan Sidwell 
>>> 
>>> This is a forward-port of a patch by Nathan (against 10.x) which fixes an 
>>> open
>>> PR.
>>> 
>>> We are ICEing because we ended up tsubst_copying something that had already
>>> been tsubst, leading to an assert failure (mostly such repeated tsubsting is
>>> harmless).
> 
> I wouldn't say "mostly".  It should always be avoided, it frequently causes 
> problems.  Pretty much any time there's a class prvalue.
> 
>>> We had a non-dependent co_await in a non-dependent-type template fn, so we
>>> processed it at definition time, and then reprocessed at instantiation time.
>>> We fix this here by deferring substitution while processing templates.
>>> 
>>> Additional observations (for a better future fix, in the GCC13 timescale):
>>> 
>>> Exprs only have dependent type if at least one operand is dependent which 
>>> was
>>> what the current code was intending to do.  Coroutines have the additional
>>> wrinkle, that the current fn's type is an implicit operand.
>>> 
>>> So, if the coroutine function's type is not dependent, and the operand is 
>>> not
>>> dependent, we should determine the type of the co_await expression using the
>>> DEPENDENT_EXPR wrapper machinery.  That allows us to determine the
>>> subexpression type, but leave its operand unchanged and then instantiate it
>>> later.
> 
> Sure, like what build_x_binary_op and the like do.
> 
>>> Tested on x86_64-darwin (it does also fix the original testcase, but that is
>>> far too time-consuming for the testsuite).
> 
> The compiler change seems fine as a temporary workaround.  Is it not feasible 
> to write a new short testcase that reproduces the problem, now that you 
> understand it?

With the fix it was possible to write a reduction test that fails for the bad 
compiler and passes for the fixed without other issues.  Threw that at cvice 
and we have now a 149 line test which is quick to run.

OK now?
thanks
Iain

From: Nathan Sidwell 
Date: Sun, 3 Apr 2022 11:35:03 +0100
Subject: [PATCH] c++, coroutines: Avoid expanding within templates [PR103868]

This is a forward-port of a patch by Nathan (against 10.x) which fixes an open
PR.

We are ICEing because we ended up tsubst_copying something that had already
been tsubst, leading to an assert failure (mostly such repeated tsubsting is
harmless).

We had a non-dependent co_await in a non-dependent-type template fn, so we
processed it at definition time, and then reprocessed at instantiation time.
We fix this here by deferring substitution while processing templates.

Additional observations (for a better future fix, in the GCC13 timescale):

Exprs only have dependent type if at least one operand is dependent which was
what the current code was intending to do.  Coroutines have the additional
wrinkle, that the current fn's type is an implicit operand.

So, if the coroutine function's type is not dependent, and the operand is not
dependent, we should determine the type of the co_await expression using the
DEPENDENT_EXPR wrapper machinery.  That allows us to determine the
subexpression type, but leave its operand unchanged and then instantiate it
later.

PR c++/103868

gcc/cp/ChangeLog:

* coroutines.cc (finish_co_await_expr): Do not process non-dependent
coroutine expressions at template definition time.
(finish_co_yield_expr): Likewise.
(finish_co_return_stmt): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr103868.C: New test.

Co-Authored-by: Iain Sandoe 
---
 gcc/cp/coroutines.cc   |  18 +--
 gcc/testsuite/g++.dg/coroutines/pr103868.C | 150 +
 2 files changed, 156 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr103868.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index cdf6503c4d3..a9ce6e050dd 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1148,10 +1148,8 @@ finish_co_await_expr (location_t kw, tree expr)
  extraneous warnings during substitution.  */
   suppress_warning (current_function_decl, OPT_Wreturn_type);
 
-  /* If we don't know the promise type, we can't proceed, build the
- co_await with the expression unchanged.  */
-  tree functype = TREE_TYPE (current_function_decl);
-  if (dependent_type_p (functype) || type_dependent_expression_p (expr))
+  /* Defer processing when we have dependent types.  */
+  if (processing_template_decl)
 {
   tree aw_expr = build5_loc (kw, CO_AWAIT_EXPR, unknown_type_node, expr,
 NULL_TREE, NULL_TREE, NULL_TREE,
@@ -1222,10 +1220,8 @@ finish_co_yield_expr (location_t kw, tree expr)
  extraneous warnings during substitution.  */
   suppress_warning (current_function_decl, OPT_Wreturn_type);
 
-  /* If we don't know 

Re: [PATCH] cgraph: Don't verify semantic_interposition flag for aliases [PR105399]

[Richard Biener via Gcc-patches]

On Thu, 28 Apr 2022, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase ICEs, because the ctors during cc1plus all have
> !opt_for_fn (decl, flag_semantic_interposition) - they have NULL
> DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) and optimization_default_node
> is for -Ofast and so has flag_semantic_interposition cleared.
> During free lang data, we set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
> for the ctor which has body (or for thunks), but don't touch it for
> aliases.
> During lto1 optimization_default_node reflects the lto1 flags which
> are -O2 rather than -Ofast and so has flag_semantic_interposition
> set, for the ctor which has body that makes no difference, but as the
> alias doesn't still have DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) set,
> we now trigger this verification check.
> 
> The following patch just doesn't verify it for aliases during lto1.
> Another possibility would be to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
> during free lang data even for aliases.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2022-04-28  Jakub Jelinek  
> 
>   PR lto/105399
>   * cgraph.cc (cgraph_node::verify_node): Don't verify
>   semantic_interposition flag against
>   opt_for_fn (decl, flag_semantic_interposition) for aliases in lto1.
> 
>   * g++.dg/lto/pr105399_0.C: New test.
> 
> --- gcc/cgraph.cc.jj  2022-04-20 09:24:12.194579146 +0200
> +++ gcc/cgraph.cc 2022-04-27 11:53:52.102173154 +0200
> @@ -3488,7 +3488,9 @@ cgraph_node::verify_node (void)
>"returns a pointer");
>error_found = true;
>  }
> -  if (definition && externally_visible
> +  if (definition
> +  && externally_visible
> +  && (!alias || thunk || !in_lto_p)

Can you add a comment above this?

OK with this if Honza doesn't have any suggestions today.

Richard.

>&& semantic_interposition
>!= opt_for_fn (decl, flag_semantic_interposition))
>  {
> --- gcc/testsuite/g++.dg/lto/pr105399_0.C.jj  2022-04-27 11:54:25.659703199 
> +0200
> +++ gcc/testsuite/g++.dg/lto/pr105399_0.C 2022-04-27 11:48:31.387664565 
> +0200
> @@ -0,0 +1,9 @@
> +// PR lto/105399
> +// { dg-lto-do link }
> +// { dg-lto-options { { -fPIC -flto -Ofast } } }
> +// { dg-require-effective-target shared }
> +// { dg-require-effective-target fpic }
> +// { dg-extra-ld-options "-shared -O2" }
> +
> +struct S { S (); };
> +S::S () {}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)

Re: [PATCH] testsuite: vect: update unaligned message

[Richard Biener via Gcc-patches]

On Thu, 28 Apr 2022, Alexandre Oliva wrote:

> 
> gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c covers ppc variants
> that accept and reject misaligned accesses.  The message that it
> expects for rejection was removed in the gcc-11 development cycle by
> commit r11-1969.  The patch adjusted multiple tests to use the message
> introduced in r11-1945, but missed this one.
> 
> Regstrapped on powerpc64el-linux-gnu.  Ok to install?
> 
> Also tested on x86_64-linux-gnu-x-ppc64-vx7r2 with gcc-11.  Ok for
> gcc-11?

OK.

> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Update
>   the expected message for the case in which unaligned accesses
>   are not allowed.
> ---
>  .../gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c 
> b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
> index 72b4930d9bbbe..c57f065cccdd6 100644
> --- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
> +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
> @@ -46,5 +46,5 @@ int main (void)
>return main1 ();
>  } 
>  
> -/* { dg-final { scan-tree-dump-times "not vectorized: unsupported unaligned 
> store" 1 "vect" { target { ! vect_hw_misalign } } } } */
> +/* { dg-final { scan-tree-dump-times "unsupported unaligned access" 1 "vect" 
> { target { ! vect_hw_misalign } } } } */
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target 
> { ! vect_hw_misalign } } } } */
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)

Re: [patch, fortran, doc] Mention new CONVERT options for POWER

[Richard Biener via Gcc-patches]

On Wed, Apr 27, 2022 at 10:34 PM Thomas Koenig via Fortran
 wrote:
>
> Hi,
>
> as we say in German "Nicht documentiert ist nicht gemacht", if
> it is not documented, it wasn't done.
>
> So I thought it would be time to document the changes to the various
> ways of specifying CONVERT before gcc12 went out of the door, so
> here is a patch for that.
>
> If that goes in, I will also write up something for gcc-12/changes.html.
>
> OK for trunk?  Suggestions for improvements?

OK for trunk.

Richard.

> Best regards
>
> Thomas
>
> Document changes to CONVERT for -mabi-ieeelongdouble for POWER
>
> gcc/fortran/ChangeLog:
>
> * gfortran.texi: Mention r16_ieee and r16_ibm.
> * invoke.texi: Likewise.

Re: Unreviewed D doc patch

[Richard Biener via Gcc-patches]

On Wed, Apr 27, 2022 at 6:27 PM Rainer Orth  
wrote:
>
> The following patch
>
> doc: Document Solaris D bootstrap requirements [PR 103528]
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591844.html
>
> has remained unreviewed for 6 weeks now, despite a reminder.  It would
> be good to get this into GCC 12.

OK.

Thanks,
Richard.

> Thanks.
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH] middle-end/105376 - invalid REAL_CST for DFP constant

[Richard Biener via Gcc-patches]

We are eventually ICEing in decimal_to_decnumber on non-decimal
REAL_VALUE_TYPE that creep in from uses of build_real (..., dconst*)
for DFP types.  The following extends the decimal_to_decnumber
special-casing of dconst* to build_real, avoiding the bogus REAL_CSTs
from creeping into the IL and modified to ones not handled by
the decimal_to_decnumber special casing.  It also makes sure to
ICE for not handled dconst* values at the point we build the REAL_CST.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for stage1
and eventual backporting (I'm considering making the gcc_unreachable
conditional on flag_checking on release branches).

Thanks,
Richard.

2022-04-27  Richard Biener  

PR middle-end/105376
* tree.cc (build_real): Special case dconst* arguments
for decimal floating point types.

* gcc.dg/pr105376.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr105376.c |  9 +
 gcc/tree.cc | 21 +
 2 files changed, 30 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr105376.c

diff --git a/gcc/testsuite/gcc.dg/pr105376.c b/gcc/testsuite/gcc.dg/pr105376.c
new file mode 100644
index 000..f19ecf4aab2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr105376.c
@@ -0,0 +1,9 @@
+/* { dg-do compile { target dfp } } */
+/* { dg-options "-O -g" } */
+
+void
+foo (_Decimal64 d, _Decimal64 e)
+{
+  d -= -d;
+  d *= -e;
+}
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 3c39be4f501..4cf3785270b 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -70,6 +70,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "escaped_string.h"
 #include "gimple-range.h"
 #include "gomp-constants.h"
+#include "dfp.h"
 
 /* Tree code classes.  */
 
@@ -2383,6 +2384,26 @@ build_real (tree type, REAL_VALUE_TYPE d)
   REAL_VALUE_TYPE *dp;
   int overflow = 0;
 
+  /* dconst{1,2,m1,half} are used in various places in
+ the middle-end and optimizers, allow them here
+ even for decimal floating point types as an exception
+ by converting them to decimal.  */
+  if (DECIMAL_FLOAT_MODE_P (TYPE_MODE (type))
+  && d.cl == rvc_normal
+  && !d.decimal)
+{
+  if (memcmp (, , sizeof (d)) == 0)
+   decimal_real_from_string (, "1");
+  else if (memcmp (, , sizeof (d)) == 0)
+   decimal_real_from_string (, "2");
+  else if (memcmp (, , sizeof (d)) == 0)
+   decimal_real_from_string (, "-1");
+  else if (memcmp (, , sizeof (d)) == 0)
+   decimal_real_from_string (, "0.5");
+  else
+   gcc_unreachable ();
+}
+
   /* ??? Used to check for overflow here via CHECK_FLOAT_TYPE.
  Consider doing it via real_convert now.  */
 
-- 
2.34.1

[PATCH] libstdc++: ppc: conditionalize vsx-only simd intrinsics

[Alexandre Oliva via Gcc-patches]

libstdc++'s bits/simd.h section for PPC (Altivec) defines various
intrinsic vector types that are only available along with VSX: 64-bit
long double, double, (un)signed long long, and 64-bit (un)signed long.

experimental/simd/standard_abi_usable{,_2}.cc tests error out reporting
the unmet requirements when the target cpu doesn't enable VSX.  Make the
reported instrinsic types conditional on VSX so that 
can be used on ppc variants that do not have VSX support.

Regstrapped on powerpc64el-linux-gnu.  Ok to install?

This is also relevant for gcc-11.  Tested with
x86_64-linux-gnu-x-ppc64-vx7r2.  Ok for gcc-11?


for  libstdc++-v3/ChangeLog

* include/experimental/bits/simd.h [__ALTIVEC__]: Require VSX
for double, long long, and 64-bit long and 64-bit long double
intrinsic types.
---
 libstdc++-v3/include/experimental/bits/simd.h |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/experimental/bits/simd.h 
b/libstdc++-v3/include/experimental/bits/simd.h
index 82e9841195e1d..66c07127ec435 100644
--- a/libstdc++-v3/include/experimental/bits/simd.h
+++ b/libstdc++-v3/include/experimental/bits/simd.h
@@ -2430,17 +2430,23 @@ template 
   template <>  
\
 struct __intrinsic_type_impl<_Tp> { using type = __vector _Tp; }
 _GLIBCXX_SIMD_PPC_INTRIN(float);
+# ifdef __VSX__
 _GLIBCXX_SIMD_PPC_INTRIN(double);
+# endif
 _GLIBCXX_SIMD_PPC_INTRIN(signed char);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned char);
 _GLIBCXX_SIMD_PPC_INTRIN(signed short);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned short);
 _GLIBCXX_SIMD_PPC_INTRIN(signed int);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned int);
+# if defined __VSX__ || __LONG_WIDTH__ == 32
 _GLIBCXX_SIMD_PPC_INTRIN(signed long);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned long);
+# endif
+# ifdef __VSX__
 _GLIBCXX_SIMD_PPC_INTRIN(signed long long);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned long long);
+# endif
 #undef _GLIBCXX_SIMD_PPC_INTRIN
 
 template 
@@ -2452,8 +2458,9 @@ template 
 static_assert(!(_S_is_ldouble && sizeof(long double) > sizeof(double)),
  "no __intrinsic_type support for long double on PPC");
 #ifndef __VSX__
-static_assert(!is_same_v<_Tp, double>,
- "no __intrinsic_type support for double on PPC w/o VSX");
+static_assert(!(is_same_v<_Tp, double>
+   || (_S_is_ldouble && sizeof(long double) == 
sizeof(double))),
+ "no __intrinsic_type support for [long] double on PPC w/o 
VSX");
 #endif
 using type =
   typename __intrinsic_type_impl<


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH][stage1] Embed real_value into REAL_CST

[Richard Biener via Gcc-patches]

The following removes the indirection to real_value from REAL_CST
which doesn't seem to serve any useful purpose.  Any sharing can
be achieved by sharing the actual REAL_CST (which is what usually
happens when copying trees) and sharing of real_value amongst
different REAL_CST doesn't happen as far as I can see and would
only lead to further issues like mismatching type and real_value.

Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.

Richard.

2022-04-27  Richard Biener  

* tree-core.h (tree_real_cst::real_cst_ptr): Remove pointer
to real_value field.
(tree_real_cst::value): Add real_value field.
* tree.h (TREE_REAL_CST_PTR): Adjust.
* tree.cc (build_real): Remove separate allocation.
* tree-streamer-in.cc (unpack_ts_real_cst_value_fields):
Likewise.

cp/
* module.cc (trees_in::core_vals): Remove separate allocation
for REAL_CST.
---
 gcc/cp/module.cc| 4 +---
 gcc/tree-core.h | 2 +-
 gcc/tree-streamer-in.cc | 5 +
 gcc/tree.cc | 6 +-
 gcc/tree.h  | 2 +-
 5 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index cebf9c35c1d..18dabfcc9ac 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -6468,9 +6468,7 @@ trees_in::core_vals (tree t)
 
 case REAL_CST:
   if (const void *bytes = buf (sizeof (real_value)))
-   TREE_REAL_CST_PTR (t)
- = reinterpret_cast (memcpy (ggc_alloc (),
-   bytes, sizeof 
(real_value)));
+   memcpy (TREE_REAL_CST_PTR (t), bytes, sizeof (real_value));
   break;
 
 case STRING_CST:
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index f1c2b6413a3..cb4cefd369b 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1461,7 +1461,7 @@ struct GTY(()) tree_int_cst {
 
 struct GTY(()) tree_real_cst {
   struct tree_typed typed;
-  struct real_value * real_cst_ptr;
+  struct real_value value;
 };
 
 struct GTY(()) tree_fixed_cst {
diff --git a/gcc/tree-streamer-in.cc b/gcc/tree-streamer-in.cc
index a35a810f4d1..196f19c759f 100644
--- a/gcc/tree-streamer-in.cc
+++ b/gcc/tree-streamer-in.cc
@@ -190,7 +190,6 @@ unpack_ts_real_cst_value_fields (struct bitpack_d *bp, tree 
expr)
 {
   unsigned i;
   REAL_VALUE_TYPE r;
-  REAL_VALUE_TYPE *rp;
 
   /* Clear all bits of the real value type so that we can later do
  bitwise comparisons to see if two values are the same.  */
@@ -204,9 +203,7 @@ unpack_ts_real_cst_value_fields (struct bitpack_d *bp, tree 
expr)
   for (i = 0; i < SIGSZ; i++)
 r.sig[i] = (unsigned long) bp_unpack_value (bp, HOST_BITS_PER_LONG);
 
-  rp = ggc_alloc ();
-  memcpy (rp, , sizeof (REAL_VALUE_TYPE));
-  TREE_REAL_CST_PTR (expr) = rp;
+  memcpy (TREE_REAL_CST_PTR (expr), , sizeof (REAL_VALUE_TYPE));
 }
 
 
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 3c39be4f501..1d2cdc82aba 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -2380,18 +2380,14 @@ tree
 build_real (tree type, REAL_VALUE_TYPE d)
 {
   tree v;
-  REAL_VALUE_TYPE *dp;
   int overflow = 0;
 
   /* ??? Used to check for overflow here via CHECK_FLOAT_TYPE.
  Consider doing it via real_convert now.  */
 
   v = make_node (REAL_CST);
-  dp = ggc_alloc ();
-  memcpy (dp, , sizeof (REAL_VALUE_TYPE));
-
   TREE_TYPE (v) = type;
-  TREE_REAL_CST_PTR (v) = dp;
+  memcpy (TREE_REAL_CST_PTR (v), , sizeof (REAL_VALUE_TYPE));
   TREE_OVERFLOW (v) = overflow;
   return v;
 }
diff --git a/gcc/tree.h b/gcc/tree.h
index 8844471e9a5..82eb8ba39d2 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -1048,7 +1048,7 @@ extern void omp_clause_range_check_failed (const_tree, 
const char *, int,
 #define POLY_INT_CST_COEFF(NODE, I) \
   (POLY_INT_CST_CHECK (NODE)->poly_int_cst.coeffs[I])
 
-#define TREE_REAL_CST_PTR(NODE) (REAL_CST_CHECK (NODE)->real_cst.real_cst_ptr)
+#define TREE_REAL_CST_PTR(NODE) (_CST_CHECK (NODE)->real_cst.value)
 #define TREE_REAL_CST(NODE) (*TREE_REAL_CST_PTR (NODE))
 
 #define TREE_FIXED_CST_PTR(NODE) \
-- 
2.34.1

[PATCH] testsuite: vect: update unaligned message

[Alexandre Oliva via Gcc-patches]

gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c covers ppc variants
that accept and reject misaligned accesses.  The message that it
expects for rejection was removed in the gcc-11 development cycle by
commit r11-1969.  The patch adjusted multiple tests to use the message
introduced in r11-1945, but missed this one.

Regstrapped on powerpc64el-linux-gnu.  Ok to install?

Also tested on x86_64-linux-gnu-x-ppc64-vx7r2 with gcc-11.  Ok for
gcc-11?


for  gcc/testsuite/ChangeLog

* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Update
the expected message for the case in which unaligned accesses
are not allowed.
---
 .../gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
index 72b4930d9bbbe..c57f065cccdd6 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
@@ -46,5 +46,5 @@ int main (void)
   return main1 ();
 } 
 
-/* { dg-final { scan-tree-dump-times "not vectorized: unsupported unaligned 
store" 1 "vect" { target { ! vect_hw_misalign } } } } */
+/* { dg-final { scan-tree-dump-times "unsupported unaligned access" 1 "vect" { 
target { ! vect_hw_misalign } } } } */
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target { 
! vect_hw_misalign } } } } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about