Re: [PATCH] PR target/97250: i386: Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64

[Matthias Klose]

On 9/30/20 2:27 PM, Florian Weimer wrote:
> These micro-architecture levels are defined in the x86-64 psABI:
> 
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9
> 
> PTA_NO_TUNE is introduced so that the new processor alias table entries
> do not affect the CPU tuning setting in ix86_tune.
> 
> The tests depend on the macros added in commit 92e652d8c21bd7e66cbb0f900
> ("i386: Define __LAHF_SAHF__ and __MOVBE__ macros, based on ISA flags").


I would like to see this series backported to the gcc-10 branch (already doing
that for distro builds). With the backport for PR target/95842 from March 30,
these can now be backported without changes: That consists of:

i386: Define __LAHF_SAHF__ and __MOVBE__ macros, based on ISA flags
commit 92e652d8c21bd7e66cbb0f9001542a2f55345af0

Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
commit 324bec558e95584e8c1997575ae9d75978af59f1

Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
commit 16664e6e4fb4281be6477c13989740d44c963c77

Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
commit 552ed3ea761324bdd42c1a40d4bbef91432da29a

i386: Make -march=x86-64-v[234] behave more like other -march= options
commit 59482fa1e7243bd905c7e27c92ae2b89c79fff87

and

Fix up plugin header install
9a83366b62e585cce5577309013a832f895ccdbf

the latter one needed anyway on the gcc-10 branch.

I know, it's late, but the PR target/95842 backport only happened two days ago.

Matthias

Re: [PATCH] data-ref: Tighten index-based alias checks [PR99726]

[Jakub Jelinek via Gcc-patches]

On Wed, Mar 31, 2021 at 11:15:08AM +0100, Richard Sandiford via Gcc-patches 
wrote:
> gcc/testsuite/
>   PR tree-optimization/99726
>   * gcc.target/i386/pr99726.c: New test.

-m32 shouldn't be used in gcc.target/i386/ testcases, people do
test with -m32/-m64 to get 32-bit compilation tested.
And, -floop-nest-optimize is a graphite optimization, so might not
be enabled in all gcc builds.

Tested on x86_64-linux -m32/-m64, committed to trunk.

2021-04-02  Jakub Jelinek  

PR tree-optimization/99726
* gcc.target/i386/pr99726.c: Remove -m32 from dg-options.  Move
-floop-nest-optimize to dg-additional-options guarded on fgraphite
effective target.

--- gcc/testsuite/gcc.target/i386/pr99726.c.jj  2021-03-31 21:25:20.447714222 
+0200
+++ gcc/testsuite/gcc.target/i386/pr99726.c 2021-04-02 10:04:01.492401220 
+0200
@@ -1,4 +1,5 @@
-/* { dg-options "-flive-patching=inline-clone -mavx512f -O2 
-floop-nest-optimize -ftree-loop-vectorize -ftrapv -m32" } */
+/* { dg-options "-flive-patching=inline-clone -mavx512f -O2 
-ftree-loop-vectorize -ftrapv" } */
+/* { dg-additional-options "-floop-nest-optimize" { target fgraphite } } */
 
 extern int a[256][1024];
 int b;

Jakub

Re: [PATCH] PR target/97250: i386: Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64

[Richard Biener via Gcc-patches]

On April 2, 2021 10:00:53 AM GMT+02:00, Matthias Klose  wrote:
>On 9/30/20 2:27 PM, Florian Weimer wrote:
>> These micro-architecture levels are defined in the x86-64 psABI:
>> 
>>
>https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9
>> 
>> PTA_NO_TUNE is introduced so that the new processor alias table
>entries
>> do not affect the CPU tuning setting in ix86_tune.
>> 
>> The tests depend on the macros added in commit
>92e652d8c21bd7e66cbb0f900
>> ("i386: Define __LAHF_SAHF__ and __MOVBE__ macros, based on ISA
>flags").
>
>
>I would like to see this series backported to the gcc-10 branch
>(already doing
>that for distro builds). With the backport for PR target/95842 from
>March 30,
>these can now be backported without changes: That consists of:
>
>i386: Define __LAHF_SAHF__ and __MOVBE__ macros, based on ISA flags
>commit 92e652d8c21bd7e66cbb0f9001542a2f55345af0
>
>Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
>commit 324bec558e95584e8c1997575ae9d75978af59f1
>
>Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
>commit 16664e6e4fb4281be6477c13989740d44c963c77
>
>Add support for x86-64-v2, x86-64-v3, x86-64-v4 levels for x86-64
>commit 552ed3ea761324bdd42c1a40d4bbef91432da29a
>
>i386: Make -march=x86-64-v[234] behave more like other -march= options
>commit 59482fa1e7243bd905c7e27c92ae2b89c79fff87
>
>and
>
>Fix up plugin header install
>9a83366b62e585cce5577309013a832f895ccdbf
>
>the latter one needed anyway on the gcc-10 branch.
>
>I know, it's late, but the PR target/95842 backport only happened two
>days ago.

This can be done after the 10.3 release if really necessary. 

Richard. 

>Matthias

Re: [gcc r11-7940] Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

[Andreas Schwab]

On Mär 31 2021, Jan Hubicka via Gcc-cvs wrote:

> https://gcc.gnu.org/g:e7fd3b783238d034018443e43a58ff87908b4db6
>
> commit r11-7940-ge7fd3b783238d034018443e43a58ff87908b4db6
> Author: Jan Hubicka 
> Date:   Wed Mar 31 22:44:20 2021 +0200
>
> Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL
> 
> USES_COMDAT_LOCAL is incorrectly defined as CIF_FINAL_ERROR which makes 
> inliner
> to mis some inlines of functions in comdat section that was previously 
> split.
> 
> 2021-03-31  Jan Hubicka  
> 
> PR ipa/98265
> * cif-code.def (USES_COMDAT_LOCAL): Make CIF_FINAL_NORMAL.

This breaks bootstrap on riscv64:

In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool 
’,
inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at 
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + 
offsetof(alloca_type_and_limit, 
alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::val[0]))’
 may be used uninitialized  -Werror=maybe-uninitialized]
  206 | ret = alloca_type_and_limit (ALLOCA_OK);
  | ^~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int 
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
  |^~~
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool 
’,
inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at 
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + 
offsetof(alloca_type_and_limit, 
alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::val[1]))’
 may be used uninitialized  -Werror=maybe-uninitialized]
  206 | ret = alloca_type_and_limit (ALLOCA_OK);
  | ^~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int 
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
  |^~~
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool 
’,
inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at 
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + 
offsetof(alloca_type_and_limit, 
alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::val[2]))’
 may be used uninitialized  -Werror=maybe-uninitialized]
  206 | ret = alloca_type_and_limit (ALLOCA_OK);
  | ^~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int 
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
  |^~~
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool 
’,
inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at 
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(unsigned int*)((char*)&ret 
+ offsetof(alloca_type_and_limit, 
alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::len))’
 may be used uninitialized [-Werror=maybe-uninitialized]
  206 | ret = alloca_type_and_limit (ALLOCA_OK);
  | ^~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int 
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
  |^~~
In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool 
’,
inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at 
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(unsigned int*)((char*)&ret 
+ offsetof(alloca_type_and_limit, 
alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::precision))’
 may be used uninitialized [-Werror=maybe-uninitialized]
  206 | ret = alloca_type_and_limit (ALLOCA_OK);
  | ^~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int 
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
  200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
  |^~~
cc1p

Re: RFC: Sphinx for GCC documentation

[Martin Sebor via Gcc-patches]

On 4/1/21 7:30 AM, Martin Liška wrote:

Hey.

I've returned to the David's project and I'm willing to finish his transition 
effort.
I believe using Sphinx documentation can rapidly improve readability, both HTML 
and PDF version,
of various GCC manuals ([1]). I've spent some time working on the David's 
texi2rsf conversion tool ([2])
and I'm presenting a result that is not perfect, but can be acceptable after a 
reasonable
amount of manual modifications.

So far I focused on the 2 biggest manuals we have:

(1) User documentation
https://splichal.eu/sphinx/
https://splichal.eu/sphinx/gcc.pdf

(2) GCC Internals Manual
https://splichal.eu/sphinx-internal
https://splichal.eu/sphinx-internal/gccint.pdf

I'm aware of missing pieces (thanks Joseph) and I'm willing to finish it.

That said, I'm asking the GCC community for a green light before I invest
more time on it?


I like the output quite a bit, especially that things like option
references are automagically linked to their documentation.  I spent
just a bit of time looking through the HTML and PDF above and found
a few minor issues.  I suspect they're due to the conversion script
not being finished yet but just to confirm please see below.

Is the source we'd work with the same as what shows up when I click
the 'View page source' link?  (Or is there some preprocessing involved?)

I'm not excited about changing tools.  I like that Texinfo is a GNU
project; AFACT, Sphinx is not.  In the original thread David linked
to there was a suggestion to use Texinfo and Sphinx side by side.
I.e., keep .texi as the master source format and generate the .rst
files using the conversion script on demand.  Would making that
the first step of the transition be a viable option?  (With the idea
of giving it a try and deciding whether to convert after some time?)

Martin

[*] The linking doesn't always seem to work (e.g.,
:option:`-fabi-version=4` under -Wabi).  I'm guessing it's not yet
done in the conversion script (or there's no -fabi-version=4 in
the index) and not a Sphinx limitation.

It doesn't add links for attributes but presumably that could also
be made to happen in the conversion, right?

It doesn't seem to preserve newlines in long lists of options (like
under -Wall), so the result is just one long running series of options
that's hard (for me) to follow. Presumably there's a way to do that
too (add a newline after each :option?)

It mentions both the positive and the negative forms of options as
headings (like -Wmain, -Wno-main).  That seems superflous and, with
very long option names (I noticed this for example with
-Wno-analyzer-use-of-pointer-in-stale-stack-frame) the heading in
the PDF can run off the right edge of the page.  But based on
the source it also looks like it should be easy to adjust in
the conversion script if we wanted to keep just one form, right?




Cheers,
Martin

[1] https://gcc.gnu.org/onlinedocs/
[2] https://github.com/davidmalcolm/texi2rst

Re: [gcc r11-7940] Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

[Jan Hubicka]

> This breaks bootstrap on riscv64:
> 
> In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, 
> bool ’,
> inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at 
> ../../gcc/gimple-ssa-warn-alloca.c:295:25:
> ../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + 
> offsetof(alloca_type_and_limit, 
> alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::val[0]))’
>  may be used uninitialized  -Werror=maybe-uninitialized]
>   206 | ret = alloca_type_and_limit (ALLOCA_OK);
>   | ^~~
> ../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int 
> pass_walloca::execute(function*)’:
> ../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
>   200 |   struct alloca_type_and_limit ret = alloca_type_and_limit 
> (ALLOCA_OK);
>   |^~~

This looks like a false positive implied by different inlining
decisions.  Would it be posible to have preprocessed source + the
tripplet to configure a cross-compiler?

Thanks,
Honza

Re: [gcc r11-7940] Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

[Martin Sebor via Gcc-patches]

On 4/2/21 9:40 AM, Jan Hubicka wrote:

This breaks bootstrap on riscv64:

In function ‘alloca_type_and_limit alloca_call_type(range_query&, gimple*, bool 
’,
 inlined from ‘virtual unsigned int pass_walloca::execute(function*)’ at 
../../gcc/gimple-ssa-warn-alloca.c:295:25:
../../gcc/gimple-ssa-warn-alloca.c:206:13: error: ‘*(long int*)((char*)&ret + 
offsetof(alloca_type_and_limit, 
alloca_type_and_limit::limit.generic_wide_int::.wide_int_storage::val[0]))’
 may be used uninitialized  -Werror=maybe-uninitialized]
   206 | ret = alloca_type_and_limit (ALLOCA_OK);
   | ^~~
../../gcc/gimple-ssa-warn-alloca.c: In member function ‘virtual unsigned int 
pass_walloca::execute(function*)’:
../../gcc/gimple-ssa-warn-alloca.c:200:32: note: ‘ret’ declared here
   200 |   struct alloca_type_and_limit ret = alloca_type_and_limit (ALLOCA_OK);
   |^~~


This looks like a false positive implied by different inlining
decisions.  Would it be posible to have preprocessed source + the
tripplet to configure a cross-compiler?


Just eyeballing the code, the warning complains about a call
to the (implicitly generated) assignment operator of class
alloca_type_and_limit with an object constructed by a ctor that
doesn't explicitly initialize the limit member when its argument
is ALLOCA_OK.  The limit member is a wide_int so unless its
default zeroes out the internal array (I had to debug nasty
problems in the past because I'd assumed it did), the assignment
might indeed end up copying uninitialized data.  So based on
this I wouldn't rule out the possibility it's a true positive.

One way to confirm this hypothesis might be to explicitly
initialize the limit member in the ctor even the argument is
ALLOCA_OK and see if the warning goes away.

Martin




Thanks,
Honza

c++: header unit purview [PR 99283]

[Nathan Sidwell]

This case occurs due to	some equivocation about	module_purview. 
Header-unit building is treated as a module-purview, but we should not 
treat entities imported from that as module purview.  (header units were 
not a thing when I started).  The testcase didn't understand we had a 
local textual definition, but it was (incorrectly) marked as 
module-purview, because we'd read in a declaration from a header unit too.


gcc/cp/
* cp-tree.h (lang_decl_base): Correct module flag comment.
* gcc/cp/module.cc (trees_in::assert_definition): Break out
not_tmpl var.
(trees_out::lang_decl_bools): Do not write purview for header 
units.

gcc/testsuite/
* g++.dg/modules/pr99283-6_d.H: New.
* g++.dg/modules/pr99283-7-swap.h: New.
* g++.dg/modules/pr99283-7-traits.h: New.
* g++.dg/modules/pr99283-7_a.H: New.
* g++.dg/modules/pr99283-7_b.H: New.
* g++.dg/modules/pr99283-7_c.C: New.
* g++.dg/modules/pr99283-7_d.H: New.
--
Nathan Sidwell
diff --git c/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index 9535910fd4e..66bba7b4d43 100644
--- c/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -2756,8 +2756,8 @@ struct GTY(()) lang_decl_base {
   unsigned var_declared_inline_p : 1;	   /* var */
   unsigned dependent_init_p : 1;	   /* var */
 
-  /* The following apply to VAR, FUNCTION, TYPE, CONCEPT, TEMPLATE,
- NAMESPACE decls.  */
+  /* The following apply to VAR, FUNCTION, TYPE, CONCEPT, & NAMESPACE
+ decls.  */
   unsigned module_purview_p : 1;	   /* in module purview (not GMF) */
   unsigned module_import_p : 1; 	   /* from an import */
   unsigned module_entity_p : 1;		   /* is in the entitity ary &
diff --git c/gcc/cp/module.cc w/gcc/cp/module.cc
index c87ddd16a80..d5b7d28ded5 100644
--- c/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -4477,6 +4477,7 @@ trees_in::assert_definition (tree decl ATTRIBUTE_UNUSED,
 {
 #if CHECKING_P
   tree *slot = note_defs->find_slot (decl, installing ? INSERT : NO_INSERT);
+  tree not_tmpl = STRIP_TEMPLATE (decl);
   if (installing)
 {
   /* We must be inserting for the first time.  */
@@ -4492,13 +4493,13 @@ trees_in::assert_definition (tree decl ATTRIBUTE_UNUSED,
 gcc_assert (!is_duplicate (decl)
 		? !slot
 		: (slot
-		   || !DECL_LANG_SPECIFIC (STRIP_TEMPLATE (decl))
-		   || !DECL_MODULE_PURVIEW_P (STRIP_TEMPLATE (decl))
-		   || (!DECL_MODULE_IMPORT_P (STRIP_TEMPLATE (decl))
+		   || !DECL_LANG_SPECIFIC (not_tmpl)
+		   || !DECL_MODULE_PURVIEW_P (not_tmpl)
+		   || (!DECL_MODULE_IMPORT_P (not_tmpl)
 		   && header_module_p (;
 
-  if (TREE_CODE (decl) == TEMPLATE_DECL)
-gcc_assert (!note_defs->find_slot (DECL_TEMPLATE_RESULT (decl), NO_INSERT));
+  if (not_tmpl != decl)
+gcc_assert (!note_defs->find_slot (not_tmpl, NO_INSERT));
 #endif
 }
 
@@ -5519,7 +5520,9 @@ trees_out::lang_decl_bools (tree t)
   WB (lang->u.base.concept_p);
   WB (lang->u.base.var_declared_inline_p);
   WB (lang->u.base.dependent_init_p);
-  WB (lang->u.base.module_purview_p);
+  /* When building a header unit, everthing is marked as purview, but
+ that's the GM purview, so not what the importer will mean  */
+  WB (lang->u.base.module_purview_p && !header_module_p ());
   if (VAR_OR_FUNCTION_DECL_P (t))
 WB (lang->u.base.module_attached_p);
   switch (lang->u.base.selector)
@@ -11304,7 +11307,7 @@ trees_in::register_duplicate (tree decl, tree existing)
 /* We've read a definition of MAYBE_EXISTING.  If not a duplicate,
return MAYBE_EXISTING (into which the definition should be
installed).  Otherwise return NULL if already known bad, or the
-   duplicate we read (for ODR checking, or extracting addtional merge
+   duplicate we read (for ODR checking, or extracting additional merge
information).  */
 
 tree
diff --git c/gcc/testsuite/g++.dg/modules/pr99283-6_d.H w/gcc/testsuite/g++.dg/modules/pr99283-6_d.H
new file mode 100644
index 000..e8114711f38
--- /dev/null
+++ w/gcc/testsuite/g++.dg/modules/pr99283-6_d.H
@@ -0,0 +1,10 @@
+// { dg-additional-options {-std=c++2a -fmodule-header} }
+
+import  "pr99283-6_b.H";
+
+template
+struct __allocated_ptr
+{
+  using value_type = allocator_traits<_Alloc>;
+};
+
diff --git c/gcc/testsuite/g++.dg/modules/pr99283-7-swap.h w/gcc/testsuite/g++.dg/modules/pr99283-7-swap.h
new file mode 100644
index 000..d725fea9ee5
--- /dev/null
+++ w/gcc/testsuite/g++.dg/modules/pr99283-7-swap.h
@@ -0,0 +1,17 @@
+template
+constexpr typename remove_reference<_Tp>::type&&
+  move(_Tp&& __t) noexcept;
+
+template
+constexpr inline
+typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>,
+			  is_move_constructible<_Tp>,
+			  is_move_assignable<_Tp>>::value>::type
+  swap(_Tp& __a, _Tp& __b)
+  noexcept(__and_,
+	   is_nothrow_move_assignable<_Tp>>::value)
+{
+  _Tp __tmp = move(__a);
+  __a = move(__b);
+  __b = move(__tmp);
+}
diff --git c/gcc/testsuite/g++.dg/modules/pr99283-7-traits.h w/gcc/testsuite/g++.dg/modules/pr99283-7-traits.

Re: [gcc r11-7940] Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

[Andreas Schwab]

On Apr 02 2021, Martin Sebor wrote:

> One way to confirm this hypothesis might be to explicitly
> initialize the limit member in the ctor even the argument is
> ALLOCA_OK and see if the warning goes away.

Yes, it does.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[pushed] c++: lambda pack init-capture within generic lambda

[Jason Merrill via Gcc-patches]

We represent the type of a pack init-capture as auto... with packs from the
initializer stuck into PACK_EXPANSION_PARAMETER_PACKS so that expanding it
produces the right number of elements.  But when partially instantiating the
auto..., we were changing PACK_EXPANSION_PARAMETER_PACKS to refer to only
the auto itself.  Fixed thus.

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

gcc/cp/ChangeLog:

PR c++/97938
* cp-tree.h (PACK_EXPANSION_AUTO_P): New.
* lambda.c (add_capture): Set it.
* pt.c (tsubst_pack_expansion): Handle it.

gcc/testsuite/ChangeLog:

PR c++/97938
* g++.dg/cpp2a/lambda-pack-init6.C: New test.
---
 gcc/cp/cp-tree.h  |  4 +++
 gcc/cp/lambda.c   |  7 +++--
 gcc/cp/pt.c   | 19 ++---
 .../g++.dg/cpp2a/lambda-pack-init6.C  | 27 +++
 4 files changed, 51 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-pack-init6.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 9535910fd4e..7f302534685 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -481,6 +481,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
   SWITCH_STMT_NO_BREAK_P (in SWITCH_STMT)
   LAMBDA_EXPR_CAPTURE_OPTIMIZED (in LAMBDA_EXPR)
   IMPLICIT_CONV_EXPR_BRACED_INIT (in IMPLICIT_CONV_EXPR)
+  PACK_EXPANSION_AUTO_P (in *_PACK_EXPANSION)
3: IMPLICIT_RVALUE_P (in NON_LVALUE_EXPR or STATIC_CAST_EXPR)
   ICS_BAD_FLAG (in _CONV)
   FN_TRY_BLOCK_P (in TRY_BLOCK)
@@ -3855,6 +3856,9 @@ struct GTY(()) lang_decl {
 /* True iff this pack expansion is for sizeof  */
 #define PACK_EXPANSION_SIZEOF_P(NODE) TREE_LANG_FLAG_1 (NODE)
 
+/* True iff this pack expansion is for auto... in lambda init-capture.  */
+#define PACK_EXPANSION_AUTO_P(NODE) TREE_LANG_FLAG_2 (NODE)
+
 /* True iff the wildcard can match a template parameter pack.  */
 #define WILDCARD_PACK_P(NODE) TREE_LANG_FLAG_0 (NODE)
 
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 421685cbc2d..b0fd6ecc57e 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -606,8 +606,11 @@ add_capture (tree lambda, tree id, tree orig_init, bool 
by_reference_p,
   parameter pack in this context.  We will want as many fields as we
   have elements in the expansion of the initializer, so use its packs
   instead.  */
-   PACK_EXPANSION_PARAMETER_PACKS (type)
- = uses_parameter_packs (initializer);
+   {
+ PACK_EXPANSION_PARAMETER_PACKS (type)
+   = uses_parameter_packs (initializer);
+ PACK_EXPANSION_AUTO_P (type) = true;
+   }
 }
 
   /* Make member variable.  */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7956e83c1de..524a16ab0c6 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13114,12 +13114,23 @@ tsubst_pack_expansion (tree t, tree args, 
tsubst_flags_t complain,
 pattern and return a PACK_EXPANSION_*. The caller will need to
 deal with that.  */
   if (TREE_CODE (t) == EXPR_PACK_EXPANSION)
-   t = tsubst_expr (pattern, args, complain, in_decl,
+   result = tsubst_expr (pattern, args, complain, in_decl,
 /*integral_constant_expression_p=*/false);
   else
-   t = tsubst (pattern, args, complain, in_decl);
-  t = make_pack_expansion (t, complain);
-  return t;
+   result = tsubst (pattern, args, complain, in_decl);
+  result = make_pack_expansion (result, complain);
+  if (PACK_EXPANSION_AUTO_P (t))
+   {
+ /* This is a fake auto... pack expansion created in add_capture with
+_PACKS that don't appear in the pattern.  Copy one over.  */
+ packs = PACK_EXPANSION_PARAMETER_PACKS (t);
+ pack = retrieve_local_specialization (TREE_VALUE (packs));
+ gcc_checking_assert (DECL_PACK_P (pack));
+ PACK_EXPANSION_PARAMETER_PACKS (result)
+   = build_tree_list (NULL_TREE, pack);
+ PACK_EXPANSION_AUTO_P (result) = true;
+   }
+  return result;
 }
 
   gcc_assert (len >= 0);
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-pack-init6.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-pack-init6.C
new file mode 100644
index 000..3ee500ed999
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-pack-init6.C
@@ -0,0 +1,27 @@
+// PR c++/97938
+// { dg-do compile { target c++20 } }
+
+template 
+int sink(Args&&... args) { return 2; }
+
+auto fwd1(const auto&&... ts1) {
+  return
+[...ts1 = ts1] {
+  return sink(ts1...);
+}();
+}
+
+template 
+auto fwd2(const T1& t1) {
+  return
+[] (auto&&... ts1) {
+  return
+   [...ts1 = ts1] {
+ return sink(ts1...);
+   }();
+}();
+}
+
+int main() {
+  return fwd1() + fwd2(1);
+}

base-commit: c84491827990e4f2746442c23294fc17923b265d
-- 
2.27.0

enable __ieee128 for p9vector tests

[Alexandre Oliva]

Several compile tests that use the __ieee128 type do not ensure it is
defined.  This patch adds -mfloat128 to their command lines, and
disregards the warning that may be issued by it.

Tested on x86_64-linux-gnu with a cross to powerpc-wrs-vxworks7r2,
configured for a CPU without altivec/vsx support.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc_target/powerpc/bfp/scalar-extract-exp-5.c: Add
-mfloat128, and disregard warning about it.
* gcc_target/powerpc/bfp/scalar-extract-sig-5.c: Likewise.
* gcc_target/powerpc/bfp/scalar-insert-exp-11.c: Likewise.
* gcc_target/powerpc/bfp/scalar-insert-exp-8.c: Likewise.
* gcc_target/powerpc/bfp/scalar-test-data-class-11.c: Likewise.
* gcc_target/powerpc/bfp/scalar-test-neg-5.c: Likewise.
---
 .../gcc.target/powerpc/bfp/scalar-extract-exp-5.c  |3 ++-
 .../gcc.target/powerpc/bfp/scalar-extract-sig-5.c  |3 ++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-11.c  |3 ++-
 .../gcc.target/powerpc/bfp/scalar-insert-exp-8.c   |3 ++-
 .../powerpc/bfp/scalar-test-data-class-11.c|3 ++-
 .../gcc.target/powerpc/bfp/scalar-test-neg-5.c |3 ++-
 6 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
index 34184812dc5cf..f57a388d8628f 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target ilp32 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
index 13c64fc3acfef..786740b2b8404 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target ilp32 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, producing a compiler
error because the builtin requires 64 bits.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
index a5dd852e60f0a..fd055c8a1fc31 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target ilp32 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
index bd68f77098568..795106b936c88 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c
@@ -1,7 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target ilp32 } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power9" } */
+/* { dg-options "-mdejagnu-cpu=power9 -mfloat128" } */
+/* { dg-prune-output ".-mfloat128. option may not be fully supported" } */
 
 /* This test only runs on 32-bit configurations, where a compiler error
should be issued because this builtin is not available on
diff --git a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c 
b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
index 7c6fca2b7292b..945257762c1dd 100644
--- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
+++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-11.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8" } */
+/* { dg-options "-mdejagnu-cpu=power8 -mfloat128" } */
+/* { dg-prune-output ".-mfloat12

silence expected psabi warning in ipa-sra-19 on ppc-vxworks

[Alexandre Oliva]

The default CPU for our ppc-vx7r2 toolchain has no support for altivec
or vsx, so an ABI without vector support is selected.  The selected
calling conventions do not cover passing or returning vector types, so
-Wpsabi warns about such uses.

powerpc-ibm-aix* already silences these warnings with -Wno-psabi;
this patch extends that to powerpc-wrs-vxworks* too.

Though other CPU defaults for this target might not require the warning
to be silenced, I suppose it doesn't really hurt if it's there.

Tested on x86_64-linux-gnu with a cross to powerpc-wrs-vxworks7r2,
configured for a CPU without altivec/vsx support.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/ipa/ipa-sra-19.c: Extend -Wno-psabi to ppc-vx7r2.
---
 gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c 
b/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c
index 8f3bb5df21a1f..c34c89eeacad7 100644
--- a/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c
+++ b/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2"  } */
 /* { dg-additional-options "-msse2" { target ia32 } } */
-/* { dg-additional-options "-Wno-psabi" { target powerpc-ibm-aix* } } */
+/* { dg-additional-options "-Wno-psabi" { target powerpc-ibm-aix* 
powerpc-wrs-vxworks* } } */
 
 typedef int __attribute__((__vector_size__(16))) vectype;
 

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

New Swedish PO file for 'gcc' (version 11.1-b20210321)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-11.1-b20210321.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: c++: imported templates and alias-template changes [PR 99283]

[Patrick Palka via Gcc-patches]

On Fri, 26 Mar 2021, Nathan Sidwell wrote:

> 
> During development of modules, I had difficulty   deciding whether the 
> module
> flags of a template should live on the decl_template_result, the
> template_decl, or both.  I chose the latter, and require them to be
> consistent.  This and a few other defects show how hard that consistency is.
> Hence this patch move to holding the flags on the template-decl-result decl.
> That's the entity various bits of the parser have at the appropriate time.
> Once needs STRIP_TEMPLATE in a bunch of places, which this patch adds.  Also a
> check that we never give a TEMPLATE_DECL to the module flag accessors.
> 
> This left a problem with how I was handling template aliases.  These were in
> two parts -- separating the TEMPLATE_DECL from the TYPE_DECL. That seemed
> somewhat funky, but development showed it necessary.  Of course, that causes
> problems if the TEMPLATE_DECL cannot contain 'am imported' information.
> Investigating now shows   that we do not need to treat them separately.   
> By
> reverting a bit of template instantiation machinery that caused the problem,
> we're back on course.  I think what has happened is that between then and now,
> other typedef fixes have corrected the underlying problem this separation was
> working around. It allows a bunch of cleanup in the decl streamer, as we no
> longer have to handle a null TEMPLATE_DECL_RESULT.
> 
> 
> PR c++/99283
> gcc/cp/
> * cp-tree.h (DECL_MODULE_CHECK): Ban TEMPLATE_DECL.

This seems to cause us to ICE when calling debug_tree on a
TEMPLATE_DECL.  Does the following fix for this look OK?

-- >8 --

Subject: [PATCH] c++: Fix ICE when dumping a TEMPLATE_DECL via debug_tree

This adjusts cxx_print_decl to avoid using the module flag accessors on
a TEMPLATE_DECL after r11-7866 made it an error to do so.

gcc/cp/ChangeLog:

* ptree.c (cxx_print_decl): Don't check module flags on a
TEMPLATE_DECL.
---
 gcc/cp/ptree.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/cp/ptree.c b/gcc/cp/ptree.c
index 95a4fdf284a..4c4642eccfe 100644
--- a/gcc/cp/ptree.c
+++ b/gcc/cp/ptree.c
@@ -62,7 +62,6 @@ cxx_print_decl (FILE *file, tree node, int indent)
   if (TREE_CODE (node) == FUNCTION_DECL
   || TREE_CODE (node) == VAR_DECL
   || TREE_CODE (node) == TYPE_DECL
-  || TREE_CODE (node) == TEMPLATE_DECL
   || TREE_CODE (node) == CONCEPT_DECL
   || TREE_CODE (node) == NAMESPACE_DECL)
 {
-- 
2.31.1.133.g84d06cdc06

Re: RFC: Sphinx for GCC documentation

[Koning, Paul via Gcc-patches]

> On Apr 2, 2021, at 11:40 AM, Martin Sebor via Gcc-patches 
>  wrote:
> 
> ...
> I'm not excited about changing tools.  I like that Texinfo is a GNU
> project; AFACT, Sphinx is not. 

Why is that important?  It's an open source tool, and if it better in 
interesting ways I don't see why its affiliation should matter.

I view its support for ebook output as a major benefit, which as far as I know 
TexInfo does not offer.  

paul

Re: [PATCH] rs6000: Avoid -fpatchable-function-entry* regressions on powerpc64 be [PR98125]

[Segher Boessenkool]

Hi!

Alan tells me -fpatchable-function-entry is inconsequential on PowerPC,
since the option is really only for the Linux kernel, and that uses
-mprofile-kernel for us, instead.

That option is only for 64 bit.  The kernel does not support profiling
for 32-bit PowerPC.  Curiously, the kernel also requires LE here.  I
wonder why that is, GCC works fine for this in BE as well.

-mprofile-kernel works fine on ELFv2, with its dual entrypoints.  It
also works fine on ELFv1, there are no dot symbol or official
procedure descriptor problems.

On Wed, Mar 31, 2021 at 02:49:29PM +0200, Jakub Jelinek wrote:
> I'm afraid I don't know what exactly should be done, whether e.g.
> it could use
> .section
> __patchable_function_entries,"awo",@progbits,.L._Z3foov
> instead, or whether the linker should be changed to handle it as is, or
> something else.

I have no idea either.  The GAS documentation says (for ELF section
flags):
  'o'
   section references a symbol defined in another section (the
   linked-to section) in the same file.
But GCC thinks it means something with "link order"?


> But because we have a P1 regression that didn't see useful progress over the
> 4 months since it has been filed and we don't really have much time, below
> is an attempt to do a targetted reversion of H.J's patch, basically act as
> if HAVE_GAS_SECTION_LINK_ORDER is never true for powerpc64-linux ELFv1,
> but for 32-bit or 64-bit ELFv2 keep working as is.
> This would give us time to resolve it for GCC 12 properly.

It then still is broken for ELFv2?  Do we need to open a separate bug
for that?

Disabling the testcase for PowerPC is fine, too, if you prefer that.

> +++ gcc/config/rs6000/rs6000.c2021-03-30 15:59:10.299755166 +0200
> @@ -1341,6 +1341,9 @@ static const struct attribute_spec rs600
>  #define TARGET_ASM_ASSEMBLE_VISIBILITY rs6000_assemble_visibility
>  #endif
>  
> +#undef TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY
> +#define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY 
> rs6000_print_patchable_function_entry

Line too long.

> +void
> +rs6000_print_patchable_function_entry (FILE *file,
> +unsigned HOST_WIDE_INT patch_area_size,
> +bool record_p)
> +{
> +  unsigned int flags = SECTION_WRITE | SECTION_RELRO;
> +  /* When .opd section is emitted, the function symbol
> + default_print_patchable_function_entry_1 is emitted into the .opd 
> section
> + while the patchable area is emitted into the function section.
> + Don't use SECTION_LINK_ORDER in that case.  */
> +  if (!(TARGET_64BIT && DEFAULT_ABI != ABI_ELFv2)
> +  && HAVE_GAS_SECTION_LINK_ORDER)
> +flags |= SECTION_LINK_ORDER;

Does this need a check that it is ELF at all?

> --- gcc/testsuite/g++.dg/pr93195a.C.jj2020-12-02 14:42:52.216054386 
> +0100
> +++ gcc/testsuite/g++.dg/pr93195a.C   2021-03-30 17:09:06.529574261 +0200
> @@ -1,4 +1,5 @@
>  /* { dg-do link { target { ! { nvptx*-*-* visium-*-* } } } } */
> +/* { dg-skip-if "not supported yet" { { powerpc*-*-* } && lp64 } } */
>  // { dg-require-effective-target o_flag_in_section }
>  /* { dg-options "-O0 -fpatchable-function-entry=1" } */
>  /* { dg-additional-options "-fno-pie" { target sparc*-*-* } } */

"not supported", instead.

Okay for trunk.  Thank you!

(Sorry this took so long, has to do a lot of archaeology and research,
pretty much nothing here is documented :-/ )


Segher

Re: [PATCH] rs6000: Fix up libgcc ABI when built with --with-long-double-format=ieee [PR97653]

[Segher Boessenkool]

Hi!

On Wed, Mar 31, 2021 at 08:25:14PM +0200, Jakub Jelinek wrote:
> __floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so}
> entrypoints for backwards compatibility should mean IBM double double
> handling (i.e. IFmode), gcc emits such calls for that format and
> form IEEE long double emits *kf* instead.
> When gcc is configured without --with-long-double-format=ieee ,
> everything is fine, but when it is not, we need to compile those
> libgcc sources with -mno-gnu-attribute -mabi=ibmlongdouble.
> The following snippet in libgcc/config/rs6000/t-linux was attempting
> to ensure that, and for some routines it works fine (e.g. for _powitf2).
> But, due to 4 different types of bugs it doesn't work for most of those
> functions, which means that in --with-long-double-format=ieee
> configured gcc those *tf* entrypoints instead handle the long double
> arguments as if they were KFmode.
> 
> The bugs are:
> 1) the first few objs properly use $(objext) as suffix, but
>several other contain a typo and use $(object) instead,
>which is a variable that isn't set to anything, so we don't
>add .o etc. extensions

Msybe we should use the --warn-undefined-variables make flag?

> 2) while unsigned fix are properly called _fixuns*, unsigned float
>are called _floatun* (without s), but the var was using there
>the extra s and so didn't match
> 3) the variable didn't cover any of the TF <-> TI conversions,
>only TF <-> DI conversions
> 4) nothing in libgcc_s.so was handled, as those object files are
>called *_s.o rather than *.o and IBM128_SHARED_OBJS used wrong
>syntax of the GNU make substitution reference, which should be
>$(var:a=b) standing for $(patsubst a,b,$(var)) but it used
>$(var:a:b) instead

That is POSIX, not a GNU invention :-)

>   PR target/97653
>   * config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use
>   $(objext) instead of $(object).  Use _floatunditf instead of
>   _floatunsditf.  Add tf <-> ti conversion objects.
>   (IBM128_SHARED_OBJS): Use proper substitution reference syntax.

Okay for trunk.  Thank you!


Segher

Re: silence expected psabi warning in ipa-sra-19 on ppc-vxworks

[Segher Boessenkool]

On Fri, Apr 02, 2021 at 02:05:24PM -0300, Alexandre Oliva wrote:
> The default CPU for our ppc-vx7r2 toolchain has no support for altivec
> or vsx, so an ABI without vector support is selected.  The selected
> calling conventions do not cover passing or returning vector types, so
> -Wpsabi warns about such uses.
> 
> powerpc-ibm-aix* already silences these warnings with -Wno-psabi;
> this patch extends that to powerpc-wrs-vxworks* too.

Okay for trunk.  Thanks!


Segher


>   * gcc.dg/ipa/ipa-sra-19.c: Extend -Wno-psabi to ppc-vx7r2.

[PATCH] c++: GC during late parsing collects live data [PR91416]

[Marek Polacek via Gcc-patches]

Coming back to
:

This is a crash that points to a GC problem.  Consider this test:

  __attribute__ ((unused)) struct S {
S() { }
  } s;

We're parsing a simple-declaration.  While parsing the decl specs, we parse
the attribute, which means creating a TREE_LIST using ggc_alloc_*.

A function body is a complete-class context so when parsing the
member-specification of this class-specifier, we parse the bodies of the
functions we'd queued in cp_parser_late_parsing_for_member.  This then
leads to this call chain:
cp_parser_function_definition_after_declarator -> expand_or_defer_fn ->
expand_or_defer_fn_1 -> maybe_clone_body -> expand_or_defer_fn ->
cgraph_node::finalize_function -> ggc_collect.

In this test, the ggc_collect call collects the TREE_LIST we had
allocated, and a crash duly ensues.

I couldn't do what Richard suggested, that is, attach the attribute list
to struct S, because we don't pass decl_specs from cp_parser_type_specifier
down to cp_parser_class_specifier.  Therefore I've attempted to do "push the
decl_specifiers onto a vec that is a GC root", except I couldn't really push
the decl_specifiers, because first I'd have to mark cp_decl_specifier_seq with
GTY(()) and even that wouldn't be enough for me to be able to create

  static GTY(()) vec

But here we only care about cp_decl_specifier_seq::attributes, so the
patch is just this.  I've also extended the test so now we test a nested
class too.

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

gcc/cp/ChangeLog:

PR c++/91416
* parser.c: Create a GC root for attributes in a decl specifier.
(cp_parser_declaration): Free it.
(cp_parser_type_specifier): Push ->attributes onto it.

gcc/testsuite/ChangeLog:

PR c++/91416
* g++.dg/other/gc7.C: New test.
---
 gcc/cp/parser.c  |  7 +++
 gcc/testsuite/g++.dg/other/gc7.C | 16 
 2 files changed, 23 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/other/gc7.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 808e5b61b1e..31da9f56b1b 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13957,6 +13957,11 @@ cp_parser_declaration_seq_opt (cp_parser* parser)
 }
 }
 
+/* Preserve the attributes across a garbage collect (by making it a GC
+   root), which can occur when parsing a member function.  */
+
+static GTY(()) vec *cp_parser_decl_specs_attrs;
+
 /* Parse a declaration.
 
declaration:
@@ -14140,6 +14145,7 @@ cp_parser_declaration (cp_parser* parser, tree 
prefix_attrs)
 
   /* Free any declarators allocated.  */
   obstack_free (&declarator_obstack, p);
+  vec_free (cp_parser_decl_specs_attrs);
 }
 
 /* Parse a namespace-scope declaration.  */
@@ -18438,6 +18444,7 @@ cp_parser_type_specifier (cp_parser* parser,
   /* Parse tentatively so that we can back up if we don't find a
 class-specifier.  */
   cp_parser_parse_tentatively (parser);
+  vec_safe_push (cp_parser_decl_specs_attrs, decl_specs->attributes);
   /* Look for the class-specifier.  */
   type_spec = cp_parser_class_specifier (parser);
   invoke_plugin_callbacks (PLUGIN_FINISH_TYPE, type_spec);
diff --git a/gcc/testsuite/g++.dg/other/gc7.C b/gcc/testsuite/g++.dg/other/gc7.C
new file mode 100644
index 000..ab436bac72f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/other/gc7.C
@@ -0,0 +1,16 @@
+// PR c++/91416 - GC during late parsing collects live data.
+// { dg-do compile }
+// { dg-options "--param ggc-min-heapsize=0 --param ggc-min-expand=0" }
+
+__attribute__ ((unused)) struct S {
+  S() { }
+} s;
+
+__attribute__ ((unused)) struct X {
+  void fn ()
+  {
+__attribute__ ((unused)) struct N {
+   N() { }
+} n;
+  }
+} x;

base-commit: b7c1f3d66cfc171bc4e779068530101fb2f197f1
-- 
2.30.2

[pushed] c++: dependent attribute on parameter [PR97900]

[Jason Merrill via Gcc-patches]

We were copying attributes from the template to the instantiation without
considering that they might be dependent.  To make sure that the new parms
have the appropriate properties for the code pattern, let's just regenerate
them.

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

gcc/cp/ChangeLog:

PR c++/97900
* pt.c (regenerate_decl_from_template): tsubst_decl
the parms.

gcc/testsuite/ChangeLog:

PR c++/97900
* g++.dg/ext/vector40.C: New test.
---
 gcc/cp/pt.c | 67 -
 gcc/testsuite/g++.dg/ext/vector40.C | 10 +
 2 files changed, 19 insertions(+), 58 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ext/vector40.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 524a16ab0c6..68ee71397d0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25364,8 +25364,6 @@ regenerate_decl_from_template (tree decl, tree tmpl, 
tree args)
 
   if (TREE_CODE (decl) == FUNCTION_DECL)
 {
-  tree decl_parm;
-  tree pattern_parm;
   tree specs;
   int args_depth;
   int parms_depth;
@@ -25389,65 +25387,18 @@ regenerate_decl_from_template (tree decl, tree tmpl, 
tree args)
  }
 
   /* Merge parameter declarations.  */
-  decl_parm = skip_artificial_parms_for (decl,
-DECL_ARGUMENTS (decl));
-  pattern_parm
-   = skip_artificial_parms_for (code_pattern,
-DECL_ARGUMENTS (code_pattern));
-  while (decl_parm && !DECL_PACK_P (pattern_parm))
+  if (tree pattern_parm
+ = skip_artificial_parms_for (code_pattern,
+  DECL_ARGUMENTS (code_pattern)))
{
- tree parm_type;
- tree attributes;
-
- if (DECL_NAME (decl_parm) != DECL_NAME (pattern_parm))
-   DECL_NAME (decl_parm) = DECL_NAME (pattern_parm);
- parm_type = tsubst (TREE_TYPE (pattern_parm), args, tf_error,
- NULL_TREE);
- parm_type = type_decays_to (parm_type);
- if (!same_type_p (TREE_TYPE (decl_parm), parm_type))
-   TREE_TYPE (decl_parm) = parm_type;
- attributes = DECL_ATTRIBUTES (pattern_parm);
- if (DECL_ATTRIBUTES (decl_parm) != attributes)
-   {
- DECL_ATTRIBUTES (decl_parm) = attributes;
- cplus_decl_attributes (&decl_parm, attributes, /*flags=*/0);
-   }
- decl_parm = DECL_CHAIN (decl_parm);
- pattern_parm = DECL_CHAIN (pattern_parm);
+ tree *p = &DECL_ARGUMENTS (decl);
+ for (int skip = num_artificial_parms_for (decl); skip; --skip)
+   p = &DECL_CHAIN (*p);
+ *p = tsubst_decl (pattern_parm, args, tf_error);
+ for (tree t = *p; t; t = DECL_CHAIN (t))
+   DECL_CONTEXT (t) = decl;
}
-  /* Merge any parameters that match with the function parameter
- pack.  */
-  if (pattern_parm && DECL_PACK_P (pattern_parm))
-{
-  int i, len;
-  tree expanded_types;
-  /* Expand the TYPE_PACK_EXPANSION that provides the types for
- the parameters in this function parameter pack.  */
-  expanded_types = tsubst_pack_expansion (TREE_TYPE (pattern_parm), 
- args, tf_error, NULL_TREE);
-  len = TREE_VEC_LENGTH (expanded_types);
-  for (i = 0; i < len; i++)
-{
-  tree parm_type;
-  tree attributes;
 
-  if (DECL_NAME (decl_parm) != DECL_NAME (pattern_parm))
-/* Rename the parameter to include the index.  */
-DECL_NAME (decl_parm) = 
-  make_ith_pack_parameter_name (DECL_NAME (pattern_parm), i);
-  parm_type = TREE_VEC_ELT (expanded_types, i);
-  parm_type = type_decays_to (parm_type);
-  if (!same_type_p (TREE_TYPE (decl_parm), parm_type))
-TREE_TYPE (decl_parm) = parm_type;
-  attributes = DECL_ATTRIBUTES (pattern_parm);
-  if (DECL_ATTRIBUTES (decl_parm) != attributes)
-{
-  DECL_ATTRIBUTES (decl_parm) = attributes;
-  cplus_decl_attributes (&decl_parm, attributes, /*flags=*/0);
-}
-  decl_parm = DECL_CHAIN (decl_parm);
-}
-}
   /* Merge additional specifiers from the CODE_PATTERN.  */
   if (DECL_DECLARED_INLINE_P (code_pattern)
  && !DECL_DECLARED_INLINE_P (decl))
diff --git a/gcc/testsuite/g++.dg/ext/vector40.C 
b/gcc/testsuite/g++.dg/ext/vector40.C
new file mode 100644
index 000..885afb058a5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/vector40.C
@@ -0,0 +1,10 @@
+// PR c++/97900
+
+template
+T test(T __attribute__((vector_size(2 * sizeof(T vec) {
+return vec[0] + vec[1];
+}
+typedef int v2si __attribute__((vector_size(2 * sizeof(int;
+int run(v2si vec) {
+return test(vec

[pushed] c++: PMF template parm and noexcept [PR90664]

[Jason Merrill via Gcc-patches]

The constexpr code only wants to preserve PTRMEM_CST in conversions if the
conversions are only qualification conversions; dropping noexcept counts as
a qualification adjustment in overload resolution, so let's include it here.

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

gcc/cp/ChangeLog:

PR c++/90664
* cvt.c (can_convert_qual): Check fnptr_conv_p.

gcc/testsuite/ChangeLog:

PR c++/90664
* g++.dg/cpp1z/noexcept-type24.C: New test.
---
 gcc/cp/cvt.c |  5 +
 gcc/testsuite/g++.dg/cpp1z/noexcept-type24.C | 22 
 2 files changed, 27 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/noexcept-type24.C

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index d1051139e70..f1687e804d1 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -2013,6 +2013,11 @@ can_convert_qual (tree type, tree expr)
   tree expr_type = TREE_TYPE (expr);
   gcc_assert (!same_type_p (type, expr_type));
 
+  /* A function pointer conversion also counts as a Qualification Adjustment
+ under [over.ics.scs].  */
+  if (fnptr_conv_p (type, expr_type))
+return true;
+
   if (TYPE_PTR_P (type) && TYPE_PTR_P (expr_type))
 return comp_ptr_ttypes (TREE_TYPE (type), TREE_TYPE (expr_type));
   else if (TYPE_PTRMEM_P (type) && TYPE_PTRMEM_P (expr_type))
diff --git a/gcc/testsuite/g++.dg/cpp1z/noexcept-type24.C 
b/gcc/testsuite/g++.dg/cpp1z/noexcept-type24.C
new file mode 100644
index 000..df16ea78641
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/noexcept-type24.C
@@ -0,0 +1,22 @@
+// PR c++/90664
+// { dg-do compile { target c++11 } }
+
+template  struct OpM;
+
+template 
+struct OpM
+{};
+
+class Class {
+public:
+  int address() noexcept { return 0; }
+  void address(int) noexcept {}
+};
+
+struct Sk {
+  template  Sk(R (C::*p)()) {
+typedef OpM OP;
+  }
+};
+
+Sk sk(static_cast(&Class::address));

base-commit: 2a26351b598242c2fbce95d2a0baacce0084aec6
prerequisite-patch-id: ce32856d89f65f0543b5696d12c0de2014236a6e
-- 
2.27.0

[pushed] c++: NRV in lambda in template [PR91217]

[Jason Merrill via Gcc-patches]

tsubst_lambda_expr was producing a function with two blocks that claimed to
be the outermost block in the function body, one from the call to
start_lambda_function in tsubst_lambda_expr, and one from tsubsting the
block added by start_lambda_function when we first parsed the lambda.  This
messed with the named return value optimization, which only works for
variables in the outermost block.

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

gcc/cp/ChangeLog:

PR c++/91217
* pt.c (tsubst_lambda_expr): Skip the body block from
DECL_SAVED_TREE.

gcc/testsuite/ChangeLog:

PR c++/91217
* g++.dg/opt/nrv20.C: New test.
---
 gcc/cp/pt.c  |  9 +++--
 gcc/testsuite/g++.dg/opt/nrv20.C | 20 
 2 files changed, 27 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/opt/nrv20.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 68ee71397d0..2763aa15f1f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19433,8 +19433,13 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
 the purposes of template argument deduction. */
   complain = tf_warning_or_error;
 
-  tsubst_expr (DECL_SAVED_TREE (oldfn), args, complain, r,
-  /*constexpr*/false);
+  tree saved = DECL_SAVED_TREE (oldfn);
+  if (TREE_CODE (saved) == BIND_EXPR && BIND_EXPR_BODY_BLOCK (saved))
+   /* We already have a body block from start_lambda_function, we don't
+  need another to confuse NRV (91217).  */
+   saved = BIND_EXPR_BODY (saved);
+
+  tsubst_expr (saved, args, complain, r, /*constexpr*/false);
 
   finish_lambda_function (body);
 
diff --git a/gcc/testsuite/g++.dg/opt/nrv20.C b/gcc/testsuite/g++.dg/opt/nrv20.C
new file mode 100644
index 000..ade0c28824a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/opt/nrv20.C
@@ -0,0 +1,20 @@
+// PR c++/91217
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -fdump-tree-gimple }
+// { dg-final { scan-tree-dump-not " = a" "gimple" } }
+
+struct A
+{
+  int ar[42];
+};
+
+template 
+A f()
+{
+  return [] { A a; return a; }();
+}
+
+int main()
+{
+  f();
+}

base-commit: 2a26351b598242c2fbce95d2a0baacce0084aec6
prerequisite-patch-id: ce32856d89f65f0543b5696d12c0de2014236a6e
prerequisite-patch-id: 2bf69397dfd35a530e9da35351b67c6fb9e8e8d4
-- 
2.27.0