Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/16/20 3:13 PM, Nikhil Benesch wrote:

On 12/16/20 2:20 PM, Rainer Orth wrote:

Hi Nikhil,


On 12/15/20 3:00 AM, Nikhil Benesch wrote:

If this patch looks good, I'll submit it upstream tomorrow.


Assuming no news is good news, I sent
https://go-review.googlesource.com/c/gofrontend/+/278672.


sorry for the delay, but unfortunately news is not so good: I get

runtime_sysinfo.go:315:18: error: use of undefined type '_ucontext'
   315 | type _ucontext_t _ucontext
   |  ^


No problem, Rainer. I figured there would be some hiccups. The somewhat good 
news
is that this error appears to be independent of the patch I sent upstream.

I suspect what is happening here is that godump sees "typedef ucontext_t struct
ucontext" and outputs the typedef immediately. Only later does it observe that
"struct ucontext" is invalid. At that point it is too late to comment out the
typedef for _ucontext_t.


Oh, wait, Rainer, did you apply *both* solaris-godump.patch and
invalid-dummy.patch? I think if you apply only the former (i.e., only
solaris-godump.patch), which is the only bit I've submitted upstream,
all will be well.

For good measure, I've also fixed the issue in invalid-dummy.patch
and attached a new version. But I'm still not sure whether it is a
worthwhile change, and it's something we can discuss separately from
solaris-godump.patch.

Nikhil
diff --git a/gcc/godump.c b/gcc/godump.c
index ff3a4a9c52c..b4cbdf275f2 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -670,6 +670,8 @@ go_force_record_alignment (struct obstack *ob, const char 
*type_string,
   return index;
 }
 
+static void go_output_typedef (class godump_container *container, tree decl);
+
 /* Write the Go version of TYPE to CONTAINER->TYPE_OBSTACK.
USE_TYPE_NAME is true if we can simply use a type name here without
needing to define it.  IS_FUNC_OK is true if we can output a func
@@ -705,6 +707,7 @@ go_format_type (class godump_container *container, tree 
type,
 {
   tree name;
   void **slot;
+  void **islot;
 
   /* References to complex builtin types cannot be translated to
Go.  */
@@ -714,10 +717,32 @@ go_format_type (class godump_container *container, tree 
type,
 
   name = TYPE_IDENTIFIER (type);
 
-  slot = htab_find_slot (container->invalid_hash, IDENTIFIER_POINTER 
(name),
+
+  slot = htab_find_slot (container->type_hash, IDENTIFIER_POINTER (name),
 NO_INSERT);
-  if (slot != NULL)
-   ret = false;
+  islot = htab_find_slot (container->invalid_hash, IDENTIFIER_POINTER 
(name),
+NO_INSERT);
+  if (islot != NULL)
+   {
+ /* The named type is known to be invalid.  */
+ ret = false;
+   }
+  else if (slot == NULL)
+   {
+ size_t pos;
+
+ /* The named type is not known to be either valid or invalid.
+Check to see if the named type is valid. Doing so requires
+formatting the type and throwing away the result, which is
+a bit silly.  */
+
+ pos = obstack_object_size (ob);
+
+ if (!go_format_type (container, type, false, false, NULL, false))
+   ret = false;
+
+ ob->next_free = ob->object_base + pos;
+   }
 
   /* References to incomplete structs are permitted in many
 contexts, like behind a pointer or inside of a typedef. So
@@ -1351,11 +1376,9 @@ find_dummy_types (const char *const , 
godump_container *adata)
   class godump_container *data = (class godump_container *) adata;
   const char *type = (const char *) ptr;
   void **slot;
-  void **islot;
 
   slot = htab_find_slot (data->type_hash, type, NO_INSERT);
-  islot = htab_find_slot (data->invalid_hash, type, NO_INSERT);
-  if (slot == NULL || islot != NULL)
+  if (slot == NULL)
 fprintf (go_dump_file, "type _%s struct {}\n", type);
   return true;
 }
diff --git a/gcc/testsuite/gcc.misc-tests/godump-1.c 
b/gcc/testsuite/gcc.misc-tests/godump-1.c
index d37ab0b5af4..4492a6e4887 100644
--- a/gcc/testsuite/gcc.misc-tests/godump-1.c
+++ b/gcc/testsuite/gcc.misc-tests/godump-1.c
@@ -304,6 +304,13 @@ long double ld_v1;
 ld_t ld_v2;
 /* { dg-final { scan-file godump-1.out "(?n)^// var _ld_v2 
INVALID-float-\[0-9\]*$" } } */
 
+typedef struct ld_s ld_s_t1;
+typedef struct ld_s { long double ld_s_f; } ld_s_t2;
+/* { dg-final { scan-file godump-1.out "(?n)^// type _ld_s_t1 _ld_s$" } } *
+/* { dg-final { scan-file godump-1.out "(?n)^// type _ld_s struct \{ ld_s_f 
INVALID-float-\[0-9\]*; \}$" } } */
+/* { dg-final { scan-file godump-1.out "(?n)^// type _ld_s_t2 _ld_s$" } } *
+/* { dg-final { scan-file-not godump-1.out "(?n)^type _ld_s struct \{\}$" } } 
*/
+
 /*** complex types ***/
 typedef _Complex cx_t;
 /* { dg-final { scan-file godump-1.out "(?n)^type _cx_t complex\[0-9\]*$" } } 
*/
@@ -476,6 +483,8 @@ struct { double d; uint8_t : 0; } sd_not_equiv;
 /* { dg-final { scan-file godump-1.out "(?n)^var _sd_not_equiv struct \{ d 

Patch RFA: Support non-ASCII file names in git-changelog

[Ian Lance Taylor via Gcc-patches]

As discussed at
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561995.html ,
the ChangeLog checker does not correctly handle files with non-ASCII
file names.

This patch fixes the problem.  I have little experience with Python,
so I may have made some foolish mistakes here.

OK to commit?

Thanks.

Ian

* gcc-changelog/git_repository.py: Ignore quotation marks added by git
for non-ASCII file names.
diff --git a/contrib/gcc-changelog/git_repository.py 
b/contrib/gcc-changelog/git_repository.py
index 8edcff91ad6..86b470b0881 100755
--- a/contrib/gcc-changelog/git_repository.py
+++ b/contrib/gcc-changelog/git_repository.py
@@ -55,7 +55,10 @@ def parse_git_revisions(repo_path, revisions, strict=True):
 t = 'A'
 else:
 t = 'M'
-modified_files.append((file.b_path, t))
+path = file.b_path
+if path.startswith('"') and path.endswith('"'):
+path = path[1:len(path)-1]
+modified_files.append((path, t))
 
 date = datetime.utcfromtimestamp(c.committed_date)
 author = '%s  <%s>' % (c.author.name, c.author.email)

Re: Change to gcc/testsuite/go.test/test rejected by ChangeLog checker

[Ian Lance Taylor via Gcc-patches]

On Wed, Dec 16, 2020 at 8:01 PM Ian Lance Taylor  wrote:
>
> Thanks for the pointer to git-verify.  It also fails.  It looks like
> when the file name contains a non-ASCII character, it comes back with
> quotation marks around it.  That causes the test "if
> path.startswith(ignored):" in git_commit.py to fail when checking
> whether the file is an ignored directory.

Looks like the quotation marks come from git itself.  This is the
output of git status.

On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged ..." to unstage)
new file:   "gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/\303\204foo.go"
new file:   
"gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/\303\204main.go"
new file:   gcc/testsuite/go.test/test/fixedbugs/issue27836.go

Ian

Re: Change to gcc/testsuite/go.test/test rejected by ChangeLog checker

[Ian Lance Taylor via Gcc-patches]

On Wed, Dec 16, 2020 at 7:38 PM Kewen.Lin  wrote:
>
> With the helper gcc-verify from contrib/gcc-git-customization.sh [1],
> you can verify your local commit to meet required ChangeLog formats.
> Does gcc-verify claim that it's ok locally?
>
> If no, probably you can amend the commit message with those entries
> suggested from contrib/mklog.py, to see there are any differences.

I figured it out.  The problem is a couple of files in the testsuite
whose names are not ASCII:

gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Äfoo.go
gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ämain.go

Trying to commit those files triggers the error on "git push".

Thanks for the pointer to git-verify.  It also fails.  It looks like
when the file name contains a non-ASCII character, it comes back with
quotation marks around it.  That causes the test "if
path.startswith(ignored):" in git_commit.py to fail when checking
whether the file is an ignored directory.

Ian

Re: [PATCH 3/3] RISC-V: Support version controling for ISA standard extensions

[Kito Cheng via Gcc-patches]

Hi Gerald:

Thanks for notifying me, we'll update that page soon :)

On Tue, Dec 15, 2020 at 4:08 PM Gerald Pfeifer  wrote:
>
> On Fri, 13 Nov 2020, Kito Cheng wrote:
> >  - New option -misa-spec support: -misa-spec=[2.2|20190608|20191213] and
> >corresponding configuration option --with-isa-spec.
>
> I noticed https://gcc.gnu.org/gcc-11/changes.html is currently empty.
>
> Are you planning to add updates for the GCC 11 release?  (It may be
> useful to add them as they happen, so they we won't miss them and
> also for the benefit of users tracking development.)
>
> Gerald

Re: Go testsuite patch committed: Add some new tests

[Ian Lance Taylor via Gcc-patches]

And another set of new tests.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian


patch.txt.bz2
Description: application/bzip

Re: Go testsuite patch committed: Add some new tests

[Ian Lance Taylor via Gcc-patches]

This patch adds some more new tests from the fixedbugs subdirectory of
the source repo that currently pass with gccgo.  Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian


patch.txt.bz2
Description: application/bzip

Re: Change to gcc/testsuite/go.test/test rejected by ChangeLog checker

[Kewen.Lin via Gcc-patches]

on 2020/12/17 上午11:26, Ian Lance Taylor wrote:
> On Wed, Dec 16, 2020 at 6:54 PM Kewen.Lin  wrote:
>>
>> on 2020/12/16 上午7:53, Ian Lance Taylor via Gcc-patches wrote:
>>> On Tue, Dec 15, 2020 at 3:51 PM Ian Lance Taylor  wrote:

 On Tue, Dec 15, 2020 at 3:43 PM Ian Lance Taylor  wrote:
>
> I'm trying to commit a change that adds a bunch of new files to
> gcc/testsuite/go.test/test.  It's being rejected because the hook
> can't deduce a ChangeLog file.  But this directory has no ChangeLog
> files.  I've committed other changes to this directory without a
> ChangeLog entry.
>
> What is going wrong?  What can I do to commit this change?  What
> information can I provide?
>
> Thanks.
>
> Ian
>
>> git push
> Enumerating objects: 854, done.
> Counting objects: 100% (854/854), done.
> Delta compression using up to 8 threads
> Compressing objects: 100% (824/824), done.
> Writing objects: 100% (847/847), 266.10 KiB | 2.25 MiB/s, done.
> Total 847 (delta 167), reused 3 (delta 0), pack-reused 0
> remote: Resolving deltas: 100% (167/167), completed with 4 local objects.
> remote: *** The following commit was rejected by your
> hooks.commit-extra-checker script (status: 1)
> remote: *** commit: b09ac944e04a59af95a5767f6835edad7da4f152
> remote: *** ChangeLog format failed:
> remote: *** ERR: could not deduce ChangeLog file
> remote: ***
> remote: *** Please see: 
> https://gcc.gnu.org/codingconventions.html#ChangeLogs
> remote: ***
> remote: error: hook declined to update refs/heads/master
> To git+ssh://gcc.gnu.org/git/gcc
>  ! [remote rejected] master -> master (hook declined)
> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc'

 One less common change I am trying to make is to delete a file.  Could
 that be the cause of this problem?

 I'm going to try removing the deleted file from the change.
>>>
>>> Nope, still failed, though the message is slightly different.
>>>
>>
>> I'm not sure you have figured out the reason and made the push
>> successfully.
>>
>> The files in gcc/testsuite/go.test/test seems still available to
>> have their changelog entries.  Such as for your recent commit
>> e38c912700f001ea1c8a32533bedb4c802e38d3f.
>>
>> git show e38c912700f001ea1c8a32533bedb4c802e38d3f | contrib/mklog.py
>> gcc/testsuite/ChangeLog:
>>
>> * go.test/test/fixedbugs/bug13343.go: New test.
>> * go.test/test/fixedbugs/bug19403.go: New test.
>> * go.test/test/fixedbugs/bug369.dir/main.go: New test.
>> * go.test/test/fixedbugs/bug483.go: New test.
>> * go.test/test/fixedbugs/bug484.go: New test.
>> * go.test/test/fixedbugs/bug485.go: New test.
>> * go.test/test/fixedbugs/bug486.go: New test.
>> * go.test/test/fixedbugs/bug490.go: New test.
>> * go.test/test/fixedbugs/bug491.go: New test.
>> * go.test/test/fixedbugs/bug495.go: New test.
>> * go.test/test/fixedbugs/bug498.go: New test.
>> * go.test/test/fixedbugs/bug510.dir/a.go: New test.
>> * go.test/test/fixedbugs/bug510.dir/b.go: New test.
>> * go.test/test/fixedbugs/bug510.go: New test.
>>
>> Probably the hook becomes stricter somehow recently and complains the
>> expected changelog entires missing there.
> 
> 
> I have not figured this out.  I am going to try to submit smaller sets
> of files.  Perhaps the problem was the size of the change, or perhaps
> it was some specific file.

With the helper gcc-verify from contrib/gcc-git-customization.sh [1],
you can verify your local commit to meet required ChangeLog formats.
Does gcc-verify claim that it's ok locally?

If no, probably you can amend the commit message with those entries
suggested from contrib/mklog.py, to see there are any differences.

BR,
Kewen

[1] https://gcc.gnu.org/gitwrite.html

Re: Change to gcc/testsuite/go.test/test rejected by ChangeLog checker

[Ian Lance Taylor via Gcc-patches]

On Wed, Dec 16, 2020 at 6:54 PM Kewen.Lin  wrote:
>
> on 2020/12/16 上午7:53, Ian Lance Taylor via Gcc-patches wrote:
> > On Tue, Dec 15, 2020 at 3:51 PM Ian Lance Taylor  wrote:
> >>
> >> On Tue, Dec 15, 2020 at 3:43 PM Ian Lance Taylor  wrote:
> >>>
> >>> I'm trying to commit a change that adds a bunch of new files to
> >>> gcc/testsuite/go.test/test.  It's being rejected because the hook
> >>> can't deduce a ChangeLog file.  But this directory has no ChangeLog
> >>> files.  I've committed other changes to this directory without a
> >>> ChangeLog entry.
> >>>
> >>> What is going wrong?  What can I do to commit this change?  What
> >>> information can I provide?
> >>>
> >>> Thanks.
> >>>
> >>> Ian
> >>>
>  git push
> >>> Enumerating objects: 854, done.
> >>> Counting objects: 100% (854/854), done.
> >>> Delta compression using up to 8 threads
> >>> Compressing objects: 100% (824/824), done.
> >>> Writing objects: 100% (847/847), 266.10 KiB | 2.25 MiB/s, done.
> >>> Total 847 (delta 167), reused 3 (delta 0), pack-reused 0
> >>> remote: Resolving deltas: 100% (167/167), completed with 4 local objects.
> >>> remote: *** The following commit was rejected by your
> >>> hooks.commit-extra-checker script (status: 1)
> >>> remote: *** commit: b09ac944e04a59af95a5767f6835edad7da4f152
> >>> remote: *** ChangeLog format failed:
> >>> remote: *** ERR: could not deduce ChangeLog file
> >>> remote: ***
> >>> remote: *** Please see: 
> >>> https://gcc.gnu.org/codingconventions.html#ChangeLogs
> >>> remote: ***
> >>> remote: error: hook declined to update refs/heads/master
> >>> To git+ssh://gcc.gnu.org/git/gcc
> >>>  ! [remote rejected] master -> master (hook declined)
> >>> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc'
> >>
> >> One less common change I am trying to make is to delete a file.  Could
> >> that be the cause of this problem?
> >>
> >> I'm going to try removing the deleted file from the change.
> >
> > Nope, still failed, though the message is slightly different.
> >
>
> I'm not sure you have figured out the reason and made the push
> successfully.
>
> The files in gcc/testsuite/go.test/test seems still available to
> have their changelog entries.  Such as for your recent commit
> e38c912700f001ea1c8a32533bedb4c802e38d3f.
>
> git show e38c912700f001ea1c8a32533bedb4c802e38d3f | contrib/mklog.py
> gcc/testsuite/ChangeLog:
>
> * go.test/test/fixedbugs/bug13343.go: New test.
> * go.test/test/fixedbugs/bug19403.go: New test.
> * go.test/test/fixedbugs/bug369.dir/main.go: New test.
> * go.test/test/fixedbugs/bug483.go: New test.
> * go.test/test/fixedbugs/bug484.go: New test.
> * go.test/test/fixedbugs/bug485.go: New test.
> * go.test/test/fixedbugs/bug486.go: New test.
> * go.test/test/fixedbugs/bug490.go: New test.
> * go.test/test/fixedbugs/bug491.go: New test.
> * go.test/test/fixedbugs/bug495.go: New test.
> * go.test/test/fixedbugs/bug498.go: New test.
> * go.test/test/fixedbugs/bug510.dir/a.go: New test.
> * go.test/test/fixedbugs/bug510.dir/b.go: New test.
> * go.test/test/fixedbugs/bug510.go: New test.
>
> Probably the hook becomes stricter somehow recently and complains the
> expected changelog entires missing there.


I have not figured this out.  I am going to try to submit smaller sets
of files.  Perhaps the problem was the size of the change, or perhaps
it was some specific file.

Ian

PING^6 [PATCH 1/4] unroll: Add middle-end unroll factor estimation

[Kewen.Lin via Gcc-patches]

Hi,

Gentle ping^6 for:

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html

BR,
Kewen

on 2020/11/19 下午1:50, Kewen.Lin via Gcc-patches wrote:
> Hi,
> 
> Gentle ping^5 for:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html
> 
> BR,
> Kewen
> 
> on 2020/11/2 下午5:13, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> Gentle ping^4 this:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html
>>
>> BR,
>> Kewen
>>
>> on 2020/10/13 下午3:06, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> Gentle ping this:
>>>
>>> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html
>>>
>>> BR,
>>> Kewen
>>>
>>> on 2020/9/15 下午3:44, Kewen.Lin via Gcc-patches wrote:
 Hi,

 Gentle ping this:

 https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html

 BR,
 Kewen

 on 2020/8/31 下午1:49, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> I'd like to gentle ping this since IVOPTs part is already to land.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546698.html
>
> BR,
> Kewen
>
> on 2020/5/28 下午8:19, Kewen.Lin via Gcc-patches wrote:
>>
>> gcc/ChangeLog
>>
>> 2020-MM-DD  Kewen Lin  
>>
>>  * cfgloop.h (struct loop): New field estimated_unroll.
>>  * tree-ssa-loop-manip.c (decide_unroll_const_iter): New function.
>>  (decide_unroll_runtime_iter): Likewise.
>>  (decide_unroll_stupid): Likewise.
>>  (estimate_unroll_factor): Likewise.
>>  * tree-ssa-loop-manip.h (estimate_unroll_factor): New declaration.
>>  * tree-ssa-loop.c (tree_average_num_loop_insns): New function.
>>  * tree-ssa-loop.h (tree_average_num_loop_insns): New declaration.
>>

Re: Change to gcc/testsuite/go.test/test rejected by ChangeLog checker

[Kewen.Lin via Gcc-patches]

Hi Ian,

on 2020/12/16 上午7:53, Ian Lance Taylor via Gcc-patches wrote:
> On Tue, Dec 15, 2020 at 3:51 PM Ian Lance Taylor  wrote:
>>
>> On Tue, Dec 15, 2020 at 3:43 PM Ian Lance Taylor  wrote:
>>>
>>> I'm trying to commit a change that adds a bunch of new files to
>>> gcc/testsuite/go.test/test.  It's being rejected because the hook
>>> can't deduce a ChangeLog file.  But this directory has no ChangeLog
>>> files.  I've committed other changes to this directory without a
>>> ChangeLog entry.
>>>
>>> What is going wrong?  What can I do to commit this change?  What
>>> information can I provide?
>>>
>>> Thanks.
>>>
>>> Ian
>>>
 git push
>>> Enumerating objects: 854, done.
>>> Counting objects: 100% (854/854), done.
>>> Delta compression using up to 8 threads
>>> Compressing objects: 100% (824/824), done.
>>> Writing objects: 100% (847/847), 266.10 KiB | 2.25 MiB/s, done.
>>> Total 847 (delta 167), reused 3 (delta 0), pack-reused 0
>>> remote: Resolving deltas: 100% (167/167), completed with 4 local objects.
>>> remote: *** The following commit was rejected by your
>>> hooks.commit-extra-checker script (status: 1)
>>> remote: *** commit: b09ac944e04a59af95a5767f6835edad7da4f152
>>> remote: *** ChangeLog format failed:
>>> remote: *** ERR: could not deduce ChangeLog file
>>> remote: ***
>>> remote: *** Please see: 
>>> https://gcc.gnu.org/codingconventions.html#ChangeLogs
>>> remote: ***
>>> remote: error: hook declined to update refs/heads/master
>>> To git+ssh://gcc.gnu.org/git/gcc
>>>  ! [remote rejected] master -> master (hook declined)
>>> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc'
>>
>> One less common change I am trying to make is to delete a file.  Could
>> that be the cause of this problem?
>>
>> I'm going to try removing the deleted file from the change.
> 
> Nope, still failed, though the message is slightly different.
> 

I'm not sure you have figured out the reason and made the push
successfully.

The files in gcc/testsuite/go.test/test seems still available to
have their changelog entries.  Such as for your recent commit
e38c912700f001ea1c8a32533bedb4c802e38d3f.

git show e38c912700f001ea1c8a32533bedb4c802e38d3f | contrib/mklog.py
gcc/testsuite/ChangeLog:

* go.test/test/fixedbugs/bug13343.go: New test.
* go.test/test/fixedbugs/bug19403.go: New test.
* go.test/test/fixedbugs/bug369.dir/main.go: New test.
* go.test/test/fixedbugs/bug483.go: New test.
* go.test/test/fixedbugs/bug484.go: New test.
* go.test/test/fixedbugs/bug485.go: New test.
* go.test/test/fixedbugs/bug486.go: New test.
* go.test/test/fixedbugs/bug490.go: New test.
* go.test/test/fixedbugs/bug491.go: New test.
* go.test/test/fixedbugs/bug495.go: New test.
* go.test/test/fixedbugs/bug498.go: New test.
* go.test/test/fixedbugs/bug510.dir/a.go: New test.
* go.test/test/fixedbugs/bug510.dir/b.go: New test.
* go.test/test/fixedbugs/bug510.go: New test.

Probably the hook becomes stricter somehow recently and complains the
expected changelog entires missing there.

BR,
Kewen

[PATCH] correct -Wmismatched-new-delete for template instantiations (PR 98305)

[Martin Sebor via Gcc-patches]

The -Wmismatched-new-delete detection of operator members of class
template instantiations is incomplete and overly simplistic, leading
to incorrect results and false positives.  Rather than reinventing
the wheel and parsing the mangled qualified names of the operators
the attached patch uses the demangler to compare their names.  Since
the code is only entered rarely (for user- defined overloads of
the operators, the cost of the demangling should be negligible in
most code bases).

Tested on x86_64-linux.

Martin
PR c++/98305 spurious -Wmismatched-new-delete on template instance

gcc/ChangeLog:

	PR c++/98305
	* builtins.c (new_delete_mismatch_p): New overload.
	(new_delete_mismatch_p (tree, tree)): Call it.

gcc/testsuite/ChangeLog:

	PR c++/98305
	* g++.dg/warn/Wmismatched-new-delete-3.C: New test.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 28e5ab2..b1d69855523 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -78,6 +78,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-ssa-live.h"
 #include "tree-outof-ssa.h"
 #include "attr-fnspec.h"
+#include "demangle.h"
 
 struct target_builtins default_target_builtins;
 #if SWITCHABLE_TARGET
@@ -13053,121 +13054,152 @@ call_dealloc_argno (tree exp)
   return UINT_MAX;
 }
 
-/* Return true if DELETE_DECL is an operator delete that's not suitable
-   to call with a pointer returned fron NEW_DECL.  */
+/* Return true if DELC doesn't refer to an operator delete that's
+   suitable to call with a pointer returned from the operator new
+   described by NEWC.  */
 
 static bool
-new_delete_mismatch_p (tree new_decl, tree delete_decl)
+new_delete_mismatch_p (const demangle_component ,
+		   const demangle_component )
 {
-  tree new_name = DECL_ASSEMBLER_NAME (new_decl);
-  tree delete_name = DECL_ASSEMBLER_NAME (delete_decl);
-
-  /* valid_new_delete_pair_p() returns a conservative result.  A true
- result is reliable but a false result doesn't necessarily mean
- the operators don't match.  */
-  if (valid_new_delete_pair_p (new_name, delete_name))
-return false;
-
-  const char *new_str = IDENTIFIER_POINTER (new_name);
-  const char *del_str = IDENTIFIER_POINTER (delete_name);
-
-  if (*new_str != '_')
-return *new_str != *del_str;
+  if (newc.type != delc.type)
+return true;
 
-  ++del_str;
-  if (*++new_str != 'Z')
-return *new_str != *del_str;
+  switch (newc.type)
+{
+case DEMANGLE_COMPONENT_NAME:
+  {
+	int len = newc.u.s_name.len;
+	const char *news = newc.u.s_name.s;
+	const char *dels = delc.u.s_name.s;
+	if (len != delc.u.s_name.len || memcmp (news, dels, len))
+	  return true;
 
-  ++del_str;
-  if (*++new_str == 'n')
-return *del_str != 'd';
+	if (news[len] == 'n')
+	  {
+	if (news[len + 1] == 'a')
+	  return dels[len] != 'd' || dels[len + 1] != 'a';
+	if (news[len + 1] == 'w')
+	  return dels[len] != 'd' || dels[len + 1] != 'l';
+	  }
+	return false;
+  }
 
-  if (*new_str != 'N')
-return *del_str != 'N';
+case DEMANGLE_COMPONENT_OPERATOR:
+  /* Operator mismatches are handled above.  */
+  return false;
 
-  /* Handle user-defined member operators below.  */
-  ++new_str;
-  ++del_str;
+case DEMANGLE_COMPONENT_EXTENDED_OPERATOR:
+  if (newc.u.s_extended_operator.args != delc.u.s_extended_operator.args)
+	return true;
+  return new_delete_mismatch_p (*newc.u.s_extended_operator.name,
+*delc.u.s_extended_operator.name);
 
-  do
-{
-  /* Determine if both operators are members of the same type.
-	 If not, they don't match.  */
-  char *new_end, *del_end;
-  unsigned long nlen = strtoul (new_str, _end, 10);
-  unsigned long dlen = strtoul (del_str, _end, 10);
-  if (nlen != dlen)
+case DEMANGLE_COMPONENT_FIXED_TYPE:
+  if (newc.u.s_fixed.accum != delc.u.s_fixed.accum
+	  || newc.u.s_fixed.sat != delc.u.s_fixed.sat)
 	return true;
+  return new_delete_mismatch_p (*newc.u.s_fixed.length,
+*delc.u.s_fixed.length);
 
-  /* Skip past the name length.   */
-  new_str = new_end;
-  del_str = del_end;
+case DEMANGLE_COMPONENT_CTOR:
+  if (newc.u.s_ctor.kind != delc.u.s_ctor.kind)
+	return true;
+  return new_delete_mismatch_p (*newc.u.s_ctor.name,
+*delc.u.s_ctor.name);
 
-  /* Skip past the names making sure each has the expected length
-	 (it would suggest some sort of a corruption if they didn't).  */
-  while (nlen--)
-	if (!*++new_end)
-	  return true;
+case DEMANGLE_COMPONENT_DTOR:
+  if (newc.u.s_dtor.kind != delc.u.s_dtor.kind)
+	return true;
+  return new_delete_mismatch_p (*newc.u.s_dtor.name,
+*delc.u.s_dtor.name);
 
-  for (nlen = dlen; nlen--; )
-	if (!*++del_end)
+case DEMANGLE_COMPONENT_BUILTIN_TYPE:
+  {
+	/* The demangler API provides no better way to compare built-in
+	   types except to by comparing their demangled names. */
+	size_t nsz, dsz;
+	demangle_component *pnc = const_cast();
+	

Re: [x86] recompute opt flags after opt level change

[Alexandre Oliva]

Hello, Martin,

On Dec 16, 2020, Martin Liška  wrote:

> On 10/1/19 10:58 AM, Alexandre Oliva wrote:
>> +  if (opts->x_flag_asynchronous_unwind_tables == 2)
>> +opts->x_flag_unwind_tables
>> +  = opts->x_flag_asynchronous_unwind_tables = 1;

> Anyway the code seems fishy, shouldn't it be:

>   if (opts->x_flag_asynchronous_unwind_tables == 2)
> opts->x_flag_unwind_tables
>   = opts->x_flag_asynchronous_unwind_tables == 1; < '==' instead 
> of '='

No, IIRC the idea was to assign 1 to both fields.

I can't tell for sure because I don't think I wrote this myself, IIRC my
patch just moved it.

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

[COMMITTED] gcc: xtensa: add optimizations for shift operations

[Max Filippov via Gcc-patches]

From: Takayuki 'January June' Suwa 

2020-12-16  Takayuki 'January June' Suwa  
gcc/
* config/xtensa/xtensa.md (*ashlsi3_1, *ashlsi3_3x, *ashrsi3_3x)
(*lshrsi3_3x): New patterns.

gcc/testsuite/
* gcc.target/xtensa/shifts.c: New test.
---
 gcc/config/xtensa/xtensa.md  | 43 
 gcc/testsuite/gcc.target/xtensa/shifts.c | 31 +
 2 files changed, 74 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/xtensa/shifts.c

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 5fbe4ad4af9f..462a7244a35d 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -1071,6 +1071,16 @@
   operands[1] = xtensa_copy_incoming_a7 (operands[1]);
 })
 
+(define_insn "*ashlsi3_1"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+   (ashift:SI (match_operand:SI 1 "register_operand" "r")
+  (const_int 1)))]
+  "TARGET_DENSITY"
+  "add.n\t%0, %1, %1"
+  [(set_attr "type""arith")
+   (set_attr "mode""SI")
+   (set_attr "length"  "2")])
+
 (define_insn "ashlsi3_internal"
   [(set (match_operand:SI 0 "register_operand" "=a,a")
(ashift:SI (match_operand:SI 1 "register_operand" "r,r")
@@ -1083,6 +1093,17 @@
(set_attr "mode""SI")
(set_attr "length"  "3,6")])
 
+(define_insn "*ashlsi3_3x"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+   (ashift:SI (match_operand:SI 1 "register_operand" "r")
+  (ashift:SI (match_operand:SI 2 "register_operand" "r")
+ (const_int 3]
+  ""
+  "ssa8b\t%2\;sll\t%0, %1"
+  [(set_attr "type""arith")
+   (set_attr "mode""SI")
+   (set_attr "length"  "6")])
+
 (define_insn "ashrsi3"
   [(set (match_operand:SI 0 "register_operand" "=a,a")
(ashiftrt:SI (match_operand:SI 1 "register_operand" "r,r")
@@ -1095,6 +1116,17 @@
(set_attr "mode""SI")
(set_attr "length"  "3,6")])
 
+(define_insn "*ashrsi3_3x"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+   (ashiftrt:SI (match_operand:SI 1 "register_operand" "r")
+(ashift:SI (match_operand:SI 2 "register_operand" "r")
+   (const_int 3]
+  ""
+  "ssa8l\t%2\;sra\t%0, %1"
+  [(set_attr "type""arith")
+   (set_attr "mode""SI")
+   (set_attr "length"  "6")])
+
 (define_insn "lshrsi3"
   [(set (match_operand:SI 0 "register_operand" "=a,a")
(lshiftrt:SI (match_operand:SI 1 "register_operand" "r,r")
@@ -1114,6 +1146,17 @@
(set_attr "mode""SI")
(set_attr "length"  "3,6")])
 
+(define_insn "*lshrsi3_3x"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+   (lshiftrt:SI (match_operand:SI 1 "register_operand" "r")
+(ashift:SI (match_operand:SI 2 "register_operand" "r")
+   (const_int 3]
+  ""
+  "ssa8l\t%2\;srl\t%0, %1"
+  [(set_attr "type""arith")
+   (set_attr "mode""SI")
+   (set_attr "length"  "6")])
+
 (define_insn "rotlsi3"
   [(set (match_operand:SI 0 "register_operand" "=a,a")
(rotate:SI (match_operand:SI 1 "register_operand" "r,r")
diff --git a/gcc/testsuite/gcc.target/xtensa/shifts.c 
b/gcc/testsuite/gcc.target/xtensa/shifts.c
new file mode 100644
index ..8d7e4a928d3a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/shifts.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+int lshift1(int v)
+{
+  return v << 1;
+}
+
+int lshift2(int v, int s)
+{
+  return v << (s * 8);
+}
+
+unsigned int lshift3(unsigned int v, int s)
+{
+  return v << (s * 8);
+}
+
+int rshift1(int v, int s)
+{
+  return v >> (s * 8);
+}
+
+unsigned int rshift2(unsigned int v, int s)
+{
+  return v >> (s * 8);
+}
+
+/* { dg-final { scan-assembler-not "slli" } } */
+/* { dg-final { scan-assembler-times "ssa8l" 2 } } */
+/* { dg-final { scan-assembler-times "ssa8b" 2 } } */
-- 
2.20.1

Re: [20/23] rtlanal: Add simple_regno_set

[Richard Sandiford via Gcc-patches]

Jeff Law  writes:
> On 11/13/20 1:21 AM, Richard Sandiford via Gcc-patches wrote:
>> This patch adds a routine for finding a “simple” SET for a register
>> definition.  See the comment in the patch for details.
>>
>> gcc/
>>  * rtl.h (simple_regno_set): Declare.
>>  * rtlanal.c (simple_regno_set): New function.
> So I was a bit confused that this is supposed to reject read-write, but
> what it's really rejecting is a narrow subset of read-write.  In
> particular it rejects things that are potentially RMW via subregs. It
> doesn't prevent the destination from appearing as a source operand.  You
> might consider clarifying the comment.

Yeah, in hindsight it was a mistake to spell out the RMW point
separately when it was really just an extra condition on the subreg.

I'd tweaked this comment and the mux-utils.h one (in response
to Martin's feedback) while doing the cross-target testing,
but forgot to include the changes to the committed version.
(The tested versions were otherwise identical, honest.)

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

Thanks,
Richard


gcc/
* mux-utils.h (pointer_mux::m_ptr): Tweak description of contents.
* rtlanal.c (simple_regno_set): Tweak description to clarify the
RMW condition.
---
 gcc/mux-utils.h | 8 
 gcc/rtlanal.c   | 8 +---
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/gcc/mux-utils.h b/gcc/mux-utils.h
index b026a9fa4c1..6ec0669256d 100644
--- a/gcc/mux-utils.h
+++ b/gcc/mux-utils.h
@@ -139,10 +139,10 @@ public:
 private:
   pointer_mux (char *ptr) : m_ptr (ptr) {}
 
-  // The pointer value for A pointers, or the pointer value + 1 for B pointers.
-  // Using a pointer rather than a uintptr_t tells the compiler that second ()
-  // can never return null, and that second_or_null () is only null if
-  // is_first ().
+  // Points to the first byte of an object for A pointers or the second
+  // byte of an object for B pointers.  Using a pointer rather than a
+  // uintptr_t tells the compiler that second () can never return null,
+  // and that second_or_null () is only null if is_first ().
   char *m_ptr;
 };
 
diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index 80e72d6049d..f0e66a7b26b 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -1458,11 +1458,13 @@ set_of (const_rtx pat, const_rtx insn)
 /* Check whether instruction pattern PAT contains a SET with the following
properties:
 
-   - the SET is executed unconditionally;
-   - the destination of the SET is write-only rather than read-write; and
+   - the SET is executed unconditionally; and
- either:
  - the destination of the SET is a REG that contains REGNO; or
- - the destination of the SET is a SUBREG of such a REG.
+ - both:
+   - the destination of the SET is a SUBREG of such a REG; and
+   - writing to the subreg clobbers all of the SUBREG_REG
+(in other words, read_modify_subreg_p is false).
 
If PAT does have a SET like that, return the set, otherwise return null.
 

Re: [PATCH 23/23] fwprop: Rewrite to use RTL SSA

[Richard Sandiford via Gcc-patches]

Jeff Law via Gcc-patches  writes:
> On 11/13/20 1:24 AM, Richard Sandiford via Gcc-patches wrote:
>> This patch rewrites fwprop.c to use the RTL SSA framework.  It tries
>> as far as possible to mimic the old behaviour, even in caes where
>> that doesn't fit naturally with the new framework.  I've added ???
>> comments to mark those places, but I think “fixing” them should
>> be done separately to make bisection easier.
>>
>> In particular:
>>
>> * The old implementation iterated over uses, and after a successful
>>   substitution, the new insn's uses were added to the end of the list.
>>   The pass still processed those uses, but because it processed them at
>>   the end, it didn't fully optimise one instruction before propagating
>>   it into the next.
>>
>>   The new version follows the same approach for comparison purposes,
>>   but I'd like to drop that as a follow-on patch.
>>
>> * The old implementation operated on single use sites (DF_REF_LOCs).
>>   This doesn't work well for instructions with match_dups, where it's
>>   necessary to update both an operand and its dups at the same time.
>>   For example, attempting to substitute into a divmod instruction would
>>   fail because only the div or the mod side would be updated.
>>
>>   The new version again follows this to some extent for comparison
>>   purposes (although not exactly).  Again I'd like to drop it as a
>>   follow-on patch.
>>
>>   One difference is that if a register occurs in multiple MEM addresses
>>   in a set, the new version will try to update them all at once.  This is
>>   what causes the SVE ACLE st4* output to improve.
>>
>> Also, the old version didn't naturally guarantee termination (PR79405),
>> whereas the new one does.
>>
>> gcc/
>>  * fwprop.c: Rewrite to use the RTL SSA framework.
>>
>> gcc/testsuite/
>>  * gcc.dg/rtl/x86_64/test-return-const.c.before-fwprop.c: Don't
>>  expect insn updates to be deferred.
>>  * gcc.target/aarch64/sve/acle/asm/st4_s8.c: Expect the addition
>>  to be folded into the address.
>>  * gcc.target/aarch64/sve/acle/asm/st4_s8.c: Likewise.
> Consider killing the ADD_NOTES bits.

Done (and glad to see it go).

> s/eqaul/equal/ to fix a typo.

Oops, fixed.

> Naturally I'm happy at how much by-hand RTL analysis code just
> disappears with this change :-)
>
> Ideally you'll drop this in tomorrow and we can get a fresh run of all
> the targets in my tester before the weekend.  I won't be stressed if we
> see some fallout, but I don't expect much.  I'll help track them down if
> they occur.

Thanks, now pushed with the above changes.

Richard

Re: [PATCH 22/23] Add rtl-ssa

[Richard Sandiford via Gcc-patches]

Jeff Law via Gcc-patches  writes:
> On 11/13/20 1:23 AM, Richard Sandiford via Gcc-patches wrote:
>> This patch adds the RTL SSA infrastructure itself.  The following
>> fwprop.c patch will make use of it.
>>
>> gcc/
>>  * configure.ac: Add rtl-ssa to the list of dependence directories.
>>  * configure: Regenerate.
>>  * Makefile.in (rtl-ssa-warn): New variable.
>>  (OBJS): Add the rtl-ssa object files.
>>  * emit-rtl.h (rtl_data::ssa): New field.
>>  * rtl-ssa.h: New file.
>>  * system.h: Include  when INCLUDE_FUNCTIONAL is defined.
>>  * rtl-ssa: New directory.
> So I know its late in stage3, but I think the risks here are relatively
> minor as this would only be used in fwprop right now and it was posted
> in advance of the deadline.
>
> My high level questions/concerns have been addressed and while I
> strongly suspect we'll have to iterate on infrastructure, I think we can
> do that on demand as passes start to use the infrastructure and we have
> a clearer picture of what tweaks we need to make for the clients.

Agreed.  And I agree we'll need to iterate.  What's there now certainly
isn't complete.

> Obviously we'll want to keep an eye on testresults, but again, the
> potential for fallout here is relatively minor IMHO.  OK for the trunk.

Thanks a lot for the reviews.  Now pushed after retesting on
aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf
(as far as I could given the current state), x86_64-linux-gnu
and powerpc64le-linux-gnu.

Richard

Re: [08/23] Add an alternative splay tree implementation

[Richard Sandiford via Gcc-patches]

Jeff Law  writes:
> On 11/13/20 1:15 AM, Richard Sandiford via Gcc-patches wrote:
>> We already have two splay tree implementations: the old C one in
>> libiberty and a templated reimplementation of it in typed-splay-tree.h.
>> However, they have some drawbacks:
>>
>> - They hard-code the assumption that nodes should have both a key and
>>   a value, which isn't always true.
>>
>> - They use the two-phase method of lookup, and so nodes need to store
>>   a temporary back pointer.  We can avoid that overhead by using the
>>   top-down method (as e.g. the bitmap tree code already does).
>>
>> - The tree node has to own the key and the value.  For some use cases
>>   it's more convenient to embed the tree links in the value instead.
>>
>> Also, a later patch wants to use splay trees to represent an
>> adaptive total order: the splay tree itself records whether node N1
>> is less than node N2, and (in the worst case) comparing nodes is
>> a splay operation.
>>
>> This patch therefore adds an alternative implementation.  The main
>> features are:
>>
>> - Nodes can optionally point back to their parents.
>>
>> - An Accessors class abstracts accessing child nodes and (where
>>   applicable) parent nodes, so that the information can be embedded
>>   in larger data structures.
>>
>> - There is no fixed comparison function at the class level.  Instead,
>>   individual functions that do comparisons take a comparison function
>>   argument.
>>
>> - There are two styles of comparison function, optimised for different
>>   use cases.  (See the comments in the patch for details.)
>>
>> - It's possible to do some operations directly on a given node,
>>   without knowing whether it's the root.  This includes the comparison
>>   use case described above.
>>
>> This of course has its own set of drawbacks.  It's really providing
>> splay utility functions rather than a true ADT, and so is more low-level
>> than the existing routines.  It's mostly geared for cases in which the
>> client code wants to participate in the splay operations to some extent.
>>
>> gcc/
>>  * Makefile.in (OBJS): Add splay-tree-utils.o.
>>  * system.h: Include  when INCLUDE_ARRAY is defined.
>>  * selftest.h (splay_tree_cc_tests): Declare.
>>  * selftest-run-tests.c (selftest::run_tests): Run splay_tree_cc_tests.
>>  * splay-tree-utils.h: New file.
>>  * splay-tree-utils.tcc: Likewise.
>>  * splay-tree-utils.cc: Likewise.
> I must admit, I'm not a fan of adding another splay tree.  Though I
> suspect the one in libiberty will be there forever since there could
> well be clients outside our source base.
>
> The typed_splay_tree implementation however is internal to GCC and only
> has a couple users (the JIT and fixit hints).  Is there any chance we
> could convert those two users to the new one?  Your cover hints that's
> not the case, but I'm going to explicitly ask :-)

Yeah, I agree it's not great to have three versions.  I had a look at
converting the uses of typed_splay_tree, and all of them seem to be a
natural fit for the new scheme.  In particular, although typed_splay_tree
maps keys to values, in practice the keys are already part of the values.

However, I think a natural conversion would need a couple of new helpers
for “get or insert” type operations.  Would it be OK to wait until GCC 12
stage 1 for that?

Thanks,
Richard

Re: [16/23] recog: Add a way of temporarily undoing changes

[Richard Sandiford via Gcc-patches]

Jeff Law via Gcc-patches  writes:
> On 11/13/20 1:19 AM, Richard Sandiford via Gcc-patches wrote:
>> In some cases, it can be convenient to roll back the changes that
>> have been made by validate_change to see how things looked before,
>> then reroll the changes.  For example, this makes it possible
>> to defer calculating the cost of an instruction until we know that
>> the result is actually needed.  It can also make dumps easier to read.
>>
>> This patch adds a couple of helper functions for doing that.
>>
>> gcc/
>>  * recog.h (temporarily_undo_changes, redo_changes): Declare.
>>  * recog.c (swap_change, temporarily_undo_changes): New functions.
>>  (redo_changes): Likewise.
> OK...  But...
> +
>> +/* Temporarily undo all the changes numbered NUM and up, with a view
>> +   to reapplying them later.  The next call to the changes machinery
>> +   must be:
>> +
>> +  redo_changes (NUM)
>> +
>> +   otherwise things will end up in an invalid state.  */
> It'd be nice if we had state validation in the other routines. Somebody
> is likely to mess this up at some point...

Yeah, good point, can definitely see myself doing that. :-)

Here's the version I committed, with temporarily_undone_changes tracking
what has been undone.

Thanks,
Richard


gcc/
* recog.h (temporarily_undo_changes, redo_changes): Declare.
* recog.c (temporarily_undone_changes): New variable.
(validate_change_1, confirm_change_group): Check that it's zero.
(cancel_changes): Likewise.
(swap_change, temporarily_undo_changes): New functions.
(redo_changes): Likewise.
---
 gcc/recog.c | 48 
 gcc/recog.h |  2 ++
 2 files changed, 50 insertions(+)

diff --git a/gcc/recog.c b/gcc/recog.c
index 65125b8f0d1..cee481f4fa0 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -193,6 +193,7 @@ static change_t *changes;
 static int changes_allocated;
 
 static int num_changes = 0;
+static int temporarily_undone_changes = 0;
 
 /* Validate a proposed change to OBJECT.  LOC is the location in the rtl
at which NEW_RTX will be placed.  If NEW_LEN is >= 0, XVECLEN (NEW_RTX, 0)
@@ -218,6 +219,7 @@ static bool
 validate_change_1 (rtx object, rtx *loc, rtx new_rtx, bool in_group,
   bool unshare, int new_len = -1)
 {
+  gcc_assert (temporarily_undone_changes == 0);
   rtx old = *loc;
 
   /* Single-element parallels aren't valid and won't match anything.
@@ -506,6 +508,7 @@ confirm_change_group (void)
   int i;
   rtx last_object = NULL;
 
+  gcc_assert (temporarily_undone_changes == 0);
   for (i = 0; i < num_changes; i++)
 {
   rtx object = changes[i].object;
@@ -561,6 +564,7 @@ num_validated_changes (void)
 void
 cancel_changes (int num)
 {
+  gcc_assert (temporarily_undone_changes == 0);
   int i;
 
   /* Back out all the changes.  Do this in the opposite order in which
@@ -577,6 +581,50 @@ cancel_changes (int num)
   num_changes = num;
 }
 
+/* Swap the status of change NUM from being applied to not being applied,
+   or vice versa.  */
+
+static void
+swap_change (int num)
+{
+  if (changes[num].old_len >= 0)
+std::swap (XVECLEN (*changes[num].loc, 0), changes[num].old_len);
+  else
+std::swap (*changes[num].loc, changes[num].old);
+  if (changes[num].object && !MEM_P (changes[num].object))
+std::swap (INSN_CODE (changes[num].object), changes[num].old_code);
+}
+
+/* Temporarily undo all the changes numbered NUM and up, with a view
+   to reapplying them later.  The next call to the changes machinery
+   must be:
+
+  redo_changes (NUM)
+
+   otherwise things will end up in an invalid state.  */
+
+void
+temporarily_undo_changes (int num)
+{
+  gcc_assert (temporarily_undone_changes == 0 && num <= num_changes);
+  for (int i = num_changes - 1; i >= num; i--)
+swap_change (i);
+  temporarily_undone_changes = num_changes - num;
+}
+
+/* Redo the changes that were temporarily undone by:
+
+  temporarily_undo_changes (NUM).  */
+
+void
+redo_changes (int num)
+{
+  gcc_assert (temporarily_undone_changes == num_changes - num);
+  for (int i = num; i < num_changes; ++i)
+swap_change (i);
+  temporarily_undone_changes = 0;
+}
+
 /* Reduce conditional compilation elsewhere.  */
 /* A subroutine of validate_replace_rtx_1 that tries to simplify the resulting
rtx.  */
diff --git a/gcc/recog.h b/gcc/recog.h
index e152e2bb591..facf36e7c08 100644
--- a/gcc/recog.h
+++ b/gcc/recog.h
@@ -96,6 +96,8 @@ extern void confirm_change_group (void);
 extern int apply_change_group (void);
 extern int num_validated_changes (void);
 extern void cancel_changes (int);
+extern void temporarily_undo_changes (int);
+extern void redo_changes (int);
 extern int constrain_operands (int, alternative_mask);
 extern int constrain_operands_cached (rtx_insn *, int);
 extern int memory_address_addr_space_p (machine_mode, rtx, addr_space_t);

Re: [07/23] Add a class that multiplexes two pointer types

[Richard Sandiford via Gcc-patches]

Martin Sebor  writes:
> On 11/26/20 10:06 AM, Richard Sandiford wrote:
>> Martin Sebor  writes:
>>> I do have one concern: the tendency to prioritize efficiency
>>> over safety (this can be said about most GCC code). Specifically
>>> in this class, the address bit twiddling makes me uneasy.  I don't
>>> think the object model in either language (certainly not C but
>>> I don't have the impression C++ either) makes it unequivocally
>>> valid.  On the contrary, I'd say many of us interpret the current
>>> rules as leaving it undefined.  There are efforts to sanction
>>> this sort of thing under some conditions (e.g, the C object
>>> model proposal) but they have not been adopted yet.  I think
>>> we should try to avoid exploiting these dark corners in new
>>> code.
>> 
>> I'd tried to stick to operations that I thought were well-defined.
>> The primitives being used are really:
>> 
>> (1) convert a T1* or T2* to char*
>> (2) increment an unincremented char*
>> (3) decrement an incremented char*
>> (4) convert a char* back to T1* or T2*
>> (5) convert a char* to an intptr_t in order to test its low bit
>
> All those are valid as long as the pointer points into the same
> object, both before and after.
>
>> I thought (1) and (4) were allowed.  At least, [basic.compound] says
>> that void* must be able to hold any object pointer and that it must have
>> the same representation as char*, so I thought the conversion in (1) was
>> guaranteed to be representable.  And (4) only ever undoes (1): it only
>> converts the result of (1) back to the original pointer type.
>> 
>> For (2) and (3), the incremented pointer will still be within the
>> containing object, so I thought it would be well-defined.  Here too,
>> (3) only ever undoes (2): it only decrements a pointer that had
>> previously been incremented.
>> 
>> One thing I'd deliberately tried to avoid was converting integers
>> “back” to pointers, because that seemed like a more dangerous thing.
>> That's why:
>> 
 +template
 +inline T2 *
 +pointer_mux::second_or_null () const
 +{
 +  // Micro optimization that's effective as of GCC 11: compute the value
 +  // of the second pointer as an integer and test that, so that the 
 integer
 +  // result can be reused as the pointer and so that all computation can
 +  // happen before a branch on null.  This reduces the number of branches
 +  // needed for loops.
 +  return uintptr_t (m_ptr - 1) & 1 ? nullptr : known_second ();
>
> This is only valid if m_ptr points to the second byte of an object.
> If it points to the first byte of A then it's invalid.  This would
> make the test valid but the result strictly unspecified (though in
> practice I'd expect it to do what you expect):
>
>return (uintptr_t (m_ptr) - 1) & 1 ? nullptr : known_second ();

Yeah, I think that's what I meant to write (and was what I thought
the code said when I quoted it, without looking properly).  It does
seem to preserve the optimisation.

Here's what I installed after retesting.

Thanks,
Richard


gcc/
* mux-utils.h: New file.
---
 gcc/mux-utils.h | 251 
 1 file changed, 251 insertions(+)
 create mode 100644 gcc/mux-utils.h

diff --git a/gcc/mux-utils.h b/gcc/mux-utils.h
new file mode 100644
index 000..b026a9fa4c1
--- /dev/null
+++ b/gcc/mux-utils.h
@@ -0,0 +1,251 @@
+// Multiplexer utilities
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of GCC.
+//
+// GCC is free software; you can redistribute it and/or modify it under
+// the terms of the GNU General Public License as published by the Free
+// Software Foundation; either version 3, or (at your option) any later
+// version.
+//
+// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+// WARRANTY; without even the implied warranty of MERCHANTABILITY or
+// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+// for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with GCC; see the file COPYING3.  If not see
+// .
+
+#ifndef GCC_MUX_UTILS_H
+#define GCC_MUX_UTILS_H 1
+
+// A class that stores a choice "A or B", where A has type T1 * and B has
+// type T2 *.  Both T1 and T2 must have an alignment greater than 1, since
+// the low bit is used to identify B over A.  T1 and T2 can be the same.
+//
+// A can be a null pointer but B cannot.
+//
+// Barring the requirement that B must be nonnull, using the class is
+// equivalent to using:
+//
+// union { T1 *A; T2 *B; };
+//
+// and having a separate tag bit to indicate which alternative is active.
+// However, using this class can have two advantages over a union:
+//
+// - It avoides the need to find somewhere to store the tag bit.
+//
+// - The compiler is aware that B cannot be null, which can make checks
+//   of the form:
+//
+//   if (auto *B = mux.dyn_cast ())
+//
+//   more 

Re: [PATCH v2] Add --ld-path= to specify an arbitrary executable as the linker

[Fāng-ruì Sòng via Gcc-patches]

On Fri, Dec 4, 2020 at 5:45 AM Martin Liška  wrote:
>
> PING
>
> May I please ping the patch, it's waiting here for a review
> for quite some time.
>
> Thanks,
> Martin

Ping. I think Martin LGTMed this patch and was waiting for a
maintainer to merge it

> On 7/23/20 12:17 PM, Martin Liška wrote:
> > On 7/21/20 6:07 AM, Fangrui Song wrote:
> >> If the value does not contain any path component separator (e.g. a
> >> slash), the linker will be searched for using COMPILER_PATH followed by
> >> PATH. Otherwise, it is either an absolute path or a path relative to the
> >> current working directory.
> >>
> >> --ld-path= complements and overrides -fuse-ld={bfd,gold,lld}. If in the
> >> future, we want to make dfferent linker option decisions we can let
> >> -fuse-ld= represent the linker flavor and --ld-path= the linker path.
> >
> > Hello.
> >
> > I have just few nits:
> >
> > === ERROR type #3: trailing operator (1 error(s)) ===
> > gcc/collect2.c:1155:14:ld_file_name =
> >
> >>
> >> PR driver/93645
> >> * common.opt (--ld-path=): Add --ld-path=
> >> * opts.c (common_handle_option): Handle OPT__ld_path_.
> >> * gcc.c (driver_handle_option): Likewise.
> >> * collect2.c (main): Likewise.
> >> * doc/invoke.texi: Document --ld-path=.
> >>
> >> ---
> >> Changes in v2:
> >> * Renamed -fld-path= to --ld-path= (clang 12.0.0 new option).
> >>The option does not affect code generation and is not a language 
> >> feature,
> >>-f* is not suitable. Additionally, clang has other similar --*-path=
> >>options, e.g. --cuda-path=.
> >> ---
> >>   gcc/collect2.c  | 63 +++--
> >>   gcc/common.opt  |  4 +++
> >>   gcc/doc/invoke.texi |  9 +++
> >>   gcc/gcc.c   |  2 +-
> >>   gcc/opts.c  |  1 +
> >>   5 files changed, 64 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/gcc/collect2.c b/gcc/collect2.c
> >> index f8a5ce45994..caa1b96ab52 100644
> >> --- a/gcc/collect2.c
> >> +++ b/gcc/collect2.c
> >> @@ -844,6 +844,7 @@ main (int argc, char **argv)
> >> const char **ld1;
> >> bool use_plugin = false;
> >> bool use_collect_ld = false;
> >> +  const char *ld_path = NULL;
> >> /* The kinds of symbols we will have to consider when scanning the
> >>outcome of a first pass link.  This is ALL to start with, then might
> >> @@ -961,12 +962,21 @@ main (int argc, char **argv)
> >>   if (selected_linker == USE_DEFAULT_LD)
> >> selected_linker = USE_PLUGIN_LD;
> >> }
> >> -else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
> >> -  selected_linker = USE_BFD_LD;
> >> -else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
> >> -  selected_linker = USE_GOLD_LD;
> >> -else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
> >> -  selected_linker = USE_LLD_LD;
> >> +else if (strncmp (argv[i], "-fuse-ld=", 9) == 0
> >> + && selected_linker != USE_LD_MAX)
> >> +  {
> >> +if (strcmp (argv[i] + 9, "bfd") == 0)
> >> +  selected_linker = USE_BFD_LD;
> >> +else if (strcmp (argv[i] + 9, "gold") == 0)
> >> +  selected_linker = USE_GOLD_LD;
> >> +else if (strcmp (argv[i] + 9, "lld") == 0)
> >> +  selected_linker = USE_LLD_LD;
> >> +  }
> >> +else if (strncmp (argv[i], "--ld-path=", 10) == 0)
> >> +  {
> >> +ld_path = argv[i] + 10;
> >> +selected_linker = USE_LD_MAX;
> >> +  }
> >>   else if (strncmp (argv[i], "-o", 2) == 0)
> >> {
> >>   /* Parse the output filename if it's given so that we can make
> >> @@ -1117,14 +1127,34 @@ main (int argc, char **argv)
> >> ld_file_name = find_a_file (, collect_ld_suffix, X_OK);
> >> use_collect_ld = ld_file_name != 0;
> >>   }
> >> -  /* Search the compiler directories for `ld'.  We have protection against
> >> - recursive calls in find_a_file.  */
> >> -  if (ld_file_name == 0)
> >> -ld_file_name = find_a_file (, ld_suffixes[selected_linker], 
> >> X_OK);
> >> -  /* Search the ordinary system bin directories
> >> - for `ld' (if native linking) or `TARGET-ld' (if cross).  */
> >> -  if (ld_file_name == 0)
> >> -ld_file_name = find_a_file (, full_ld_suffixes[selected_linker], 
> >> X_OK);
> >> +  if (selected_linker == USE_LD_MAX)
> >> +{
> >> +  /* If --ld-path= does not contain a path component separator, 
> >> search for
> >> + the command using cpath, then using path.  Otherwise find the linker
> >> + relative to the current working directory.  */
> >> +  if (lbasename (ld_path) == ld_path)
> >> +{
> >> +  ld_file_name = find_a_file (, ld_path, X_OK);
> >> +  if (ld_file_name == 0)
> >> +ld_file_name = find_a_file (, ld_path, X_OK);
> >> +}
> >> +  else if (file_exists (ld_path))
> >> +{
> >
> > ^^^ these braces are not needed.
> >
> >> +  ld_file_name = ld_path;
> >> +}
> >> +}
> >> +  else
> >> +{
> >> +  /* Search the 

Re: [PATCH 4/1] c++: More precise tracking of potentially unstable satisfaction

[Patrick Palka via Gcc-patches]

On Wed, 16 Dec 2020, Jason Merrill wrote:

> On 12/14/20 3:29 PM, Patrick Palka wrote:
> > On Mon, 14 Dec 2020, Jason Merrill wrote:
> > 
> > > On 12/14/20 1:07 PM, Patrick Palka wrote:
> > > > This makes tracking of potentially unstable satisfaction results more
> > > > precise by recording the specific types for which completion failed
> > > > during satisfaction.  We now recompute a satisfaction result only if one
> > > > of these types has been completed since the last time we computed the
> > > > satisfaction result.  Thus the number of times that we recompute a
> > > > satisfaction result is now bounded by the number of such incomplete
> > > > types, rather than being effectively unbounded.  This allows us to
> > > > remove the invalid assumption in note_ftc_for_satisfaction that was
> > > > added to avoid a compile time performance regression in cmcstl2 due to
> > > > repeated re-computation of a satisfaction result that depended on
> > > > completion of a permanently incomplete class template specialization.
> > > > 
> > > > In order to continue to detect the instability in concepts-complete3.C,
> > > > we also need to explicitly keep track of return type deduction failure
> > > > alongside type completion failure.  So this patch also adds a call to
> > > > note_ftc_for_satisfaction in require_deduced_type.
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * constraint.cc (failed_type_completion_count): Remove.
> > > > (failed_type_completions): Define.
> > > > (note_failed_type_completion_for_satisfaction): Append the
> > > > supplied argument to failed_type_completions.
> > > > (some_type_complete_p): Define.
> > > > (sat_entry::maybe_unstable): Replace with ...
> > > > (sat_entry::ftc_begin, sat_entry::ftc_end): ... these.
> > > > (satisfaction_cache::ftc_count): Replace with ...
> > > > (satisfaction_cache::ftc_begin): ... this.
> > > > (satisfaction_cache::satisfaction_cache): Adjust accordingly.
> > > > (satisfaction_cache::get): Adjust accordingly, using
> > > > some_type_complete_p.
> > > > (satisfaction_cache::save): Adjust accordingly.
> > > > (satisfy_declaration_constraints): Likewise.
> > > > * decl.c (require_deduced_type): Call
> > > > note_failed_type_completion_for_satisfaction.
> > > > ---
> > > >gcc/cp/constraint.cc | 89
> > > > +++-
> > > >gcc/cp/decl.c|  1 +
> > > >2 files changed, 56 insertions(+), 34 deletions(-)
> > > > 
> > > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > > > index dc5c34e7e91..fd5d9429c9d 100644
> > > > --- a/gcc/cp/constraint.cc
> > > > +++ b/gcc/cp/constraint.cc
> > > > @@ -2374,26 +2374,44 @@ tsubst_parameter_mapping (tree map, tree args,
> > > > tsubst_flags_t complain, tree in_
> > > >Constraint satisfaction
> > > >
> > > > ---*/
> > > >-/* A counter incremented by
> > > > note_failed_type_completion_for_satisfaction().
> > > > -   It's used by the satisfaction caches in order to flag "potentially
> > > > unstable"
> > > > -   satisfaction results.  */
> > > > +/* A vector of incomplete types (and declarations with undeduced return
> > > > types),
> > > > +   appended to by note_failed_type_completion_for_satisfaction.  The
> > > > +   satisfaction caches use this in order to keep track of "potentially
> > > > unstable"
> > > > +   satisfaction results.
> > > >-static unsigned failed_type_completion_count;
> > > > +   Since references to entries in vector are stored only in the
> > > > GC-deletable
> > > > +   sat_cache, it's safe to make this deletable as well.  */
> > > >-/* Called whenever a type completion failure occurs that definitely
> > > > affects
> > > > -   the semantics of the program, by e.g. inducing substitution failure.
> > > > */
> > > > +static GTY((deletable)) vec *failed_type_completions;
> > > 
> > > > +/* Called whenever a type completion (or return type deduction) failure
> > > > occurs
> > > > +   that definitely affects the semantics of the program, by e.g.
> > > > inducing
> > > > +   substitution failure.  */
> > > >  void
> > > > -note_failed_type_completion_for_satisfaction (tree type)
> > > > -{
> > > > -  gcc_checking_assert (!COMPLETE_TYPE_P (type));
> > > > -  if (CLASS_TYPE_P (type)
> > > > -  && CLASSTYPE_TEMPLATE_INSTANTIATION (type))
> > > > -/* After instantiation, a class template specialization that's
> > > > -   incomplete will remain incomplete, so for our purposes we can
> > > > -   ignore this completion failure event.  */;
> > > > -  else
> > > > -++failed_type_completion_count;
> > > > +note_failed_type_completion_for_satisfaction (tree t)
> > > > +{
> > > > +  gcc_checking_assert ((TYPE_P (t) && !COMPLETE_TYPE_P (t))
> > > > +  || (DECL_P (t) && 

[PATCH] c++tools: Fix up c++tools for --with-gcc-major-version-only

[Jakub Jelinek via Gcc-patches]

Hi!

Seems c++tools doesn't honor --with-gcc-major-version-only.
Our distro uses that flag and so everything is installed in
/usr/lib/gcc//11/...
/usr/libexec/gcc//11/...
except
/usr/libexec/gcc//11.0.0/g++-mapper-server

The following patch should fix that, ok for trunk if it passes testing?

2020-12-17  Jakub Jelinek  

* configure.ac: Add GCC_BASE_VER.
* Makefile.in (version): Remove variable.
(gcc_version): New variable.
(libexecsubdir): Use $(gcc_version) instead of $(version).
* configure: Regenerated.

--- c++tools/configure.ac.jj2020-12-16 23:38:34.091923526 +0100
+++ c++tools/configure.ac   2020-12-17 00:02:48.221661922 +0100
@@ -206,6 +206,9 @@ if test $ac_cv_inet_ntop = yes; then
   [Define if inet_ntop provided.])
 fi
 
+# Determine what GCC version number to use in filesystem paths.
+GCC_BASE_VER
+
 AC_CONFIG_HEADERS([config.h])
 AC_CONFIG_FILES([Makefile])
 
--- c++tools/Makefile.in.jj 2020-12-16 23:38:34.091923526 +0100
+++ c++tools/Makefile.in2020-12-17 00:01:54.419263424 +0100
@@ -20,8 +20,8 @@ prefix := @prefix@
 bindir := @bindir@
 libexecdir := @libexecdir@
 target_noncanonical := @target_noncanonical@
-version := $(shell cat $(srcdir)/../gcc/BASE-VER)
-libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(version)
+gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER)
+libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version)
 INSTALL_PROGRAM := @INSTALL_PROGRAM@
 INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s
 AUTOCONF := @AUTOCONF@
--- c++tools/configure.jj   2020-12-16 23:38:34.091923526 +0100
+++ c++tools/configure  2020-12-17 00:02:53.849599006 +0100
@@ -585,6 +585,7 @@ ac_unique_file="c++tools"
 ac_unique_file="server.cc"
 ac_subst_vars='LTLIBOBJS
 LIBOBJS
+get_gcc_base_ver
 ac_ct_CC
 CFLAGS
 CC
@@ -658,6 +659,7 @@ ac_user_opts='
 enable_option_checking
 enable_c___tools
 enable_maintainer_mode
+with_gcc_major_version_only
 '
   ac_precious_vars='build_alias
 host_alias
@@ -1287,6 +1289,12 @@ Optional Features:
   enable maintainer mode. Add rules to rebuild
   configurey bits
 
+Optional Packages:
+  --with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
+  --without-PACKAGE   do not use PACKAGE (same as --with-PACKAGE=no)
+  --with-gcc-major-version-only
+  use only GCC major number in filesystem paths
+
 Some influential environment variables:
   CXX C++ compiler command
   CXXFLAGSC++ compiler flags
@@ -3557,6 +3565,21 @@ $as_echo "#define HAVE_INET_NTOP 1" >>co
 
 fi
 
+# Determine what GCC version number to use in filesystem paths.
+
+  get_gcc_base_ver="cat"
+
+# Check whether --with-gcc-major-version-only was given.
+if test "${with_gcc_major_version_only+set}" = set; then :
+  withval=$with_gcc_major_version_only; if test x$with_gcc_major_version_only 
= xyes ; then
+get_gcc_base_ver="sed -e 's/^\([0-9]*\).*/\1/'"
+  fi
+
+fi
+
+
+
+
 ac_config_headers="$ac_config_headers config.h"
 
 ac_config_files="$ac_config_files Makefile"

Jakub

Re: rs6000: add support for powerpc64le-unknown-freebsd

[Segher Boessenkool]

On Tue, Dec 15, 2020 at 12:29:45AM +0100, Gerald Pfeifer wrote:
> > The patch looks fine.  Okay for trunk.  Also okay for any backports you 
> > want (after waiting to see if it creates problems on trunk, as usual).
> 
> Thank you! Segher doesn't have write access, and usually I'd help out,
> alas autoconf in GCC-land and me are, um, slightly divergent.

It's not you.  So because this is just three lines, I did manual
surgery.  Someone should fix the generated configure though, it is *not*
generated with 2.69, although it claims it is.

> Any chance (one of you) can help and commit this?

Done now.

Please remind me in a week or so to do the backports?

> To make this easier, I've created a proposal for a full ChangeLog 
> entry. :-)
> 
> 2020-12-15  Piotr Kubaj   
>  
>   * config.gcc (powerpc*le-*-freebsd*): Add. 
>   * configure.ac (powerpc*le-*-freebsd*): Ditto. 
>   * config/rs6000/freebsd64.h (ASM_SPEC_COMMON): Use ENDIAN_SELECT. 
>   (DEFAULT_ASM_ENDIAN): Add little endian support. 
>   (LINK_OS_FREEBSD_SPEC64): Ditto. 

I added an entry for configure, and a little blurb taken from the first
email.

Thanks to both of you,


Segher

Go testsuite patch committed: Add some new tests

[Ian Lance Taylor via Gcc-patches]

This patch adds some new tests from the fixedbugs subdirectory of the
source repo that currently pass with gccgo.  Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
e38c912700f001ea1c8a32533bedb4c802e38d3f
diff --git a/gcc/testsuite/go.test/test/fixedbugs/bug13343.go 
b/gcc/testsuite/go.test/test/fixedbugs/bug13343.go
new file mode 100644
index 000..a7febeae7e0
--- /dev/null
+++ b/gcc/testsuite/go.test/test/fixedbugs/bug13343.go
@@ -0,0 +1,18 @@
+// errorcheck
+
+// Copyright 2015 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package main
+
+var (
+   a, b = f() // ERROR "initialization loop|depends upon itself|depend 
upon each other"
+   c= b   // GCCGO_ERROR "depends upon itself|depend upon each other"
+)
+
+func f() (int, int) {
+   return c, c
+}
+
+func main() {}
diff --git a/gcc/testsuite/go.test/test/fixedbugs/bug19403.go 
b/gcc/testsuite/go.test/test/fixedbugs/bug19403.go
new file mode 100644
index 000..94c0fb47309
--- /dev/null
+++ b/gcc/testsuite/go.test/test/fixedbugs/bug19403.go
@@ -0,0 +1,134 @@
+// run
+
+// Copyright 2017 The Go Authors.  All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// Test for golang.org/issue/19403.
+// F15 should not be clobbered by float-to-int conversion on ARM.
+// This test requires enough locals that can be put in registers that the 
compiler can choose to use F15.
+package main
+
+var count float32 = 16
+var i0 int
+var i1 int
+var i2 int
+var i3 int
+var i4 int
+var i5 int
+var i6 int
+var i7 int
+var i8 int
+var i9 int
+var i10 int
+var i11 int
+var i12 int
+var i13 int
+var i14 int
+var i15 int
+var i16 int
+
+func main() {
+   var f0 float32 = 0.0
+   var f1 float32 = 1.0
+   var f2 float32 = 2.0
+   var f3 float32 = 3.0
+   var f4 float32 = 4.0
+   var f5 float32 = 5.0
+   var f6 float32 = 6.0
+   var f7 float32 = 7.0
+   var f8 float32 = 8.0
+   var f9 float32 = 9.0
+   var f10 float32 = 10.0
+   var f11 float32 = 11.0
+   var f12 float32 = 12.0
+   var f13 float32 = 13.0
+   var f14 float32 = 14.0
+   var f15 float32 = 15.0
+   var f16 float32 = 16.0
+   i0 = int(f0)
+   i1 = int(f1)
+   i2 = int(f2)
+   i3 = int(f3)
+   i4 = int(f4)
+   i5 = int(f5)
+   i6 = int(f6)
+   i7 = int(f7)
+   i8 = int(f8)
+   i9 = int(f9)
+   i10 = int(f10)
+   i11 = int(f11)
+   i12 = int(f12)
+   i13 = int(f13)
+   i14 = int(f14)
+   i15 = int(f15)
+   i16 = int(f16)
+   if f16 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f15 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f14 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f13 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f12 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f11 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f10 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f9 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f8 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f7 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f6 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f5 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f4 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f3 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f2 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f1 != count {
+   panic("fail")
+   }
+   count -= 1
+   if f0 != count {
+   panic("fail")
+   }
+   count -= 1
+}
diff --git a/gcc/testsuite/go.test/test/fixedbugs/bug369.dir/main.go 
b/gcc/testsuite/go.test/test/fixedbugs/bug369.dir/main.go
new file mode 100644
index 000..03b53a5b90d
--- /dev/null
+++ b/gcc/testsuite/go.test/test/fixedbugs/bug369.dir/main.go
@@ -0,0 +1,55 @@
+// Copyright 2011 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package main
+
+import (
+   "flag"
+   "os"
+   "runtime"
+   "testing"
+
+   fast "./fast"
+   slow "./slow"
+)
+
+var buf = make([]byte, 1048576)
+
+func BenchmarkFastNonASCII(b *testing.B) {
+   for i := 0; i < b.N; i++ {
+   fast.NonASCII(buf, 0)
+   }
+}
+
+func BenchmarkSlowNonASCII(b *testing.B) {
+   for i := 0; i < b.N; i++ {
+ 

Re: [PATCH] maintainer-scripts: Prefer temp dir /sourceware/snapshot-tmp/gcc for update_version_git

[Joseph Myers]

On Tue, 15 Dec 2020, Jakub Jelinek via Gcc-patches wrote:

> On Mon, Dec 14, 2020 at 11:58:05PM +, Joseph Myers wrote:
> > > Thanks for heads up. I'm aware of it and I don't see reason why (running 
> > > the
> > > update script in dry mode works).
> > 
> > https://gcc.gnu.org/pipermail/gccadmin/2020q4/017037.html
> > 
> > OSError: [Errno 28] No space left on device: 
> > '/tmp/tmp.Zq3p6D4MxS/gcc/.git/objects/objn31xpefh' -> 
> > '/tmp/tmp.Zq3p6D4MxS/gcc/.git/objects/db/ffb02a4bcdd4ec04af3db75d86b8cc2e52bdff'
> > 
> > Maybe change the script to use /sourceware/snapshot-tmp/gcc (which has 
> > rather more space) instead of /tmp?
> 
> So like this?  Ok for trunk?

OK.

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

Re: rs6000: add support for powerpc64le-unknown-freebsd

[Segher Boessenkool]

On Tue, Dec 15, 2020 at 12:52:05AM +0100, Piotr Kubaj wrote:
> Yes, there is, thanks for noticing that!
> 
> Fixed patch attached.

Hi!

Could you send this as plain text?  It now is quoted-printable, which is
really hard to handle.

Thanks!

Hrm, this is really short, I'll just try to fix it by hand...  Wish me
luck :-)


Segher

[Patch] Fortran: Delay vtab generation until after parsing [PR92587]

[Tobias Burnus]

Calling gfc_find_vtab during resolution during parsing
comes too early for finalizers. This patch just moves it
to the resolution, which seems to be the simplest solution.

(I tried way more complicated ones which do not work; thus,
I settled for the simple solution ...)

OK for GCC 9/10/mainline?

Tobias

PS: I was wondering about FORALL (which is resolved separately),
but as "f = b" does not work (missing loop index) and as
"f(i)%a = b" is broken (no reallocation, no __copy call,
→ https://gcc.gnu.org/PR98336 ) I think no action is needed
for now.

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
Fortran: Delay vtab generation until after parsing [PR92587]

gcc/fortran/ChangeLog:

	PR fortran/92587
	* match.c (gfc_match_assignment): Move gfc_find_vtab call from here ...
	* resolve.c (gfc_resolve_code): ... to here.

gcc/testsuite/ChangeLog:

	PR fortran/92587
	* gfortran.dg/finalize_37.f90: New test.

 gcc/fortran/match.c  |  3 --
 gcc/fortran/resolve.c|  3 ++
 gcc/testsuite/gfortran.dg/finalize_37.f90| 51 
 4 files changed, 80 insertions(+), 3 deletions(-)

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index bee73e7b008..c13fe96ed33 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -1389,9 +1389,6 @@ gfc_match_assignment (void)
 
   gfc_check_do_variable (lvalue->symtree);
 
-  if (lvalue->ts.type == BT_CLASS)
-gfc_find_vtab (>ts);
-
   return MATCH_YES;
 }
 
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 05a5e43c90b..1da7ba4d031 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11896,6 +11896,9 @@ start:
 	  if (!t)
 	break;
 
+	  if (code->expr1->ts.type == BT_CLASS)
+	   gfc_find_vtab (>expr2->ts);
+
 	  /* Remove a GFC_ISYM_CAF_GET inserted for a coindexed variable on
 	 the LHS.  */
 	  if (code->expr1->expr_type == EXPR_FUNCTION
diff --git a/gcc/testsuite/gfortran.dg/finalize_37.f90 b/gcc/testsuite/gfortran.dg/finalize_37.f90
new file mode 100644
index 000..3f872633fdd
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/finalize_37.f90
@@ -0,0 +1,51 @@
+! { dg-do compile }
+! { dg-additional-options "-fdump-tree-original" }
+!
+! PR fortran/92587
+!
+
+module m
+   implicit none (type, external)
+   type t2
+   contains
+  final :: fini
+   end type
+   type t3
+  type(t2) :: a
+   end type
+   type, extends(t3) :: t4
+   end type
+   class(t4), allocatable :: y
+   class(t4), allocatable :: z
+contains
+   subroutine sub
+  y = z
+   end
+   subroutine fini(x)
+ type(t2) :: x
+   end
+end
+
+module m2
+  use m
+  implicit none (type, external)
+  type, extends(t3) :: t5
+  end type
+  type, extends(t3) :: t6
+contains
+  final :: fin2
+  end type
+contains
+  subroutine bar(x, y, z)
+class(t4), allocatable, intent(out) :: x
+class(t5), allocatable, intent(out) :: y
+class(t6), allocatable, intent(out) :: z
+  end
+  subroutine fin2 (x)
+type(t6) :: x
+  end
+end  
+
+! { dg-final { scan-tree-dump "__final_m_T2 \\\(struct" "original" } }
+! { dg-final { scan-tree-dump "__final_m_T3 \\\(struct" "original" } }
+! { dg-final { scan-tree-dump "__final_m2_T6 \\\(struct" "original" } }

Re: [PATCH] add g_nonstandard_bool attribute for GIMPLE FE use

[Joseph Myers]

On Sun, 13 Dec 2020, Martin Sebor via Gcc-patches wrote:

> "nonstandard" isn't a very descriptive name.  The leading g_ prefix
> also looks a little too terse (is that supposed to stand dor GIMPLE?).
> I would suggest choosing a better name, say, bool_precision.  Since

Indeed, g_ suggests the GLib API to me, so a name not involving g_ or 
"nonstandard" seems better.

The principle of a GIMPLE-front-end-specific attribute for this sort of 
thing seems reasonable to me.

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

Re: [C PATCH] Avoid incorrect warning for volatile in compound expressions [PR 98260]

[Joseph Myers]

On Sun, 13 Dec 2020, Uecker, Martin wrote:

> Here is a patch that fixes an incorrect warning for volatile
> that appeared with the lvalue change. 
> 
> 
> -- Martin
> 
> C: Avoid incorrect warning for volatile in compound expressions [PR98260]

OK.

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

Re: [PATCH 4/1] c++: More precise tracking of potentially unstable satisfaction

[Jason Merrill via Gcc-patches]

On 12/14/20 3:29 PM, Patrick Palka wrote:

On Mon, 14 Dec 2020, Jason Merrill wrote:


On 12/14/20 1:07 PM, Patrick Palka wrote:

This makes tracking of potentially unstable satisfaction results more
precise by recording the specific types for which completion failed
during satisfaction.  We now recompute a satisfaction result only if one
of these types has been completed since the last time we computed the
satisfaction result.  Thus the number of times that we recompute a
satisfaction result is now bounded by the number of such incomplete
types, rather than being effectively unbounded.  This allows us to
remove the invalid assumption in note_ftc_for_satisfaction that was
added to avoid a compile time performance regression in cmcstl2 due to
repeated re-computation of a satisfaction result that depended on
completion of a permanently incomplete class template specialization.

In order to continue to detect the instability in concepts-complete3.C,
we also need to explicitly keep track of return type deduction failure
alongside type completion failure.  So this patch also adds a call to
note_ftc_for_satisfaction in require_deduced_type.

gcc/cp/ChangeLog:

* constraint.cc (failed_type_completion_count): Remove.
(failed_type_completions): Define.
(note_failed_type_completion_for_satisfaction): Append the
supplied argument to failed_type_completions.
(some_type_complete_p): Define.
(sat_entry::maybe_unstable): Replace with ...
(sat_entry::ftc_begin, sat_entry::ftc_end): ... these.
(satisfaction_cache::ftc_count): Replace with ...
(satisfaction_cache::ftc_begin): ... this.
(satisfaction_cache::satisfaction_cache): Adjust accordingly.
(satisfaction_cache::get): Adjust accordingly, using
some_type_complete_p.
(satisfaction_cache::save): Adjust accordingly.
(satisfy_declaration_constraints): Likewise.
* decl.c (require_deduced_type): Call
note_failed_type_completion_for_satisfaction.
---
   gcc/cp/constraint.cc | 89 +++-
   gcc/cp/decl.c|  1 +
   2 files changed, 56 insertions(+), 34 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index dc5c34e7e91..fd5d9429c9d 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2374,26 +2374,44 @@ tsubst_parameter_mapping (tree map, tree args,
tsubst_flags_t complain, tree in_
   Constraint satisfaction
   ---*/
   -/* A counter incremented by
note_failed_type_completion_for_satisfaction().
-   It's used by the satisfaction caches in order to flag "potentially
unstable"
-   satisfaction results.  */
+/* A vector of incomplete types (and declarations with undeduced return
types),
+   appended to by note_failed_type_completion_for_satisfaction.  The
+   satisfaction caches use this in order to keep track of "potentially
unstable"
+   satisfaction results.
   -static unsigned failed_type_completion_count;
+   Since references to entries in vector are stored only in the
GC-deletable
+   sat_cache, it's safe to make this deletable as well.  */
   -/* Called whenever a type completion failure occurs that definitely
affects
-   the semantics of the program, by e.g. inducing substitution failure.  */
+static GTY((deletable)) vec *failed_type_completions;



+/* Called whenever a type completion (or return type deduction) failure
occurs
+   that definitely affects the semantics of the program, by e.g. inducing
+   substitution failure.  */
 void
-note_failed_type_completion_for_satisfaction (tree type)
-{
-  gcc_checking_assert (!COMPLETE_TYPE_P (type));
-  if (CLASS_TYPE_P (type)
-  && CLASSTYPE_TEMPLATE_INSTANTIATION (type))
-/* After instantiation, a class template specialization that's
-   incomplete will remain incomplete, so for our purposes we can
-   ignore this completion failure event.  */;
-  else
-++failed_type_completion_count;
+note_failed_type_completion_for_satisfaction (tree t)
+{
+  gcc_checking_assert ((TYPE_P (t) && !COMPLETE_TYPE_P (t))
+  || (DECL_P (t) && undeduced_auto_decl (t)));
+  vec_safe_push (failed_type_completions, t);
+}


It looks like we'll happily add to this table outside of satisfaction, making
it much larger than it needs to be.


I should've mentioned that in practice these events (type completion
failure or return type deduction failure inducing substitution failure)
seem to be rare enough that the vector ends up being very small even
when we append to it outside of satisfaction.  For example the vector
ends up being appended to at most 13 times in any one test in the
libstdc++ ranges testsuite and cmcstl2 testsuite, and so far zero times
when compiling llvm or range-v3.


Good to know, but I would still expect it to be larger in a codebase 
that uses opaque types.


Certainly we shouldn't add to the 

Re: [PATCH] d: Fix ICE in in force_decl_die, at dwarf2out.c with -gdwarf-2 -gstrict-dwarf [PR98067]

[Jason Merrill via Gcc-patches]

On 12/15/20 7:15 PM, Iain Buclaw wrote:

Hi,

This patch fixes an ICE in dwarf2out.c that occurs when compiling a
selective import declaration in D with strict dwarf2 in effect.

Manifest constants in D are represented as CONST_DECLs, which can be
imported from one module to another.  However, when compiling on strict
dwarf2 targets such as *-*darwin10, importing CONST_DECLs cannot be
represented in debug as D did not exist as an AT_language until dwarf3,
and the only available fallback being DW_LANG_C.  As CONST_DECLs are
treated as enumerators in C, and not outputted individually in
gen_decl_die, this causes an internal error in force_decl_die to occur.

To handle this, similar to other places in dwarf2out, if a CONST_DECL is
seen in dwarf2out_imported_module_or_decl_1, then we simply return early
if the language is not one of Ada, D, or Fortran.

The new files and tests added are boilerplate for introducing
gdc.dg/debug and gdc.dg/debug/dwarf2 test directories, as well as two
extra tests - langdw2.d and langdw3.d - that verify that DW_LANG_D is
set except for strict dwarf2.

This has been bootstrapped, and the D testsuite regression tested on
x86_64-linux-gnu/-m32/-mx32.

OK for mainline?


OK.


Iain.

---
gcc/ChangeLog:

PR d/98067
* dwarf2out.c (dwarf2out_imported_module_or_decl_1): Handle
  CONST_DECL only if is_fortran, is_ada, or is_dlang.

gcc/testsuite/ChangeLog:

PR d/98067
* gdc.dg/debug/debug.exp: New test.
* gdc.dg/debug/dwarf2/dwarf2.exp: New test.
* gdc.dg/debug/dwarf2/imports/pr98067.d: New test.
* gdc.dg/debug/dwarf2/langdw2.d: New test.
* gdc.dg/debug/dwarf2/langdw3.d: New test.
* gdc.dg/debug/dwarf2/pr98067.d: New test.
* gdc.dg/debug/trivial.d: New test.
---
  gcc/dwarf2out.c   |  7 
  gcc/testsuite/gdc.dg/debug/debug.exp  | 28 ++
  gcc/testsuite/gdc.dg/debug/dwarf2/dwarf2.exp  | 38 +++
  .../gdc.dg/debug/dwarf2/imports/pr98067.d |  3 ++
  gcc/testsuite/gdc.dg/debug/dwarf2/langdw2.d   |  7 
  gcc/testsuite/gdc.dg/debug/dwarf2/langdw3.d   |  6 +++
  gcc/testsuite/gdc.dg/debug/dwarf2/pr98067.d   |  6 +++
  gcc/testsuite/gdc.dg/debug/trivial.d  |  6 +++
  8 files changed, 101 insertions(+)
  create mode 100644 gcc/testsuite/gdc.dg/debug/debug.exp
  create mode 100644 gcc/testsuite/gdc.dg/debug/dwarf2/dwarf2.exp
  create mode 100644 gcc/testsuite/gdc.dg/debug/dwarf2/imports/pr98067.d
  create mode 100644 gcc/testsuite/gdc.dg/debug/dwarf2/langdw2.d
  create mode 100644 gcc/testsuite/gdc.dg/debug/dwarf2/langdw3.d
  create mode 100644 gcc/testsuite/gdc.dg/debug/dwarf2/pr98067.d
  create mode 100644 gcc/testsuite/gdc.dg/debug/trivial.d

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 0baa056447c..027f327c1a1 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -26705,6 +26705,13 @@ dwarf2out_imported_module_or_decl_1 (tree decl,
  gen_type_die_for_member (type, decl,
   get_context_die (TYPE_CONTEXT (type)));
}
+ if (TREE_CODE (decl) == CONST_DECL)
+   {
+ /* Individual enumerators of an enum type do not get output here
+(see gen_decl_die), so we cannot call force_decl_die.  */
+ if (!is_fortran () && !is_ada () && !is_dlang ())
+   return;
+   }
  if (TREE_CODE (decl) == NAMELIST_DECL)
at_import_die = gen_namelist_decl (DECL_NAME (decl),
 get_context_die (DECL_CONTEXT (decl)),
diff --git a/gcc/testsuite/gdc.dg/debug/debug.exp 
b/gcc/testsuite/gdc.dg/debug/debug.exp
new file mode 100644
index 000..1607c4d6d44
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/debug/debug.exp
@@ -0,0 +1,28 @@
+# Copyright (C) 2020 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# Load support procs.
+load_lib gdc-dg.exp
+
+# Initialize `dg'.
+dg-init
+
+# Main loop.
+gcc-dg-debug-runtest gdc_target_compile trivial.d [list -O -O3] \
+[lsort [glob -nocomplain $srcdir/$subdir/*.d]]
+
+# All done.
+dg-finish
diff --git a/gcc/testsuite/gdc.dg/debug/dwarf2/dwarf2.exp 
b/gcc/testsuite/gdc.dg/debug/dwarf2/dwarf2.exp
new file mode 100644
index 000..11711e197b9
--- /dev/null
+++ 

Re: C++ 20 modules

[Nathan Sidwell]

Several issues have been fixed today:
* Solaris headers 98315 (hopefully finally)
* install-strip  98328
* clang offsetof 98323 (I typoed the PR in the commit)
* libcody enable-checking 98311 (thanks Jakub for the followup)
* source_location etc fix from Jonathan
* More dashisms
* detailed-mem-stat init issue

I'm aware of the following:
* 98324  bootstrap with lto/PIE.  I can reproduce this, investigating
* 98300  windows build, reporter has indicated patch gets further
* 98316  solaris socket lib, Rainer is developing a patch

On 12/15/20 5:33 PM, Nathan Sidwell wrote:
as expected there are a bunch of configurey type errors.  I am aware of 
the following:


windows build (pr 98300), insufficient #ifing.  A patch is being tested

solaris 11, sys/socket.h, bcopy and poisoning.  Asked jwakely to try a 
patch, he seems to have a build set up.


AIX install.  Testing a patch

gcc_update not touching files: fixed

libcody uses too-new options: fixed, hopefully

libcody unused variable: fixed by Marek, thanks!

nathan




--
Nathan Sidwell

Re: [C PATCH] Drop qualifiers of assignment expressions [PR 97981]

[Joseph Myers]

On Sun, 13 Dec 2020, Uecker, Martin wrote:

> Here is a patch to drop qualifiers in assignment expressions.
> 
> -- Martin
> 
> 
> 
> C: Drop qualifiers of assignment expressions. [PR98047]
> 
> ISO C17 6.5.15.1 specifies that the result is the
> type the LHS would have after lvalue conversion.

OK.

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

Re: [PATCH v5] Practical Improvement to libgcc Complex Divide

[Joseph Myers]

On Thu, 10 Dec 2020, Patrick McGehearty via Gcc-patches wrote:

> Thank you for your rapid feedback.
> I'll fix the various formatting issues (spaces in the wrong places
> and such as well as revise the Changelog magic) in the next submission.

I'll await a patch with the formatting issues fixed to save on finding 
duplicate issues in the review.

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

[COMMITTED] gcc: xtensa: rearrange DI mode constant loading

[Max Filippov via Gcc-patches]

From: Takayuki 'January June' Suwa 

2020-12-16  Takayuki 'January June' Suwa  
gcc/
* config/xtensa/xtensa.c (xtensa_emit_move_sequence): Try to
replace 'l32r' with 'movi' + 'slli' when optimizing for size.
* config/xtensa/xtensa.md (movdi): Split loading DI mode constant
into register pair into two loads of SI mode constants.
---
 gcc/config/xtensa/xtensa.c  | 15 +++
 gcc/config/xtensa/xtensa.md | 19 +--
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c
index be1eb21a0b60..1cdc39acfffa 100644
--- a/gcc/config/xtensa/xtensa.c
+++ b/gcc/config/xtensa/xtensa.c
@@ -1082,6 +1082,21 @@ xtensa_emit_move_sequence (rtx *operands, machine_mode 
mode)
 
   if (! TARGET_AUTO_LITPOOLS && ! TARGET_CONST16)
{
+ /* Try to emit MOVI + SLLI sequence, that is smaller
+than L32R + literal.  */
+ if (optimize_size && mode == SImode && register_operand (dst, mode))
+   {
+ HOST_WIDE_INT srcval = INTVAL (src);
+ int shift = ctz_hwi (srcval);
+
+ if (xtensa_simm12b (srcval >> shift))
+   {
+ emit_move_insn (dst, GEN_INT (srcval >> shift));
+ emit_insn (gen_ashlsi3_internal (dst, dst, GEN_INT (shift)));
+ return 1;
+   }
+   }
+
  src = force_const_mem (SImode, src);
  operands[1] = src;
}
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 671c4bea144f..5fbe4ad4af9f 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -727,8 +727,23 @@
(match_operand:DI 1 "general_operand" ""))]
   ""
 {
-  if (CONSTANT_P (operands[1]) && !TARGET_CONST16)
-operands[1] = force_const_mem (DImode, operands[1]);
+  if (CONSTANT_P (operands[1]))
+{
+  /* Split in halves if 64-bit Const-to-Reg moves
+because of offering further optimization opportunities.  */
+  if (register_operand (operands[0], DImode))
+   {
+ rtx first, second;
+
+ split_double (operands[1], , );
+ emit_insn (gen_movsi (gen_lowpart (SImode, operands[0]), first));
+ emit_insn (gen_movsi (gen_highpart (SImode, operands[0]), second));
+ DONE;
+   }
+
+  if (!TARGET_CONST16)
+   operands[1] = force_const_mem (DImode, operands[1]);
+}
 
   if (!register_operand (operands[0], DImode)
   && !register_operand (operands[1], DImode))
-- 
2.20.1

[PATCH] PR fortran/98307 - Dependency check fails when using "allocatable"

[Harald Anlauf via Gcc-patches]

Dear all,

since the introduction of check_forall_dependencies() we mishandled the
dependencies of ALLOCATABLE components of derived types, while POINTER
was dealt with.  Fix that.

Regtested on x86_64-pc-linux-gnu.

OK for master?  Since we generate wrong code under the given circumstances,
what do people think about backports?

Thanks,
Harald


PR fortran/98307 - Dependency check fails when using "allocatable"

The dependency check for FORALL constructs already handled pointer
components to derived types, but missed allocatables.  Fix that.

gcc/fortran/ChangeLog:

PR fortran/98307
* trans-stmt.c (check_forall_dependencies): Extend dependency
check to allocatable components of derived types.

gcc/testsuite/ChangeLog:

PR fortran/98307
* gfortran.dg/forall_19.f90: New test.

diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index adc6b8fefb5..112a4e8ead9 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -3949,9 +3949,10 @@ check_forall_dependencies (gfc_code *c, stmtblock_t *pre, stmtblock_t *post)
  point to the copy instead.  Note that the shallow copy of
  the variable will not suffice for derived types with
  pointer components.  We therefore leave these to their
- own devices.  */
+ own devices.  Likewise for allocatable components.  */
   if (lsym->ts.type == BT_DERIVED
-	&& lsym->ts.u.derived->attr.pointer_comp)
+  && (lsym->ts.u.derived->attr.pointer_comp
+	  || lsym->ts.u.derived->attr.alloc_comp))
 return need_temp;

   new_symtree = NULL;
diff --git a/gcc/testsuite/gfortran.dg/forall_19.f90 b/gcc/testsuite/gfortran.dg/forall_19.f90
new file mode 100644
index 000..ef05c97ab24
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/forall_19.f90
@@ -0,0 +1,32 @@
+! { dg-do run }
+! PR fortran/98307 - Dependency check fails when using "allocatable"
+
+program forall_deps
+  implicit none
+  type t
+logical :: valid = .true.
+integer :: s = 0
+integer, allocatable :: p(:)
+  end type
+  type(t) :: v(2)
+  integer :: i
+
+  allocate (v(1)%p(8))
+  allocate (v(2)%p(8))
+  v(1)%s= 8
+  v(2)%s= 6
+
+  v(1)%p(:) = [1, 2, 3, 4, 5, 6, 7, 8]
+  v(2)%p(:) = [13, 14, 15, 16, 17, 18, 19, 20]
+  forall (i=1:2)
+ v(i)%p(1:v(i)%s) = v(3-i)%p(1:v(i)%s)
+  end forall
+  if (any(v(2)%p(:) /= [1, 2, 3, 4, 5, 6, 19, 20])) stop 1
+
+  v(1)%p(:) = [1, 2, 3, 4, 5, 6, 7, 8]
+  v(2)%p(:) = [13, 14, 15, 16, 17, 18, 19, 20]
+  forall (i=1:2, v(i)%valid)
+ v(i)%p(1:v(i)%s) = v(3-i)%p(1:v(i)%s)
+  end forall
+  if (any(v(2)%p(:) /= [1, 2, 3, 4, 5, 6, 19, 20])) stop 2
+end

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Wed, 16 Dec 2020 at 22:44, abebeos 
wrote:
[...]

> And look at this:
>
> * 200h (estimation) for the patch
>

Not my work, other author(s).

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

+cc: Law, Biener,
On Wed, 16 Dec 2020 at 20:27, Dimitar Dimitrov  wrote:

> On понеделник, 14 декември 2020 г. 20:53:36 EET Dimitar Dimitrov wrote:
> > On петък, 11 декември 2020 г. 19:00:35 EET abebeos wrote:
> > > After "digesting" a bit more your review, I need to thank you for
> opening
> > > my eyes re "cherrypick" suggestion and... the missing g++ summaries. I
> > > need
> > > to update my setup to provide the g++ test-deltas, too. Note that in my
> > > test-setup, more c++ tests pass than in yours, not exactly sure why.
> It's
> > > in the "unresovled testcases".
> >
> > Regarding the additional "unresolved testcases" in my results. I traced
> it
> > to a bug in my setup. I did not prepare $HOME/.dejagnurc properly for
> AVR.
> > I'll rerun the tests and post the results.
> >
> > I'm using stock avr-libc, while I see you are using the avr-libc3 fork.
> > Hopefully the main differences are in HW support, not core libc.
> >
> > Regards,
> > Dimitar
>
> Here are the tests results with my environment fixes. Outcome is the same
> -
> saaadhu has no regressions.
>

Very nice!

@all

This review:

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561757.html

shows that there is still much work to do.

But the patch author seems "away" (and not available anyways), the listed
avr maintainer seems "super-away", main "executing analyst" (me) refuses to
"touch even whitespace".

To my understanding, the non-availability of the avr maintainer should mean
that the "upper-up" maintainers decide.

Commiting means essentially:

=> A low-quality avr-cc0 backend will be replaced with a 0-regressions
low(possibly even lower)-quality avr-mode_cc backend.

If anyone insists to polish things even more in context of a $7K bounty...
start thinking about this:

* Where is the line where bounty-work becomes IT-worker-abuse?
* Do you want people start saying (rightfully) that "gcc bounties are
essentially slave-labour"?
* Enjoying fixed employment?

And look at this:

* 200h (estimation) for the patch
* 200+h for the integration-work (dev-systems, testing etc.) - general
reading not counted.
* 100h (estimation) polishing
* 400h (estimation) for quality enhancement

no way, dishwashing pays better (
https://www.payscale.com/research/US/Job=Dishwasher/Hourly_Rate).

I could, as a follow-up task, "enhance the quality of the avr-mode-cc
backend", nothing special with the code.

But me not sure if it's worth assimilating "gcc's md & related internals"
to the point neccessary to fulfill the task at hand.

I've done my work here.

Note that I'll stop monitoring gcc-patches, but I'm still monitoring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c41


=
> baseline beb9afcaf1466996a301c778596c5df209e7913c
> === gcc Summary ===
>
> # of expected passes105527
> # of unexpected failures584
> # of unexpected successes   16
> # of expected failures  582
> # of untested testcases 2
> # of unresolved testcases   33
> # of unsupported tests  5031
>
> === g++ Summary ===
>
> # of expected passes146432
> # of unexpected failures8012
> # of unexpected successes   21
> # of expected failures  624
> # of untested testcases 10
> # of unresolved testcases   3174
> # of unsupported tests  2
>
>
> =
> pipcet/avr-ccmode
> === gcc Summary ===
>
> # of expected passes105431
> # of unexpected failures709
> # of unexpected successes   16
> # of expected failures  582
> # of untested testcases 2
> # of unresolved testcases   69
> # of unsupported tests  5032
>
> === g++ Summary ===
>
> # of expected passes146229
> # of unexpected failures8291
> # of unexpected successes   21
> # of expected failures  624
> # of untested testcases 10
> # of unresolved testcases   3236
> # of unsupported tests  2
>
> =
> saadhu/avr-cc0
> === gcc Summary ===
>
> # of expected passes105527
> # of unexpected failures584
> # of unexpected successes   16
> # of expected failures  582
> # of untested testcases 2
> # of unresolved testcases   33
> # of unsupported tests  5031
>
> === g++ Summary ===
>
> # of expected passes146432
> # of unexpected failures8012
> # of unexpected successes   21
> # of expected failures  624
> # of untested testcases 10
> # of unresolved testcases   3174
> # of unsupported tests  2
>
> Regards,
> Dimitar
>
>
>

[PATCH][AArch32] MVE: Split refactoring of remaining complex instrinsics

[Tamar Christina via Gcc-patches]

Hi All,

This refactors the complex numbers bits of MVE to go through the same unspecs
as the NEON variant.

This is pre-work to allow code to be shared between NEON and MVE for the complex
vectorization patches.

Bootstrapped Regtested on arm-none-linux-gnueabihf and no issues.
Codegen tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard -mfpu=auto
and no issues.

This is just a splitting of a previously approved patch due to it having a
dependency on the AArch64 bits which have been requested to be reworked.

Will commit under the previous approval.

Thanks,
Tamar

gcc/ChangeLog:

* config/arm/arm_mve.h (__arm_vcmulq_rot90_f16):
(__arm_vcmulq_rot270_f16, _arm_vcmulq_rot180_f16, __arm_vcmulq_f16,
__arm_vcmulq_rot90_f32, __arm_vcmulq_rot270_f32,
__arm_vcmulq_rot180_f32, __arm_vcmulq_f32, __arm_vcmlaq_f16,
__arm_vcmlaq_rot180_f16, __arm_vcmlaq_rot270_f16,
__arm_vcmlaq_rot90_f16, __arm_vcmlaq_f32, __arm_vcmlaq_rot180_f32,
__arm_vcmlaq_rot270_f32, __arm_vcmlaq_rot90_f32): Update builtin calls.
* config/arm/arm_mve_builtins.def (vcmulq_f, vcmulq_rot90_f,
vcmulq_rot180_f, vcmulq_rot270_f, vcmlaq_f, vcmlaq_rot90_f,
vcmlaq_rot180_f, vcmlaq_rot270_f): Removed.
(vcmulq, vcmulq_rot90, vcmulq_rot180, vcmulq_rot270, vcmlaq,
vcmlaq_rot90, vcmlaq_rot180, vcmlaq_rot270): New.
* config/arm/iterators.md (mve_rot): Add UNSPEC_VCMLA, UNSPEC_VCMLA90,
UNSPEC_VCMLA180, UNSPEC_VCMLA270, UNSPEC_VCMUL, UNSPEC_VCMUL90,
UNSPEC_VCMUL180, UNSPEC_VCMUL270.
(VCMUL): New.
* config/arm/mve.md (mve_vcmulq_f,
mve_vcmulq_rot270_f, mve_vcmulq_rot90_f, mve_vcmlaq_f,
mve_vcmlaq_rot180_f, mve_vcmlaq_rot270_f,
mve_vcmlaq_rot90_f): Removed.
(mve_vcmlaq, mve_vcmulq,
mve_vcaddq, cadd3, mve_vcaddq):
New.
* config/arm/unspecs.md (UNSPEC_VCMUL90, UNSPEC_VCMUL270, UNSPEC_VCMUL,
UNSPEC_VCMUL180): New.
(VCMULQ_F, VCMULQ_ROT180_F, VCMULQ_ROT270_F, VCMULQ_ROT90_F,
VCMLAQ_F, VCMLAQ_ROT180_F, VCMLAQ_ROT90_F, VCMLAQ_ROT270_F): Removed.

--- inline copy of patch -- 
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index 
987495dd234ad96ba1163a1f482fe183a46ff437..45014621f2533497e90ddf5257fb04e1fd9325b4
 100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -17348,28 +17348,28 @@ __extension__ extern __inline float16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmulq_rot90_f16 (float16x8_t __a, float16x8_t __b)
 {
-  return __builtin_mve_vcmulq_rot90_fv8hf (__a, __b);
+  return __builtin_mve_vcmulq_rot90v8hf (__a, __b);
 }
 
 __extension__ extern __inline float16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmulq_rot270_f16 (float16x8_t __a, float16x8_t __b)
 {
-  return __builtin_mve_vcmulq_rot270_fv8hf (__a, __b);
+  return __builtin_mve_vcmulq_rot270v8hf (__a, __b);
 }
 
 __extension__ extern __inline float16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmulq_rot180_f16 (float16x8_t __a, float16x8_t __b)
 {
-  return __builtin_mve_vcmulq_rot180_fv8hf (__a, __b);
+  return __builtin_mve_vcmulq_rot180v8hf (__a, __b);
 }
 
 __extension__ extern __inline float16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmulq_f16 (float16x8_t __a, float16x8_t __b)
 {
-  return __builtin_mve_vcmulq_fv8hf (__a, __b);
+  return __builtin_mve_vcmulqv8hf (__a, __b);
 }
 
 __extension__ extern __inline float16x8_t
@@ -17600,28 +17600,28 @@ __extension__ extern __inline float32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmulq_rot90_f32 (float32x4_t __a, float32x4_t __b)
 {
-  return __builtin_mve_vcmulq_rot90_fv4sf (__a, __b);
+  return __builtin_mve_vcmulq_rot90v4sf (__a, __b);
 }
 
 __extension__ extern __inline float32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmulq_rot270_f32 (float32x4_t __a, float32x4_t __b)
 {
-  return __builtin_mve_vcmulq_rot270_fv4sf (__a, __b);
+  return __builtin_mve_vcmulq_rot270v4sf (__a, __b);
 }
 
 __extension__ extern __inline float32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmulq_rot180_f32 (float32x4_t __a, float32x4_t __b)
 {
-  return __builtin_mve_vcmulq_rot180_fv4sf (__a, __b);
+  return __builtin_mve_vcmulq_rot180v4sf (__a, __b);
 }
 
 __extension__ extern __inline float32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmulq_f32 (float32x4_t __a, float32x4_t __b)
 {
-  return __builtin_mve_vcmulq_fv4sf (__a, __b);
+  return __builtin_mve_vcmulqv4sf (__a, __b);
 }
 
 __extension__ extern __inline float32x4_t
@@ -17790,28 +17790,28 @@ __extension__ extern __inline float16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcmlaq_f16 (float16x8_t __a, float16x8_t __b, 

Re: [PATCH] genemit: Handle `const_double_zero' rtx

[Maciej W. Rozycki]

On Wed, 16 Dec 2020, Paul Koning wrote:

> > NB the PDP-11 pieces affected here and tripping this assertion are I 
> > believe dead code, as these insns are only ever produced by splitters and 
> > do not appear to be referred by their names.  
> 
> Right; I gave them names for documentation purposes, after all insns are 
> allowed to have names whether or not the name is referenced or is a 
> required name for RTL generation.

 You can use `*foo' however to have it printed in dumps and be able to 
refer to it otherwise, while not producing callable `gen_foo' entrypoints.  
It is not a feature GCC has always had, but it's been around for a little 
while already.

  Maciej

[PATCH 2/2]Arm: Add NEON and MVE RTL patterns for Complex Addition.

[Tamar Christina via Gcc-patches]

Hi All,

This adds implementation for the optabs for complex additions.  With this the
following C code:

  void f90 (float complex a[restrict N], float complex b[restrict N],
float complex c[restrict N])
  {
for (int i=0; i < N; i++)
  c[i] = a[i] + (b[i] * I);
  }

generates

  f90:
  add r3, r2, #1600
  .L2:
  vld1.32 {q8}, [r0]!
  vld1.32 {q9}, [r1]!
  vcadd.f32   q8, q8, q9, #90
  vst1.32 {q8}, [r2]!
  cmp r3, r2
  bne .L2
  bx  lr


instead of

  f90:
  add r3, r2, #1600
  .L2:
  vld2.32 {d24-d27}, [r0]!
  vld2.32 {d20-d23}, [r1]!
  vsub.f32  q8, q12, q11
  vadd.f32  q9, q13, q10
  vst2.32 {d16-d19}, [r2]!
  cmp r3, r2
  bne .L2
  bx  lr

Bootstrapped Regtested on arm-none-linux-gnueabihf and no issues.
Codegen tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard -mfpu=auto
and no issues.

This is just a splitting of a previously approved patch due to it having a
dependency on the AArch64 bits which have been requested to be reworked.

Will commit under the previous approval.

Thanks,
Tamar

gcc/ChangeLog:

* config/arm/arm_mve.h (__arm_vcaddq_rot90_u8, __arm_vcaddq_rot270_u8,
__arm_vcaddq_rot90_s8, __arm_vcaddq_rot270_s8,
__arm_vcaddq_rot90_u16, __arm_vcaddq_rot270_u16,
__arm_vcaddq_rot90_s16, __arm_vcaddq_rot270_s16,
__arm_vcaddq_rot90_u32, __arm_vcaddq_rot270_u32,
__arm_vcaddq_rot90_s32, __arm_vcaddq_rot270_s32,
__arm_vcaddq_rot90_f16, __arm_vcaddq_rot270_f16,
__arm_vcaddq_rot90_f32, __arm_vcaddq_rot270_f32):  Update builtin calls.
* config/arm/arm_mve_builtins.def (vcaddq_rot90_u, vcaddq_rot270_u,
vcaddq_rot90_s, vcaddq_rot270_s, vcaddq_rot90_f, vcaddq_rot270_f):
Removed.
(vcaddq_rot90, vcaddq_rot270): New.
* config/arm/constraints.md (Dz): Include MVE.
* config/arm/iterators.md (mve_rot): New.
(supf): Remove VCADDQ_ROT270_S, VCADDQ_ROT270_U, VCADDQ_ROT90_S,
VCADDQ_ROT90_U.
(VCADDQ_ROT270, VCADDQ_ROT90): Removed.
* config/arm/mve.md (mve_vcaddq_rot270_, mve_vcaddq_rot270_f,
mve_vcaddq_rot90_f): Removed.
(mve_vcaddq, mve_vcaddq): New.
* config/arm/unspecs.md (VCADDQ_ROT270_S, VCADDQ_ROT90_S,
VCADDQ_ROT270_U, VCADDQ_ROT90_U, VCADDQ_ROT270_F,
VCADDQ_ROT90_F): Removed.
* config/arm/vec-common.md (cadd3): New.

--- inline copy of patch -- 
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index 
6c0d1e2e634a32196eb31079166a7733dcd3a4b6..987495dd234ad96ba1163a1f482fe183a46ff437
 100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -3981,14 +3981,16 @@ __extension__ extern __inline uint8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot90_u8 (uint8x16_t __a, uint8x16_t __b)
 {
-  return __builtin_mve_vcaddq_rot90_uv16qi (__a, __b);
+  return (uint8x16_t)
+__builtin_mve_vcaddq_rot90v16qi ((int8x16_t)__a, (int8x16_t)__b);
 }
 
 __extension__ extern __inline uint8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot270_u8 (uint8x16_t __a, uint8x16_t __b)
 {
-  return __builtin_mve_vcaddq_rot270_uv16qi (__a, __b);
+  return (uint8x16_t)
+__builtin_mve_vcaddq_rot270v16qi ((int8x16_t)__a, (int8x16_t)__b);
 }
 
 __extension__ extern __inline uint8x16_t
@@ -4520,14 +4522,14 @@ __extension__ extern __inline int8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot90_s8 (int8x16_t __a, int8x16_t __b)
 {
-  return __builtin_mve_vcaddq_rot90_sv16qi (__a, __b);
+  return __builtin_mve_vcaddq_rot90v16qi (__a, __b);
 }
 
 __extension__ extern __inline int8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot270_s8 (int8x16_t __a, int8x16_t __b)
 {
-  return __builtin_mve_vcaddq_rot270_sv16qi (__a, __b);
+  return __builtin_mve_vcaddq_rot270v16qi (__a, __b);
 }
 
 __extension__ extern __inline int8x16_t
@@ -4821,14 +4823,16 @@ __extension__ extern __inline uint16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot90_u16 (uint16x8_t __a, uint16x8_t __b)
 {
-  return __builtin_mve_vcaddq_rot90_uv8hi (__a, __b);
+  return (uint16x8_t)
+__builtin_mve_vcaddq_rot90v8hi ((int16x8_t)__a, (int16x8_t)__b);
 }
 
 __extension__ extern __inline uint16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot270_u16 (uint16x8_t __a, uint16x8_t __b)
 {
-  return __builtin_mve_vcaddq_rot270_uv8hi (__a, __b);
+  return (uint16x8_t)
+__builtin_mve_vcaddq_rot270v8hi ((int16x8_t)__a, (int16x8_t)__b);
 }
 
 __extension__ extern __inline uint16x8_t
@@ -5360,14 +5364,14 @@ __extension__ extern __inline int16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, 

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/16/20 2:20 PM, Rainer Orth wrote:

Hi Nikhil,


On 12/15/20 3:00 AM, Nikhil Benesch wrote:

If this patch looks good, I'll submit it upstream tomorrow.


Assuming no news is good news, I sent
https://go-review.googlesource.com/c/gofrontend/+/278672.


sorry for the delay, but unfortunately news is not so good: I get

runtime_sysinfo.go:315:18: error: use of undefined type '_ucontext'
   315 | type _ucontext_t _ucontext
   |  ^


No problem, Rainer. I figured there would be some hiccups. The somewhat good 
news
is that this error appears to be independent of the patch I sent upstream.

I suspect what is happening here is that godump sees "typedef ucontext_t struct
ucontext" and outputs the typedef immediately. Only later does it observe that
"struct ucontext" is invalid. At that point it is too late to comment out the
typedef for _ucontext_t.

Nikhil

c++: Another solaris header use [PR 98315]

[Nathan Sidwell]

Rather than early-include sys/socket.h, let's allow the includer to
tell cody no networking.

libcody/
* cody.hh: Allow user to set CODY_NETWORKING.
gcc/cp/
* mapper-resolver.cc: Remove early include of
sys/socket.h.  Specify no CODY_NETWORKING instead.
* module.cc: Specify no CODY_NETWORKING.

pushing to trunk
--
Nathan Sidwell
diff --git i/gcc/cp/mapper-resolver.cc w/gcc/cp/mapper-resolver.cc
index 8e968c52556..53c482441b4 100644
--- i/gcc/cp/mapper-resolver.cc
+++ w/gcc/cp/mapper-resolver.cc
@@ -21,13 +21,9 @@ along with GCC; see the file COPYING3.  If not see
 /* Forward to the resolver in c++tools.  */
 
 #include "config.h"
-#if defined (__unix__)
-// Solaris11's socket header used bcopy, which we poison.  cody.hh
-// will include it later under the above check
-#include 
-#endif
-
 #define INCLUDE_ALGORITHM
 #include "system.h"
 
+// We don't want or need to be aware of networking
+#define CODY_NETWORKING 0
 #include "../../c++tools/resolver.cc"
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index e9ea18636b4..2318489d9d4 100644
--- i/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -207,7 +207,6 @@ Classes used:
 
 #define _DEFAULT_SOURCE 1 /* To get TZ field of struct tm, if available.  */
 #include "config.h"
-
 #include "system.h"
 #include "coretypes.h"
 #include "cp-tree.h"
@@ -229,6 +228,8 @@ Classes used:
 #include "attribs.h"
 #include "intl.h"
 #include "langhooks.h"
+/* This TU doesn't need or want to see the networking.  */
+#define CODY_NETWORKING 0
 #include "mapper-client.h"
 
 #if HAVE_MMAP_FILE && _POSIX_MAPPED_FILES > 0
diff --git i/libcody/cody.hh w/libcody/cody.hh
index 31d9c182cbe..789ce9e70b7 100644
--- i/libcody/cody.hh
+++ w/libcody/cody.hh
@@ -5,6 +5,9 @@
 #ifndef CODY_HH
 #define CODY_HH 1
 
+// If the user specifies this as non-zero, it must be what we expect,
+// generally only good for requesting no networking
+#if !defined (CODY_NETWORKING)
 // Have a known-good list of networking systems
 #if defined (__unix__) || defined (__MACH__)
 #define CODY_NETWORKING 1
@@ -15,6 +18,7 @@
 #undef CODY_NETWORKING
 #define CODY_NETWORKING 0
 #endif
+#endif
 
 // C++
 #include 

c++: Fix template parm ICE [PR 98297]

[Nathan Sidwell]

I think this is nonsense code, we seem to be naming an instantiation
of a template template parm.  But this fixes the ICE.  Perhaps we
should diagnose the issue earlier?

gcc/cp/
* parser.c (cp_parser_elaborated_type_specifier): Test
BOUND_TEMPLATE_TEMPLATE_PARM before checking for instantiation.
gcc/testsuite/
* g++.dg/template/pr98297.C: New.

pushing to trunk
--
Nathan Sidwell
diff --git c/gcc/cp/parser.c w/gcc/cp/parser.c
index 7ea8c28830e..3883339aa64 100644
--- c/gcc/cp/parser.c
+++ w/gcc/cp/parser.c
@@ -19650,7 +19650,9 @@ cp_parser_elaborated_type_specifier (cp_parser* parser,
   if (TREE_CODE (type) == TYPENAME_TYPE)
 	warning (OPT_Wattributes,
 		 "attributes ignored on uninstantiated type");
-  else if (tag_type != enum_type && CLASSTYPE_TEMPLATE_INSTANTIATION (type)
+  else if (tag_type != enum_type
+	   && TREE_CODE (type) != BOUND_TEMPLATE_TEMPLATE_PARM
+	   && CLASSTYPE_TEMPLATE_INSTANTIATION (type)
 	   && ! processing_explicit_instantiation)
 	warning (OPT_Wattributes,
 		 "attributes ignored on template instantiation");
diff --git c/gcc/testsuite/g++.dg/template/pr98297.C w/gcc/testsuite/g++.dg/template/pr98297.C
new file mode 100644
index 000..0dd63a57b5c
--- /dev/null
+++ w/gcc/testsuite/g++.dg/template/pr98297.C
@@ -0,0 +1,6 @@
+// PR 98297, ICE
+// { dg-do compile { target c++11 } }
+template  class a>
+struct [[b]]
+a ; // { dg-error "does not declare anything" }
+// { dg-warning "ignored" "" { target *-*-* } .-1 }

Re: c++tools: fix install-strip [PR 98328]

[H.J. Lu via Gcc-patches]

On Wed, Dec 16, 2020 at 11:49 AM Nathan Sidwell  wrote:
>
>
> I'd missed an install-strip rule in c++tools.  Here it is, cribbed
> from gcc/ subdir.
>
>  c++tools/

Missing PR other/98328 here.

>  * Makefile.in (INSTALL): Replace with ...
>  (INSTALL_PROGRAM): ... this.
>  (INSTALL_STRIP_PROGRAM): New.
>  (install-strip): New target.
>  (install): Use INSTALL_PROGRAM.
> * configure.ac: Add INSTALL_PROGRAM.
>  * configure: Regenerated.
>
> pushing to trunk
> --
> Nathan Sidwell



-- 
H.J.

c++tools: fix install-strip [PR 98328]

[Nathan Sidwell]

I'd missed an install-strip rule in c++tools.  Here it is, cribbed
from gcc/ subdir.

c++tools/
* Makefile.in (INSTALL): Replace with ...
(INSTALL_PROGRAM): ... this.
(INSTALL_STRIP_PROGRAM): New.
(install-strip): New target.
(install): Use INSTALL_PROGRAM.
* configure.ac: Add INSTALL_PROGRAM.
* configure: Regenerated.

pushing to trunk
--
Nathan Sidwell
diff --git i/c++tools/Makefile.in w/c++tools/Makefile.in
index 4ec1419fa5b..310b5674fec 100644
--- i/c++tools/Makefile.in
+++ w/c++tools/Makefile.in
@@ -22,7 +22,8 @@ libexecdir := @libexecdir@
 target_noncanonical := @target_noncanonical@
 version := $(shell cat $(srcdir)/../gcc/BASE-VER)
 libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(version)
-INSTALL := @INSTALL@
+INSTALL_PROGRAM := @INSTALL_PROGRAM@
+INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s
 AUTOCONF := @AUTOCONF@
 AUTOHEADER := @AUTOHEADER@
 CXX := @CXX@
@@ -47,16 +48,23 @@ maintainer-clean::
 
 install::
 
-check:
-installcheck:
-dvi:
-pdf:
-html:
-info:
-install-info:
-install-pdf:
-install-man:
-install-html:
+check::
+installcheck::
+dvi::
+pdf::
+html::
+info::
+install-info::
+install-pdf::
+install-man::
+install-html::
+
+install-strip: override INSTALL_PROGRAM = $(INSTALL_STRIP_PROGRAM)
+ifneq ($(STRIP),)
+install-strip: STRIPPROG = $(STRIP)
+export STRIPPROG
+endif
+install-strip: install
 
 vpath %.cc $(srcdir)
 vpath %.in $(srcdir)
@@ -90,8 +98,7 @@ all::../gcc/g++-mapper-server$(exeext)
 
 install::
 	$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(libexecsubdir)
-	$(INSTALL) g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir)
-
+	$(INSTALL_PROGRAM) g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir)
 endif
 
 ifneq ($(MAINTAINER),)
diff --git i/c++tools/configure w/c++tools/configure
index 82975120393..e8658aac16e 100755
--- i/c++tools/configure
+++ w/c++tools/configure
@@ -2060,6 +2060,8 @@ test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL}'
 
 test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 
+test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
+
 
 ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
diff --git i/c++tools/configure.ac w/c++tools/configure.ac
index 75773650be7..c5560f68d4d 100644
--- i/c++tools/configure.ac
+++ w/c++tools/configure.ac
@@ -32,6 +32,8 @@ ACX_NONCANONICAL_TARGET
 
 AC_CANONICAL_SYSTEM
 AC_PROG_INSTALL
+test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
+AC_SUBST(INSTALL_PROGRAM)
 
 AC_PROG_CXX
 MISSING=`cd $ac_aux_dir && ${PWDCMD-pwd}`/missing

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Jonathan Wakely via Gcc-patches]

On 16/12/20 17:02 +, Jonathan Wakely wrote:

On 16/12/20 09:23 -0700, Martin Sebor via Libstdc++ wrote:

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)


All recent versions of Intel and Clang support __has_builtin.
(For Intel __has_builtin(__builtin_sprintf) is true, for Clang it's
false. But they both support checking it.)

The #ifdef __has_builtin in  was added more than three years
ago, before GCC supported __has_builtin. So that check was there to
make the code work with GCC, not other compilers.

Now that GCC supports it, I can simplify that.


Like so.

Tested powerpc64-linux, committed to trunk.


commit 4d4f82959aa0802611f1183389c4c74d22431e49
Author: Jonathan Wakely 
Date:   Wed Dec 16 17:18:10 2020

libstdc++: Simplify built-in detection in 

Now that GCC supports __has_builtin there is no need to test whether
it's defined, we can just use it unconditionally.

libstdc++-v3/ChangeLog:

* include/std/utility: Use __has_builtin without checking if
it's defined.

diff --git a/libstdc++-v3/include/std/utility b/libstdc++-v3/include/std/utility
index 4a9ad604cbc..61573f42f3f 100644
--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -297,27 +297,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // extract the elements in a tuple.
   template struct _Index_tuple { };
 
-#ifdef __has_builtin
-# if __has_builtin(__make_integer_seq)
-#  define _GLIBCXX_USE_MAKE_INTEGER_SEQ 1
-# endif
-#endif
-
   // Builds an _Index_tuple<0, 1, 2, ..., _Num-1>.
   template
 struct _Build_index_tuple
 {
-#if _GLIBCXX_USE_MAKE_INTEGER_SEQ
+#if __has_builtin(__make_integer_seq)
   template
 using _IdxTuple = _Index_tuple<_Indices...>;
 
+  // Clang defines __make_integer_seq for this purpose.
   using __type = __make_integer_seq<_IdxTuple, size_t, _Num>;
 #else
+  // For GCC and other compilers, use __integer_pack instead.
   using __type = _Index_tuple<__integer_pack(_Num)...>;
 #endif
 };
 
-#if __cplusplus > 201103L
+#if __cplusplus >= 201402L
 
 #define __cpp_lib_integer_sequence 201304
 
@@ -332,14 +328,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /// Alias template make_integer_sequence
   template
 using make_integer_sequence
-#if _GLIBCXX_USE_MAKE_INTEGER_SEQ
+#if __has_builtin(__make_integer_seq)
   = __make_integer_seq;
 #else
   = integer_sequence<_Tp, __integer_pack(_Num)...>;
 #endif
 
-#undef _GLIBCXX_USE_MAKE_INTEGER_SEQ
-
   /// Alias template index_sequence
   template
 using index_sequence = integer_sequence;

[committed] libstdc++: Warn if __STRICT_ANSI has been undefined

[Jonathan Wakely via Gcc-patches]

Recent changes to use __int128 as an integer-like type in  and
to optimize std::uniform_int_distribution mean that the library relies
on __int128 more heavily than in the past.

The library expects that if __int128 is supported then either
__GLIBCXX_TYPE_INT_N_0 is defined (and we treat is like the standard
integer types), or __STRICT_ANSI__ is defined (and we need to add
special handling for __int128 as a non-standard integer type).

If users compile with -std=c++NN -U__STRICT_ANSI__ then it puts the
library into a broken and inconsistent state, where the compiler doesn't
define the __GLIBCXX_TYPE_INT_N_0 macro, but the library thinks it
doesn't need special handling for __int128. What the user should do is
compile with -std=gnu++NN instead.

This adds a warning if it appears that __int128 is supported but neither
__GLIBCXX_TYPE_INT_N_0 nor __STRICT_ANSI__ is defined.

libstdc++-v3/ChangeLog:

* include/bits/c++config: Warn if __STRICT_ANSI__ state is
inconsistent with __GLIBCXX_TYPE_INT_N_0.

Tested powerpc64-linux. Committed to trunk.

commit 767537a8b027bcb5807bb45b0268c5da98c2c7a0
Author: Jonathan Wakely 
Date:   Wed Dec 16 15:54:50 2020

libstdc++: Warn if __STRICT_ANSI has been undefined

Recent changes to use __int128 as an integer-like type in  and
to optimize std::uniform_int_distribution mean that the library relies
on __int128 more heavily than in the past.

The library expects that if __int128 is supported then either
__GLIBCXX_TYPE_INT_N_0 is defined (and we treat is like the standard
integer types), or __STRICT_ANSI__ is defined (and we need to add
special handling for __int128 as a non-standard integer type).

If users compile with -std=c++NN -U__STRICT_ANSI__ then it puts the
library into a broken and inconsistent state, where the compiler doesn't
define the __GLIBCXX_TYPE_INT_N_0 macro, but the library thinks it
doesn't need special handling for __int128. What the user should do is
compile with -std=gnu++NN instead.

This adds a warning if it appears that __int128 is supported but neither
__GLIBCXX_TYPE_INT_N_0 nor __STRICT_ANSI__ is defined.

libstdc++-v3/ChangeLog:

* include/bits/c++config: Warn if __STRICT_ANSI__ state is
inconsistent with __GLIBCXX_TYPE_INT_N_0.

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 155d0f46b16..cd7678eb16d 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -524,6 +524,15 @@ namespace std
 
 #define _GLIBCXX_USE_ALLOCATOR_NEW
 
+#ifdef __SIZEOF_INT128__
+#if ! defined __GLIBCXX_TYPE_INT_N_0 && ! defined __STRICT_ANSI__
+// If __int128 is supported, we expect __GLIBCXX_TYPE_INT_N_0 to be defined
+// unless the compiler is in strict mode. If it's not defined and the strict
+// macro is not defined, something is wrong.
+#warning "__STRICT_ANSI__ seems to have been undefined; this is not supported"
+#endif
+#endif
+
 #else // !__cplusplus
 # define _GLIBCXX_BEGIN_EXTERN_C
 # define _GLIBCXX_END_EXTERN_C

Re: [PATCH] doc: reflect the publication of C++20 in invoke.texi and standards.texi

[Jonathan Wakely via Gcc-patches]

On 16/12/20 19:36 +0100, Jakub Jelinek wrote:

Hi!

Jonathan mentioned on IRC that ISO/IEC 14882:2020 has been published
yesterday (and indeed it appears on www.iso.org for sale).
I think we should reflect that in our documentation and in cxx-status.html,
patches attached.
I understand we want to keep C++20 support experimental even in GCC 11,
though not sure if we should still talk about "almost certainly change in
incompatible ways" rather than that it might change in incompatible ways.

If the library is feature complete for C++17, we need to adjust the wording
slightly too.


It isn't. I still need to finished reviewing Patrick's std::to_chars
patch.

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Rainer Orth]

Hi Nikhil,

> On 12/15/20 3:00 AM, Nikhil Benesch wrote:
>> If this patch looks good, I'll submit it upstream tomorrow.
>
> Assuming no news is good news, I sent
> https://go-review.googlesource.com/c/gofrontend/+/278672.

sorry for the delay, but unfortunately news is not so good: I get

runtime_sysinfo.go:315:18: error: use of undefined type '_ucontext'
  315 | type _ucontext_t _ucontext
  |  ^
runtime_sysinfo.go:963:22: error: use of undefined type '_nv_alloc_ops'
  963 | type _nv_alloc_ops_t _nv_alloc_ops
  |  ^
runtime_sysinfo.go:945:267: error: use of undefined type '_ns_postinit_s'
  945 | type _netstack struct { netstack_u struct { nu_modules [21+1]*byte; }; 
netstack_m_state [21+1]uint32; netstack_lock _kmutex_t; netstack_next 
*_netstack; netstack_stackid int32; netstack_numzones int32; netstack_refcnt 
int32; netstack_flags int32; netstack_postinit *_ns_postinit_s; }
  | 


  ^

on both sparc and x86.

gen-sysinfo.go has

type _ucontext_t _ucontext
// type _ucontext struct { uc_flags uint32; uc_link *_ucontext_t; uc_sigmask 
_sigset_t; uc_stack _stack_t; uc_mcontext _mcontext_t; uc_xrs _xrs_t; uc_filler 
[2+1]int32; }

type _nv_alloc_ops_t _nv_alloc_ops
// type _nv_alloc_ops struct { nv_ao_init func(*_nv_alloc_t, ___va_list) int32; 
nv_ao_fini func(*_nv_alloc_t); nv_ao_alloc func(*_nv_alloc_t, uint32) *byte; 
nv_ao_free func(*_nv_alloc_t, *byte, uint32); nv_ao_reset func(*_nv_alloc_t); }

type _netstack struct { netstack_u struct { nu_modules [21+1]*byte; }; 
netstack_m_state [21+1]uint32; netstack_lock _kmutex_t; netstack_next 
*_netstack; netstack_stackid int32; netstack_numzones int32; netstack_refcnt 
int32; netstack_flags int32; netstack_postinit *_ns_postinit_s; }
// type _ns_postinit_s struct { ns_pi_fn func_ns_applyfn_t; ns_pi_arg uint32; 
ns_pi_next *_ns_postinit_s; }
// type _ns_postinit_t _ns_postinit_s

Rainer

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

Re: [PATCH] genemit: Handle `const_double_zero' rtx

[Paul Koning via Gcc-patches]

> On Dec 16, 2020, at 6:35 AM, Maciej W. Rozycki  wrote:
> 
> ...
> NB the PDP-11 pieces affected here and tripping this assertion are I 
> believe dead code, as these insns are only ever produced by splitters and 
> do not appear to be referred by their names.  

Right; I gave them names for documentation purposes, after all insns are 
allowed to have names whether or not the name is referenced or is a required 
name for RTL generation.

paul

[PATCH] configure: Extend SHF_GNU_RETAIN conftest to check for unsupported gold

[Jozef Lawrynowicz]

Since "6fbec038f7a Use SHF_GNU_RETAIN to preserve symbol definitions",
GCC could create sections with the 'R' flag, which GAS would map to
SHF_GNU_RETAIN.

SHF_GNU_RETAIN support was not available in gold until Binutils commit
ff4bc37d77, on 2020-12-14. Until the support was added, invalid binaries
could be created if some special sections, such as .init_array, had
SHF_GNU_RETAIN set.

HAVE_GAS_SHF_GNU_RETAIN is now disabled if a version of gold without
SHF_GNU_RETAIN support is detected.

I tested that HAVE_GAS_SHF_GNU_RETAIN was enabled/disabled as
appropriate in a number of configurations, using both in-tree and
out-of-tree Binutils:
- Before the Binutils gold patch:
  * gold disabled == SHF_GNU_RETAIN enabled
  * gold enabled == SHF_GNU_RETAIN disabled
- After the Binutils gold patch:
  * gold disabled == SHF_GNU_RETAIN enabled
  * gold enabled == SHF_GNU_RETAIN enabled 

Successfully bootstrapped for x86_64-pc-linux-gnu.

Ok to apply?
>From af3000bbacc6d8ca57581c11790032b73ea944ac Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Wed, 16 Dec 2020 18:33:54 +
Subject: [PATCH] configure: Extend SHF_GNU_RETAIN conftest to check for
 unsupported gold

Since "6fbec038f7a Use SHF_GNU_RETAIN to preserve symbol definitions",
GCC could create sections with the 'R' flag, which GAS would map to
SHF_GNU_RETAIN.

SHF_GNU_RETAIN support was not available in gold until Binutils commit
ff4bc37d77, on 2020-12-14. Until the support was added, invalid binaries
could be created if some special sections, such as .init_array, had
SHF_GNU_RETAIN set.

HAVE_GAS_SHF_GNU_RETAIN is now disabled if a version of gold without
SHF_GNU_RETAIN support is detected.

gcc/ChangeLog:

PR target/98210
* configure: Regenerate.
* configure.ac (gcc_cv_as_shf_gnu_retain): Disable
HAVE_GAS_SHF_GNU_RETAIN for gold versions that do not support it.
---
 gcc/configure| 60 -
 gcc/configure.ac | 64 +---
 2 files changed, 120 insertions(+), 4 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index 9a27e459f14..544ec92463e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -24442,7 +24442,63 @@ case "${target}" in
 gcc_cv_as_shf_gnu_retain=no
 ;;
   *)
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for section 
'R' flag" >&5
+# gold did not support SHF_GNU_RETAIN until 2.35.50.20201215.
+# Support for SHF_GNU_RETAIN in GCC was only added on 2020-12-01, so rather
+# than only disabling the GCC functionality if gold is the default, disable
+# it if a gold without the support has been built at all.
+
+ld_gold=`which ${gcc_cv_ld}.gold`
+check_gold_ver=no
+if test x$ld_is_gold = xyes; then
+  # Always check_gold_ver when gold is the default linker.
+  check_gold_ver=yes
+  gold_date=$ld_date
+elif test -f ../gold/ld-new$build_exeext; then
+  # Always check_gold_ver when gold has been built in-tree.
+  check_gold_ver=yes
+  gold_ver=`../gold/ld-new$build_exeext --version 2>/dev/null | sed 1q`
+  gold_date=`echo $gold_ver | sed -n 
's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
+elif test -n "$ld_gold"; then
+  gold_ver=`${gcc_cv_ld}.gold --version 2>/dev/null | sed 1q`
+  gold_vers=`echo $gold_ver | sed -n \
+ -e 's,^[^)]*[  ]\([0-9][0-9]*\.[0-9][0-9]*[^)]*\)) .*$,\1,p'`
+  gold_date=`echo $gold_ver | sed -n 
's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
+  gold_vers_major=`expr "$gold_vers" : '\([0-9]*\)'`
+  gold_vers_minor=`expr "$gold_vers" : '[0-9]*\.\([0-9]*\)'`
+  gold_vers_patch=`expr "$gold_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
+
+  # If gold exists but is not the default linker, we assume that it is
+  # still intended to be used if the version matches the default ld.
+  if test 0"$gold_vers_major" -eq 0"$ld_vers_major" \
+ && test 0"$gold_vers_minor" -eq 0"$ld_vers_minor" \
+ && test 0"$gold_vers_patch" -eq 0"$ld_vers_patch" \
+ && test 0"$gold_date" -eq 0"$ld_date"; then
+   check_gold_ver=yes
+  fi
+fi
+
+# To test for the period of time when the SHF_GNU_RETAIN flag is supported
+# in ld, but not in gold, check the date in the version string.  If there
+# is no date, then we let gcc_GAS_CHECK_FEATURE make the correct
+# choice.
+if test $check_gold_ver = yes && test -n "$gold_date" \
+   && test 0"$gold_date" -lt 20201215; then
+  gcc_cv_as_shf_gnu_retain=no
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking gold support for 
SHF_GNU_RETAIN" >&5
+$as_echo_n "checking gold support for SHF_GNU_RETAIN... " >&6; }
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$gcc_cv_as_shf_gnu_retain" >&5
+$as_echo "$gcc_cv_as_shf_gnu_retain" >&6; }
+else
+  # Versions of Binutils with SHF_GNU_RETAIN support do not directly
+  # 

[PATCH] doc: reflect the publication of C++20 in invoke.texi and standards.texi

[Jakub Jelinek via Gcc-patches]

Hi!

Jonathan mentioned on IRC that ISO/IEC 14882:2020 has been published
yesterday (and indeed it appears on www.iso.org for sale).
I think we should reflect that in our documentation and in cxx-status.html,
patches attached.
I understand we want to keep C++20 support experimental even in GCC 11,
though not sure if we should still talk about "almost certainly change in
incompatible ways" rather than that it might change in incompatible ways.

If the library is feature complete for C++17, we need to adjust the wording
slightly too.

2020-12-16  Jakub Jelinek  

* doc/invoke.texi (-std=c++20): Adjust for the publication of
ISO 14882:2020 standard.
* standards.texi: Likewise.

--- gcc/doc/invoke.texi.jj  2020-12-16 13:05:58.996994744 +0100
+++ gcc/doc/invoke.texi 2020-12-16 19:12:07.794336129 +0100
@@ -2418,8 +2418,8 @@ The name @samp{gnu++1z} is deprecated.
 
 @item c++20
 @itemx c++2a
-The next revision of the ISO C++ standard, planned for
-2020.  Support is highly experimental, and will almost certainly
+The 2020 ISO C++ standard plus amendments.
+Support is highly experimental, and will almost certainly
 change in incompatible ways in future releases.
 
 @item gnu++20
--- gcc/doc/standards.texi.jj   2020-07-28 15:39:09.874758070 +0200
+++ gcc/doc/standards.texi  2020-12-16 19:18:28.421078276 +0100
@@ -221,11 +221,18 @@ To select this standard in GCC, use the
 
 The C++ language was further revised in 2017 and ISO/IEC 14882:2017 was
 published.  This is referred to as C++17, and before publication was
-often referred to as C++1z.  GCC supports all the changes in the new
+often referred to as C++1z.  GCC supports all the changes in that
 specification.  For further details see
-@uref{https://gcc.gnu.org/projects/@/cxx-status.html#cxx1z}.  Use the option
+@uref{https://gcc.gnu.org/projects/@/cxx-status.html#cxx17}.  Use the option
 @option{-std=c++17} to select this variant of C++.
 
+Another revised ISO C++ standard was published in 2020 as ISO/IEC
+14882:2020, and is referred to as C++20; before its publication it was
+sometimes referred to as C++2a.  GCC supports most of the changes in the
+new specification.  For further details see
+@uref{https://gcc.gnu.org/projects/@/cxx-status.html@cxx20}.
+To select this standard in GCC, use the option @option{-std=c++20}.
+
 More information about the C++ standards is available on the ISO C++
 committee's web site at @uref{http://www.open-std.org/@/jtc1/@/sc22/@/wg21/}.
 
@@ -243,7 +250,8 @@ select an extended version of the C++ la
 @option{-std=gnu++98} (for C++98 with GNU extensions), or
 @option{-std=gnu++11} (for C++11 with GNU extensions), or
 @option{-std=gnu++14} (for C++14 with GNU extensions), or
-@option{-std=gnu++17} (for C++17 with GNU extensions).  
+@option{-std=gnu++17} (for C++17 with GNU extensions), or
+@option{-std=gnu++20} (for C++20 with GNU extensions).
 
 The default, if
 no C++ language dialect options are given, is @option{-std=gnu++17}.

Jakub
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 403d6740..3d3ed0fe 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -33,8 +33,8 @@
 
   C++20 Support in GCC
 
-  GCC has experimental support for the next revision of the C++
-  standard, which is expected to be published in 2020.
+  GCC has experimental support for the latest revision of the C++
+  standard, which was published in 2020.
 
   C++20 features are available since GCC 8. To enable C++20
   support, add the command-line parameter -std=c++20
@@ -44,9 +44,7 @@
 add -std=gnu++20.
 
   Important: Because the ISO C++20 standard is
-  still evolving, GCC's support is experimental. No attempt
-  will be made to maintain backward compatibility with implementations of
-  C++20 features that do not reflect the final standard.
+  very recent, GCC's support is experimental.
 
   C++20 Language Features
 
@@ -575,7 +573,7 @@
 
   C++17 Support in GCC
 
-  GCC has almost full support for the latest revision of the C++
+  GCC has almost full support for the previous revision of the C++
   standard, which was published in 2017.
   Some library features are missing or incomplete, as described in
   https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017;>the
 library documentation.
@@ -902,8 +900,7 @@
 
   C++14 Support in GCC
 
-  GCC has full support for the previous revision of the C++
-  standard, which was published in 2014.
+  GCC has full support for the of the 2014 C++ standard.
 
   This mode is the default in GCC 6.1 up until GCC 10 (including); it can
   be explicitly selected with the -std=c++14 command-line flag,

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Dimitar Dimitrov]

On понеделник, 14 декември 2020 г. 20:53:36 EET Dimitar Dimitrov wrote:
> On петък, 11 декември 2020 г. 19:00:35 EET abebeos wrote:
> > After "digesting" a bit more your review, I need to thank you for opening
> > my eyes re "cherrypick" suggestion and... the missing g++ summaries. I
> > need
> > to update my setup to provide the g++ test-deltas, too. Note that in my
> > test-setup, more c++ tests pass than in yours, not exactly sure why. It's
> > in the "unresovled testcases".
> 
> Regarding the additional "unresolved testcases" in my results. I traced it
> to a bug in my setup. I did not prepare $HOME/.dejagnurc properly for AVR.
> I'll rerun the tests and post the results.
> 
> I'm using stock avr-libc, while I see you are using the avr-libc3 fork.
> Hopefully the main differences are in HW support, not core libc.
> 
> Regards,
> Dimitar

Here are the tests results with my environment fixes. Outcome is the same - 
saaadhu has no regressions.


=
baseline beb9afcaf1466996a301c778596c5df209e7913c
=== gcc Summary ===

# of expected passes105527
# of unexpected failures584
# of unexpected successes   16
# of expected failures  582
# of untested testcases 2
# of unresolved testcases   33
# of unsupported tests  5031

=== g++ Summary ===

# of expected passes146432
# of unexpected failures8012
# of unexpected successes   21
# of expected failures  624
# of untested testcases 10
# of unresolved testcases   3174
# of unsupported tests  2


=
pipcet/avr-ccmode
=== gcc Summary ===

# of expected passes105431
# of unexpected failures709
# of unexpected successes   16
# of expected failures  582
# of untested testcases 2
# of unresolved testcases   69
# of unsupported tests  5032

=== g++ Summary ===

# of expected passes146229
# of unexpected failures8291
# of unexpected successes   21
# of expected failures  624
# of untested testcases 10
# of unresolved testcases   3236
# of unsupported tests  2

=
saadhu/avr-cc0
=== gcc Summary ===

# of expected passes105527
# of unexpected failures584
# of unexpected successes   16
# of expected failures  582
# of untested testcases 2
# of unresolved testcases   33
# of unsupported tests  5031

=== g++ Summary ===

# of expected passes146432
# of unexpected failures8012
# of unexpected successes   21
# of expected failures  624
# of untested testcases 10
# of unresolved testcases   3174
# of unsupported tests  2

Regards,
Dimitar

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Martin Sebor via Gcc-patches]

On 12/16/20 10:04 AM, Jonathan Wakely wrote:

On 16/12/20 17:02 +, Jonathan Wakely wrote:

On 16/12/20 09:23 -0700, Martin Sebor via Libstdc++ wrote:

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)


All recent versions of Intel and Clang support __has_builtin.
(For Intel __has_builtin(__builtin_sprintf) is true, for Clang it's
false. But they both support checking it.)


I recently discussed this subject with Judy Ward at Intel, and their
preference is for libstdc++ to use __has_builtin, see
6aa12274007bccbae2691a9d336c37fe167bb535 for a recent change to fix
feature detection for Intel.


Looks good, thanks.

Martin

c++: Fix offsetof use [PR 98232]

[Nathan Sidwell]

offsetof is underspecified.  GCC happened to accept an unneeded
explicit scoping, clang does not.

gcc/cp/
* module.cc (dumper::push): Clangify offsetof use.

pushed
--
Nathan Sidwell
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index d2806966e43..e9ea18636b4 100644
--- i/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -4153,7 +4153,7 @@ dumper::push (module_state *m)
   /* Create or extend the dump implementor.  */
   unsigned current = dumps ? dumps->stack.length () : 0;
   unsigned count = current ? current * 2 : EXPERIMENT (1, 20);
-  size_t alloc = (offsetof (impl, impl::stack)
+  size_t alloc = (offsetof (impl, stack)
 		  + impl::stack_t::embedded_size (count));
   dumps = XRESIZEVAR (impl, dumps, alloc);
   dumps->stack.embedded_init (count, current);

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Segher Boessenkool]

On Wed, Dec 16, 2020 at 06:31:35PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 16, 2020 at 11:17:29AM -0600, Segher Boessenkool wrote:
> > It was just a bootstrap+regression check, so no new testcase was needed.
> > I don't remember what target, but powerpc (32+64, BE) probably.
> 
> I'll bootstrap/regtest the patch on powerpc64 and powerpc64le then.

Thanks!

> > > The testcase in the patch (which I've excended today compared to what
> > > the patch had yesterday) has the cases of a single as well as multiple
> > > edges to the ideal prologue bb in the cold partition, yet I can't 
> > > reproduce
> > > the ICE.
> > > As for what changed, I remember fixing PR87475 which is related to
> > > redirection of crossing jumps.
> > 
> > But that is for cfglayout mode?  Shrink-wrap has to do everything in
> > cfgrtl mode unfortunately, because of the partitioning stuff.  Sounds
> > like a good cancidate otherwise.
> 
> The patch affects both modes.  patch_jump_insn would in some cases ICE
> and now it doesn't, instead returns false and 
> rtl_redirect_edge_and_branch_force
> then can deal with it another way.

But that can also ICE then, it's just pushing the problem around, unless
the original test was wrong?

In any case, if you see no problems anymore, I'll just try to stop
worrying :-)


Segher

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 11:17:29AM -0600, Segher Boessenkool wrote:
> It was just a bootstrap+regression check, so no new testcase was needed.
> I don't remember what target, but powerpc (32+64, BE) probably.

I'll bootstrap/regtest the patch on powerpc64 and powerpc64le then.
> 
> > The testcase in the patch (which I've excended today compared to what
> > the patch had yesterday) has the cases of a single as well as multiple
> > edges to the ideal prologue bb in the cold partition, yet I can't reproduce
> > the ICE.
> > As for what changed, I remember fixing PR87475 which is related to
> > redirection of crossing jumps.
> 
> But that is for cfglayout mode?  Shrink-wrap has to do everything in
> cfgrtl mode unfortunately, because of the partitioning stuff.  Sounds
> like a good cancidate otherwise.

The patch affects both modes.  patch_jump_insn would in some cases ICE
and now it doesn't, instead returns false and rtl_redirect_edge_and_branch_force
then can deal with it another way.

Jakub

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Segher Boessenkool]

On Wed, Dec 16, 2020 at 04:36:37PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 16, 2020 at 09:28:56AM -0600, Segher Boessenkool wrote:
> > This used to not work, as mentioned in the original patch submission:
> > https://patchwork.ozlabs.org/project/gcc/patch/52f14532eb742ac8d878a185a46a88da7b0326eb.1442588483.git.seg...@kernel.crashing.org/
> > I wonder what changed?
> 
> There is no testcase in that thread I could find, on which it would ICE.

It was just a bootstrap+regression check, so no new testcase was needed.
I don't remember what target, but powerpc (32+64, BE) probably.

> The testcase in the patch (which I've excended today compared to what
> the patch had yesterday) has the cases of a single as well as multiple
> edges to the ideal prologue bb in the cold partition, yet I can't reproduce
> the ICE.
> As for what changed, I remember fixing PR87475 which is related to
> redirection of crossing jumps.

But that is for cfglayout mode?  Shrink-wrap has to do everything in
cfgrtl mode unfortunately, because of the partitioning stuff.  Sounds
like a good cancidate otherwise.

> > So, the situation is there are multiple incoming edges to where we want
> > to place the prologue.  Because we have to have one single edge to put
> > the prologue on (that is how the infrastructure we have works, it is not
> > anything fundamental), we create a new block that just jumps to the
> > block that needs the prologue, use that new edge for where we place the
> > prologue, and then redirect all edges to the first block to the new
> > block.  (We cannot in all case simply fall through.)
> 
> I believe this case is covered in the testcase.

Yeah...  It is never certaint what it will look like in the generated
machine code, but yup, probably.

In either case, if regstrap now works with this on all targets, this is
great :-)  I just wish I knew what changed.

> > > In the former case, they
> > > are usually conditional jumps that patch_jump_insn can handle just fine,
> > > after all, they were previously crossing and will be crossing after
> > > the redirection too, just to a different label.  And in the powerpc64
> > > case, it is a simple_jump instead that again seems to be handled by
> > > patch_jump_insn just fine.
> > 
> > So what changed in the last five years that makes redirecting
> > EDGE_CROSSING jumps now always work?  Does that also apply to
> > EDGE_COMPLEX, btw?  Knowing this would make at least me a lot less
> > nervous about this patch :-)
> 
> I think EDGE_COMPLEX generally can't be redirected, it is ok to punt on
> those.

Yeah, it is the kitchen sink "do not touch this" flag :-)

Thanks again,


Segher

Re: [PATCH] libgcc: Thumb-1 Floating-Point Library for Cortex M0

[Christophe Lyon via Gcc-patches]

On Wed, 2 Dec 2020 at 04:31, Daniel Engel  wrote:
>
> Hi Christophe,
>
> On Thu, Nov 26, 2020, at 1:14 AM, Christophe Lyon wrote:
> > Hi,
> >
> > On Fri, 13 Nov 2020 at 00:03, Daniel Engel  wrote:
> > >
> > > Hi,
> > >
> > > This patch adds an efficient assembly-language implementation of IEEE-
> > > 754 compliant floating point routines for Cortex M0 EABI (v6m, thumb-
> > > 1).  This is the libgcc portion of a larger library originally
> > > described in 2018:
> > >
> > > https://gcc.gnu.org/legacy-ml/gcc/2018-11/msg00043.html
> > >
> > > Since that time, I've separated the libm functions for submission to
> > > newlib.  The remaining libgcc functions in the attached patch have
> > > the following characteristics:
> > >
> > > Function(s) Size (bytes)Cycles  
> > > Stack   Accuracy
> > > __clzsi242  23  0 
> > >   exact
> > > __clzsi2 (OPTIMIZE_SIZE)22  55  0 
> > >   exact
> > > __clzdi28+__clzsi2  4+__clzsi2  0 
> > >   exact
> > >
> > > __umulsidi3 44  24  0 
> > >   exact
> > > __mulsidi3  30+__umulsidi3  24+__umulsidi3  8 
> > >   exact
> > > __muldi3 (__aeabi_lmul) 10+__umulsidi3  6+__umulsidi3   0 
> > >   exact
> > > __ashldi3 (__aeabi_llsl)22  13  0 
> > >   exact
> > > __lshrdi3 (__aeabi_llsr)22  13  0 
> > >   exact
> > > __ashrdi3 (__aeabi_lasr)22  13  0 
> > >   exact
> > >
> > > __aeabi_lcmp20   13 0 
> > >   exact
> > > __aeabi_ulcmp   16  10  0 
> > >   exact
> > >
> > > __udivsi3 (__aeabi_uidiv)   56  72 – 3850 
> > >   < 1 lsb
> > > __divsi3 (__aeabi_idiv) 38+__udivsi326+__udivsi38 
> > >   < 1 lsb
> > > __udivdi3 (__aeabi_uldiv)   164 103 – 1394  
> > > 16  < 1 lsb
> > > __udivdi3 (OPTIMIZE_SIZE)   142 120 – 1392  
> > > 16  < 1 lsb
> > > __divdi3 (__aeabi_ldiv) 54+__udivdi336+__udivdi3
> > > 32  < 1 lsb
> > >
> > > __shared_float  178
> > > __shared_float (OPTIMIZE_SIZE)  154
> > >
> > > __addsf3 (__aeabi_fadd) 116+__shared_float  31 – 76 8 
> > >   <= 0.5 ulp
> > > __addsf3 (OPTIMIZE_SIZE)112+__shared_float  74  8 
> > >   <= 0.5 ulp
> > > __subsf3 (__aeabi_fsub) 8+__addsf3  6+__addsf3  8 
> > >   <= 0.5 ulp
> > > __aeabi_frsub   8+__addsf3  6+__addsf3  8 
> > >   <= 0.5 ulp
> > > __mulsf3 (__aeabi_fmul) 112+__shared_float  73 – 97 8 
> > >   <= 0.5 ulp
> > > __mulsf3 (OPTIMIZE_SIZE)96+__shared_float   93  8 
> > >   <= 0.5 ulp
> > > __divsf3 (__aeabi_fdiv) 132+__shared_float  83 – 3618 
> > >   <= 0.5 ulp
> > > __divsf3 (OPTIMIZE_SIZE)120+__shared_float  263 – 359   8 
> > >   <= 0.5 ulp
> > >
> > > __cmpsf2/__lesf2/__ltsf272  33  0 
> > >   exact
> > > __eqsf2/__nesf2 4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __gesf2/__gesf2 4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __unordsf2 (__aeabi_fcmpun) 4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmpeq  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmpne  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmplt  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmple  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmpge  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > >
> > > __floatundisf (__aeabi_ul2f)14+__shared_float   40 – 81 8 
> > >   <= 0.5 ulp
> > > __floatundisf (OPTIMIZE_SIZE)   14+__shared_float   40 – 2378 
> > >   <= 0.5 ulp
> > > __floatunsisf (__aeabi_ui2f)0+__floatundisf 1+__floatundisf 8 
> > >   <= 0.5 ulp
> > > __floatdisf (__aeabi_l2f)   14+__floatundisf7+__floatundisf 8 
> > >   <= 0.5 ulp
> > > __floatsisf (__aeabi_i2f)   0+__floatdisf   1+__floatdisf   8 
> > >   <= 0.5 ulp
> > >
> > > __fixsfdi (__aeabi_f2lz)74  27 – 33 0 
> > >   exact
> > > __fixunssfdi (__aeabi_f2ulz)4+__fixsfdi 3+__fixsfdi 0 
> > 

Re: libcody: fix --enable-checking=... [PR 98311]

[Nathan Sidwell]

On 12/16/20 10:40 AM, Jakub Jelinek wrote:

On Wed, Dec 16, 2020 at 09:22:49AM -0500, Nathan Sidwell wrote:

Thanks Jakub for pointing at libcpp.

The -enable-checking configure code in libcody didn't play well with
us.  This just uses libcpp's configurey for that piece.

libcody/
 * configure.ac:Use libcpp's enable-checking code.
 * configure: Rebuilt.

pushing to trunk


This doesn't set is_release anywhere, which means when --enable-checking*
or --disable-checking isn't specified, it always treats it as
--enable-checking=yes, while the normal gcc behavior is treat only trunk
as --enable-checking=yes and treat release branches as
--enable-checking=release by default.

On the other side, nothing uses those ac_assert_checking and
ac_valgrind_checking variables, so it is a waste to compute those.

Is this ok if it passes testing?


yes. hehe, I checked that -enable-checking=set,of,options worked :)


2020-12-16  Jakub Jelinek  

* configure.ac: Compute is_release.
(NMS_ENABLE_CHECKING): Simplify but not computing ac_assert_checking
and ac_valgrind_checking the code doesn't use.
* configure: Regenerated.

--- libcody/configure.ac.jj 2020-12-16 16:14:49.468351790 +0100
+++ libcody/configure.ac2020-12-16 16:23:57.630214135 +0100
@@ -23,6 +23,14 @@ NMS_TOOL_DIRS
  NMS_LINK_OPT([-Wl,--no-undefined])
  NMS_CONFIG_FILES([gdbinit dox.cfg])
  
+# Enable expensive internal checks

+is_release=
+if test -d $srcdir/../gcc \
+   && test -f $srcdir/../gcc/DEV-PHASE \
+   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
+  is_release=yes
+fi
+
  NMS_BUGURL
  dnl NMS_ENABLE_CHECKING
  dnl cloned from ../libcpp/configure.ac
@@ -44,13 +52,8 @@ for check in release $ac_checking_flags
  do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
-   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   # these enable particular checks
-   assert) ac_assert_checking=1 ;;
-   misc) ac_checking=1 ;;
-   valgrind) ac_valgrind_checking=1 ;;
+   yes|all|misc) ac_checking=1 ;;
+   no|none|release) ac_checking= ;;
# accept
*) ;;
esac
--- libcody/configure.jj2020-12-16 16:14:49.459351891 +0100
+++ libcody/configure   2020-12-16 16:29:28.204514512 +0100
@@ -2686,6 +2686,14 @@ configure_args=$ac_configure_args
  
  
  
+# Enable expensive internal checks

+is_release=
+if test -d $srcdir/../gcc \
+   && test -f $srcdir/../gcc/DEV-PHASE \
+   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
+  is_release=yes
+fi
+
  { $as_echo "$as_me:${as_lineno-$LINENO}: checking bugurl" >&5
  $as_echo_n "checking bugurl... " >&6; }
  
@@ -2728,13 +2736,8 @@ for check in release $ac_checking_flags

  do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
-   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   # these enable particular checks
-   assert) ac_assert_checking=1 ;;
-   misc) ac_checking=1 ;;
-   valgrind) ac_valgrind_checking=1 ;;
+   yes|all|misc) ac_checking=1 ;;
+   no|none|release) ac_checking= ;;
# accept
*) ;;
esac


Jakub




--
Nathan Sidwell

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Jonathan Wakely via Gcc-patches]

On 16/12/20 17:02 +, Jonathan Wakely wrote:

On 16/12/20 09:23 -0700, Martin Sebor via Libstdc++ wrote:

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)


All recent versions of Intel and Clang support __has_builtin.
(For Intel __has_builtin(__builtin_sprintf) is true, for Clang it's
false. But they both support checking it.)


I recently discussed this subject with Judy Ward at Intel, and their
preference is for libstdc++ to use __has_builtin, see
6aa12274007bccbae2691a9d336c37fe167bb535 for a recent change to fix
feature detection for Intel.

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Jonathan Wakely via Gcc-patches]

On 16/12/20 09:23 -0700, Martin Sebor via Libstdc++ wrote:

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)


All recent versions of Intel and Clang support __has_builtin.
(For Intel __has_builtin(__builtin_sprintf) is true, for Clang it's
false. But they both support checking it.)

The #ifdef __has_builtin in  was added more than three years
ago, before GCC supported __has_builtin. So that check was there to
make the code work with GCC, not other compilers.

Now that GCC supports it, I can simplify that.

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Martin Sebor via Gcc-patches]

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)

Martin

Re: [PATCH] improve caching and enhance array bounds checking

[Martin Sebor via Gcc-patches]

On 12/15/20 10:29 PM, Jeff Law wrote:



On 11/11/20 6:09 PM, Martin Sebor via Gcc-patches wrote:

The attached patch builds on top of the series I posted last
week(*) to improve the detection of out of bounds pointers
and C++ references, as well as a subset of invalid pointer
relational and subtraction expressions.

First, as I mentioned last week, the simple compute_objsize
cache I implemented then is space inefficient.  The changes
in this update enhance the  cache to reduce the space overhead
and improve compile-time efficiency.  The cache now consists
of two arrays, one storing the indices to the other.
The former is indexed by SSA_NAME version.  The latter also
contains separate entries for sizes of enclosing objects and
their members (missing from the first attempt, leading to
inefficient hacks to overcome the limitation).   These
improvements let clients look up the provenance of any pointer
in O(1) time and avoid the hacks.

Second, with the necessary cache improvements above,
the gimple-array-bounds changes enhance array bounds checking
in two ways:
1) pointers passed to functions or used to initialize C++
references are checked to see if they're valid and in bounds
and diagnosed if not (a subset of instances of passing valid
just-past-past-the-end and so non-dereferenceable pointers to
functions are also diagnosed)
2) relational or difference expressions involving pointers are
checked to make sure they point to the same object and diagnosed
if not.

Besides bootstrapping and regtesting I have also tested the full
patch series with a few packages, including Binutils/GDB, Glibc
and Valgrind, and verified that it doesn't cause any false
positives.  The new -Wpointer-compare warning does trigger in
two or three places in each, for subtracting pointers to distinct
objects.  Those are true positives, but the code I checked looks
benign.  In such cases the warning can be suppressed by converting
the pointers to intptr_t before the subtraction.

Martin

[*] Prerequisite patches:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558127.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557807.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html

gcc-wpointer-compare.diff

Improve detection of invalid pointer operations.

gcc/ChangeLog:

PR middle-end/93848
* builtins.c (compute_objsize_r): Add argument.
(access_ref::parm): New function.
(access_ref::get_ref): Add argument.  Avoid null pointers.  Treat
multiple PHIs with all arguments referencing the same object the same
as references to that object with a range of offsets.  Clear BASE0
for PHIs with arguments referencing distinct objects and different
offsets.
(access_ref::get_ref_type): New function.
(access_ref::size_remaining): Make sure low bound of size is
nonnegative.
(pointer_query::pointer_query): Adjust ctor.
(pointer_query::get_ref): Handle separate index and var caches.
(pointer_query::put_ref): Same.
(pointer_query::flush_cache): New function.
(access_ref::inform_access): Differentiate pointers to allocated
objects from those returned by non-allocation functions.
(get_offset_range): Make extern.
(handle_min_max_size): Add argument.  Pass it to compute_objsize.
(compute_objsize_r, compute_objsize): Same.
(gimple_call_alloc_p): Make extern.
(maybe_emit_free_warning): Adjust and simplify test for built-in
functions.
* builtins.h (struct access_ref): Add new members, adjust existing.
(get_offset_range): Declare.
(gimple_call_alloc_p): Same.
(compute_objsize): Add argument.
* common.opt (-Wpointer-compare): Move option here from gcc/c.opt.
* doc/invoke.texi (-Wpointer-compare): Update.
* gimple-array-bounds.cc (ptrrefs): New variable.
(format_offset_range): New function.
(format_subscript_range): New function.
(array_bounds_checker::check_array_ref): Remove argument.
(array_bounds_checker::check_mem_ref): Remove argument.  Check
no-warning bit on the current statement.  Use format_subscript_range.
Simplify informational messages.
(array_bounds_checker::check_addr_expr): Remove redundant argument
from calls.
(array_bounds_checker::ptrs_to_distinct): New function.
(array_bounds_checker::check_pointer_op): Same.
(array_bounds_checker::handle_assign): Same.
(array_bounds_checker::handle_call): Same.
(array_bounds_checker::check_array_bounds): Set new
array_bounds_checker members.  Adjust calls.
(check_array_bounds_dom_walker::before_dom_children): Call new
array_bounds_checker members.  Set statement visited bit.
(array_bounds_checker::check): Create and a pointer_query instance
and flush its cache.
* gimple-array-bounds.h (class 

Re: libcody: fix --enable-checking=... [PR 98311]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 09:22:49AM -0500, Nathan Sidwell wrote:
> Thanks Jakub for pointing at libcpp.
> 
> The -enable-checking configure code in libcody didn't play well   with
> us.  This just uses libcpp's configurey   for that piece.
> 
>   libcody/
> * configure.ac:   Use libcpp's enable-checking code.
> * configure: Rebuilt.
> 
> pushing to trunk

This doesn't set is_release anywhere, which means when --enable-checking*
or --disable-checking isn't specified, it always treats it as
--enable-checking=yes, while the normal gcc behavior is treat only trunk
as --enable-checking=yes and treat release branches as
--enable-checking=release by default.

On the other side, nothing uses those ac_assert_checking and
ac_valgrind_checking variables, so it is a waste to compute those.

Is this ok if it passes testing?

2020-12-16  Jakub Jelinek  

* configure.ac: Compute is_release.
(NMS_ENABLE_CHECKING): Simplify but not computing ac_assert_checking
and ac_valgrind_checking the code doesn't use.
* configure: Regenerated.

--- libcody/configure.ac.jj 2020-12-16 16:14:49.468351790 +0100
+++ libcody/configure.ac2020-12-16 16:23:57.630214135 +0100
@@ -23,6 +23,14 @@ NMS_TOOL_DIRS
 NMS_LINK_OPT([-Wl,--no-undefined])
 NMS_CONFIG_FILES([gdbinit dox.cfg])
 
+# Enable expensive internal checks
+is_release=
+if test -d $srcdir/../gcc \
+   && test -f $srcdir/../gcc/DEV-PHASE \
+   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
+  is_release=yes
+fi
+
 NMS_BUGURL
 dnl NMS_ENABLE_CHECKING
 dnl cloned from ../libcpp/configure.ac
@@ -44,13 +52,8 @@ for check in release $ac_checking_flags
 do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
-   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   # these enable particular checks
-   assert) ac_assert_checking=1 ;;
-   misc) ac_checking=1 ;;
-   valgrind) ac_valgrind_checking=1 ;;
+   yes|all|misc) ac_checking=1 ;;
+   no|none|release) ac_checking= ;;
# accept
*) ;;
esac
--- libcody/configure.jj2020-12-16 16:14:49.459351891 +0100
+++ libcody/configure   2020-12-16 16:29:28.204514512 +0100
@@ -2686,6 +2686,14 @@ configure_args=$ac_configure_args
 
 
 
+# Enable expensive internal checks
+is_release=
+if test -d $srcdir/../gcc \
+   && test -f $srcdir/../gcc/DEV-PHASE \
+   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
+  is_release=yes
+fi
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking bugurl" >&5
 $as_echo_n "checking bugurl... " >&6; }
 
@@ -2728,13 +2736,8 @@ for check in release $ac_checking_flags
 do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
-   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   # these enable particular checks
-   assert) ac_assert_checking=1 ;;
-   misc) ac_checking=1 ;;
-   valgrind) ac_valgrind_checking=1 ;;
+   yes|all|misc) ac_checking=1 ;;
+   no|none|release) ac_checking= ;;
# accept
*) ;;
esac


Jakub

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 09:28:56AM -0600, Segher Boessenkool wrote:
> This used to not work, as mentioned in the original patch submission:
> https://patchwork.ozlabs.org/project/gcc/patch/52f14532eb742ac8d878a185a46a88da7b0326eb.1442588483.git.seg...@kernel.crashing.org/
> I wonder what changed?

There is no testcase in that thread I could find, on which it would ICE.
The testcase in the patch (which I've excended today compared to what
the patch had yesterday) has the cases of a single as well as multiple
edges to the ideal prologue bb in the cold partition, yet I can't reproduce
the ICE.
As for what changed, I remember fixing PR87475 which is related to
redirection of crossing jumps.

> So, the situation is there are multiple incoming edges to where we want
> to place the prologue.  Because we have to have one single edge to put
> the prologue on (that is how the infrastructure we have works, it is not
> anything fundamental), we create a new block that just jumps to the
> block that needs the prologue, use that new edge for where we place the
> prologue, and then redirect all edges to the first block to the new
> block.  (We cannot in all case simply fall through.)

I believe this case is covered in the testcase.

> > In the former case, they
> > are usually conditional jumps that patch_jump_insn can handle just fine,
> > after all, they were previously crossing and will be crossing after
> > the redirection too, just to a different label.  And in the powerpc64
> > case, it is a simple_jump instead that again seems to be handled by
> > patch_jump_insn just fine.
> 
> So what changed in the last five years that makes redirecting
> EDGE_CROSSING jumps now always work?  Does that also apply to
> EDGE_COMPLEX, btw?  Knowing this would make at least me a lot less
> nervous about this patch :-)

I think EDGE_COMPLEX generally can't be redirected, it is ok to punt on
those.

Jakub

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Segher Boessenkool]

Hi!

On Wed, Dec 16, 2020 at 02:35:32PM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, shrink-wrapping disqualifies for prologue
> placement basic blocks that have EDGE_CROSSING incoming edge.
> I don't see why that is necessary, those edges seem to be redirected
> just fine, both on x86_64 and powerpc64.

This used to not work, as mentioned in the original patch submission:
https://patchwork.ozlabs.org/project/gcc/patch/52f14532eb742ac8d878a185a46a88da7b0326eb.1442588483.git.seg...@kernel.crashing.org/
I wonder what changed?

So, the situation is there are multiple incoming edges to where we want
to place the prologue.  Because we have to have one single edge to put
the prologue on (that is how the infrastructure we have works, it is not
anything fundamental), we create a new block that just jumps to the
block that needs the prologue, use that new edge for where we place the
prologue, and then redirect all edges to the first block to the new
block.  (We cannot in all case simply fall through.)

> In the former case, they
> are usually conditional jumps that patch_jump_insn can handle just fine,
> after all, they were previously crossing and will be crossing after
> the redirection too, just to a different label.  And in the powerpc64
> case, it is a simple_jump instead that again seems to be handled by
> patch_jump_insn just fine.

So what changed in the last five years that makes redirecting
EDGE_CROSSING jumps now always work?  Does that also apply to
EDGE_COMPLEX, btw?  Knowing this would make at least me a lot less
nervous about this patch :-)

> Sure, redirecting an edge that was previously not crossing to be crossing or
> vice versa can fail, but that is not what shrink-wrapping needs.

It used to ICE when not disallowing EDGE_CROSSING.

> Also tested in GCC 8 with this patch and don't see ICEs there either
> (though, of course, I'm not suggesting we should backport this to release
> branches).

The patch looks fine to me of course, modulo that worry.


Segher

Re: Libcody breaks configure

[Nathan Sidwell]

On 12/16/20 3:38 AM, Kewen.Lin via Gcc-patches wrote:

on 2020/12/16 下午2:35, Stott Graham via Gcc-patches wrote:

If any ---checking options used



The related PR PR98311[1] has been filed by David.

BR,
Kewen

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98311


now fixed


--
Nathan Sidwell

[PATCH, OpenMP 5.0] Basic support of release/delete clauses on target/target-data directives

[Chung-Lin Tang]

Hi Jakub,
we have some other sollve_vv tests for OpenMP 5.0, which tests the occurrence of
'delete' map kind on the target directive.

Looking through the specification, as early as 4.5, it seems that there's no
wording that release/delete map kinds are explicitly prohibited on structured 
block
device directives like target and target data (though may not be intuitive if
used in those cases)

According to the description of map clause operation, 'release' seems to be 
essentially
the equivalent of 'alloc' if used this way.

The 'delete' map kind might be of some special use to "deep de-allocate" some
mappings on the way out of a target[data] region. Seems to be sometimes useful, 
I think.

The attached patch is basically just a preliminary patch that lifts the 
rejection of
release/delete map clauses on target/target-data; it no longer rejects those 
kinds,
but has not yet any special handling of 'delete' in 
gomp_map/unmap_vars_internal yet,
making them essentially just the same as 'alloc'. That said, it helps with some 
testcase
compilation that doesn't test all the limitations.
(proper implementation of these clauses inside libgomp will be finished later)

Is this okay for trunk after stage1 reopens?

Thanks,
Chung-Lin

2020-12-16  Chung-Lin Tang  

gcc/c/
* c-parser.c (c_parser_omp_target_data): Allow 'release' and 'delete'
map kinds, update error message string.
(c_parser_omp_target): Likewise.

gcc/cp/
* parser.c (cp_parser_omp_target_data): Allow 'release' and 'delete'
map kinds, update error message string.
(cp_parser_omp_target): Likewise.

libgomp/
* target.c (gomp_map_vars_internal): Add GOMP_MAP_RELEASE and
GOMP_MAP_DELETE cases.
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 69ecdb5e822..970e620b63c 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -19563,26 +19563,28 @@ c_parser_omp_target_data (location_t loc, c_parser 
*parser, bool *if_p)
  case GOMP_MAP_TO:
  case GOMP_MAP_ALWAYS_TO:
  case GOMP_MAP_FROM:
  case GOMP_MAP_ALWAYS_FROM:
  case GOMP_MAP_TOFROM:
  case GOMP_MAP_ALWAYS_TOFROM:
  case GOMP_MAP_ALLOC:
+ case GOMP_MAP_RELEASE:
+ case GOMP_MAP_DELETE:
map_seen = 3;
break;
  case GOMP_MAP_FIRSTPRIVATE_POINTER:
  case GOMP_MAP_ALWAYS_POINTER:
  case GOMP_MAP_ATTACH_DETACH:
break;
  default:
map_seen |= 1;
error_at (OMP_CLAUSE_LOCATION (*pc),
  "%<#pragma omp target data%> with map-type other "
- "than %, %, % or % "
- "on % clause");
+ "than %, %, %, %, "
+ "%, or % on % clause");
*pc = OMP_CLAUSE_CHAIN (*pc);
continue;
  }
   else if (OMP_CLAUSE_CODE (*pc) == OMP_CLAUSE_USE_DEVICE_PTR
   || OMP_CLAUSE_CODE (*pc) == OMP_CLAUSE_USE_DEVICE_ADDR)
map_seen = 3;
   pc = _CLAUSE_CHAIN (*pc);
@@ -20027,23 +20029,25 @@ check_clauses:
  case GOMP_MAP_TO:
  case GOMP_MAP_ALWAYS_TO:
  case GOMP_MAP_FROM:
  case GOMP_MAP_ALWAYS_FROM:
  case GOMP_MAP_TOFROM:
  case GOMP_MAP_ALWAYS_TOFROM:
  case GOMP_MAP_ALLOC:
+ case GOMP_MAP_RELEASE:
+ case GOMP_MAP_DELETE:
  case GOMP_MAP_FIRSTPRIVATE_POINTER:
  case GOMP_MAP_ALWAYS_POINTER:
  case GOMP_MAP_ATTACH_DETACH:
break;
  default:
error_at (OMP_CLAUSE_LOCATION (*pc),
  "%<#pragma omp target%> with map-type other "
- "than %, %, % or % "
- "on % clause");
+ "than %, %, %, %, "
+ "%, or % on % clause");
*pc = OMP_CLAUSE_CHAIN (*pc);
continue;
  }
   pc = _CLAUSE_CHAIN (*pc);
 }
   cfun->has_omp_target = true;
   return true;
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7ea8c28830e..55f3ab3f852 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -41430,27 +41430,29 @@ cp_parser_omp_target_data (cp_parser *parser, 
cp_token *pragma_tok, bool *if_p)
  case GOMP_MAP_TO:
  case GOMP_MAP_ALWAYS_TO:
  case GOMP_MAP_FROM:
  case GOMP_MAP_ALWAYS_FROM:
  case GOMP_MAP_TOFROM:
  case GOMP_MAP_ALWAYS_TOFROM:
  case GOMP_MAP_ALLOC:
+ case GOMP_MAP_RELEASE:
+ case GOMP_MAP_DELETE:
map_seen = 3;
break;
  case GOMP_MAP_FIRSTPRIVATE_POINTER:
  case GOMP_MAP_FIRSTPRIVATE_REFERENCE:
  case GOMP_MAP_ALWAYS_POINTER:
  case GOMP_MAP_ATTACH_DETACH:
break;
  default:
map_seen |= 1;
error_at (OMP_CLAUSE_LOCATION (*pc),
  "%<#pragma omp target data%> with map-type other "
- 

[PATCH, OpenMP 5.0] Allow duplicate mapping of variables

[Chung-Lin Tang]

Hi Jakub,
when running sollve_vv tests (which we're trying to make work out-of-the-box),
some of the 5.0 tests which were testing map clause ordering also required
supporting mapping the same variable multiple times.

This was not allowed before, so besides the small changes needed in the
front-ends, the omp-lowering conventions for field lookup had to be adjusted.
For map clauses, we now use the whole OMP_CLAUSE expression to lookup
fields, instead of the variable DECL, which will clash and ICE when
multiple occurrences happen.

The modifications OpenACC firstprivate variables exist because they seem
to share code with normal map handling in many ways, so they were adjusted
to use the clause-as-key convention too (including the adjustments in
lower_oacc_reductions).

This has been tested for no regressions for gcc, g++, gfortran, and libgomp.
Is this okay for trunk after stage1 reopens?

Thanks,
Chung-Lin

2020-12-16  Chung-Lin Tang  

gcc/c/
* c-typeck.c (c_finish_omp_clauses): Adjust to allow duplicate
mapped variables for OpenMP.

gcc/cp/
* semantics.c (finish_omp_clauses):  Adjust to allow duplicate
mapped variables for OpenMP.

gcc/
* omp-low.c (install_var_field): Add new 'tree key_expr = NULL_TREE'
default parameter. Set splay-tree lookup key to key_expr instead of
var if key_expr is non-NULL.
(scan_sharing_clauses): Use clause tree expression as splay-tree key
for map/to/from and OpenACC firstprivate cases when installing the
variable field into the send/receive record type.
(lower_oacc_reductions): Adjust to find map-clause of reduction
variable, then create receiver-ref.
(lower_omp_target): Adjust to lookup var field using clause expression.

gcc/testsuite/
* c-c++-common/gomp/clauses-2.c: Adjust testcase.
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 7d58e8de342..6bf57ae2ba1 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -14776,12 +14776,12 @@ c_finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
}
  else
bitmap_set_bit (_head, DECL_UID (t));
}
  else if (bitmap_bit_p (_head, DECL_UID (t))
-  && (ort != C_ORT_OMP
-  || !bitmap_bit_p (_field_head, DECL_UID (t
+  && !bitmap_bit_p (_field_head, DECL_UID (t))
+  && ort != C_ORT_OMP)
{
  if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_MAP)
error_at (OMP_CLAUSE_LOCATION (c),
  "%qD appears more than once in motion clauses", t);
  else if (ort == C_ORT_ACC)
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 92e32c8e0ad..4159b770613 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7643,11 +7643,12 @@ finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
}
  else
bitmap_set_bit (_head, DECL_UID (t));
}
  else if (bitmap_bit_p (_head, DECL_UID (t))
-  && !bitmap_bit_p (_field_head, DECL_UID (t)))
+  && !bitmap_bit_p (_field_head, DECL_UID (t))
+  && ort != C_ORT_OMP)
{
  if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_MAP)
error_at (OMP_CLAUSE_LOCATION (c),
  "%qD appears more than once in motion clauses", t);
  else if (ort == C_ORT_ACC)
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 91a5e3d1431..f8109d9752a 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -761,24 +761,31 @@ build_sender_ref (tree var, omp_context *ctx)
 
 /* Add a new field for VAR inside the structure CTX->SENDER_DECL.  If
BASE_POINTERS_RESTRICT, declare the field with restrict.  */
 
 static void
-install_var_field (tree var, bool by_ref, int mask, omp_context *ctx)
+install_var_field (tree var, bool by_ref, int mask, omp_context *ctx,
+  tree key_expr = NULL_TREE)
 {
   tree field, type, sfield = NULL_TREE;
   splay_tree_key key = (splay_tree_key) var;
 
-  if ((mask & 16) != 0)
-{
-  key = (splay_tree_key) _NAME (var);
-  gcc_checking_assert (key != (splay_tree_key) var);
-}
-  if ((mask & 8) != 0)
+  if (key_expr)
+/* Allow user to explicitly set the expression used as the key.  */
+key = (splay_tree_key) key_expr;
+  else
 {
-  key = (splay_tree_key) _UID (var);
-  gcc_checking_assert (key != (splay_tree_key) var);
+  if ((mask & 16) != 0)
+   {
+ key = (splay_tree_key) _NAME (var);
+ gcc_checking_assert (key != (splay_tree_key) var);
+   }
+  if ((mask & 8) != 0)
+   {
+ key = (splay_tree_key) _UID (var);
+ gcc_checking_assert (key != (splay_tree_key) var);
+   }
 }
   gcc_assert ((mask & 1) == 0
  || !splay_tree_lookup (ctx->field_map, key));
   gcc_assert ((mask & 2) == 0 || 

[committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Jonathan Wakely via Gcc-patches]

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.

commit 96d9670e88333d8896a5d2f2bb0403c1e2ad19ab
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:50:34 2020

libstdc++: Only use __builtin_sprintf if supported [PR 96083]

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

diff --git a/libstdc++-v3/include/ext/throw_allocator.h 
b/libstdc++-v3/include/ext/throw_allocator.h
index 0ab174f19a5..2364827a632 100644
--- a/libstdc++-v3/include/ext/throw_allocator.h
+++ b/libstdc++-v3/include/ext/throw_allocator.h
@@ -64,6 +64,10 @@
 #endif
 #include 
 
+#if !__has_builtin(__builtin_sprintf)
+# include 
+#endif
+
 namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -310,6 +314,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 static void
 log_to_string(std::string& s, const_reference ref)
 {
+#if ! __has_builtin(__builtin_sprintf)
+  __typeof__(::sprintf) __builtin_sprintf = ::sprintf;
+#endif
+
   char buf[40];
   const char tab('\t');
   s += "label: ";
@@ -332,6 +340,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 static void
 log_to_string(std::string& s, const std::pair& ref)
 {
+#if ! __has_builtin(__builtin_sprintf)
+  auto __builtin_sprintf = ::sprintf;
+#endif
+
   char buf[40];
   const char tab('\t');
   s += "label: ";
@@ -566,6 +578,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static gen_t generator(engine(), distribution);
 #endif
 
+#if ! __has_builtin(__builtin_sprintf)
+  __typeof__(::sprintf) __builtin_sprintf = ::sprintf;
+#endif
+
   double random = generator();
   if (random < distribution.min() || random > distribution.max())
{

libcody: fix --enable-checking=... [PR 98311]

[Nathan Sidwell]

Thanks Jakub for pointing at libcpp.

The -enable-checking configure code in libcody didn't play well with
us.  This just uses libcpp's configurey for that piece.

libcody/
* configure.ac: Use libcpp's enable-checking code.
* configure: Rebuilt.

pushing to trunk

--
Nathan Sidwell
diff --git i/libcody/configure w/libcody/configure
index 4cc03dcaa3a..76ff932d61b 100755
--- i/libcody/configure
+++ w/libcody/configure
@@ -1285,7 +1285,11 @@ Optional Features:
   --enable-maintainer-mode
   enable maintainer mode. Add rules to rebuild
   configurey bits
-  --enable-checking   enable run-time checking
+  --enable-checking[=LIST]
+  enable expensive run-time checks. With LIST, enable
+  only specific categories of checks. Categories are:
+  yes,no,all,none,release. Flags are: misc,valgrind or
+  other strings
   --enable-exceptions enable exceptions & rtti
 
 Optional Packages:
@@ -2708,30 +2712,45 @@ _ACEOF
 
 # Check whether --enable-checking was given.
 if test "${enable_checking+set}" = set; then :
-  enableval=$enable_checking;
+  enableval=$enable_checking; ac_checking_flags="${enableval}"
 else
-  enable_checking="yes"
+
+# Determine the default checks.
+if test x$is_release = x ; then
+  ac_checking_flags=yes
+else
+  ac_checking_flags=release
+fi
 fi
 
-case $enable_checking in #(
-  yes|all|yes,*) :
-nms_checking=yes ;; #(
-  no|none|release) :
-nms_checking= ;; #(
-  *) :
-as_fn_error $? "unknown check \"$enable_checking\"" "$LINENO" 5 ;;
-esac
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking checking" >&5
-$as_echo_n "checking checking... " >&6; }
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: ${nms_checking:-no}" >&5
-$as_echo "${nms_checking:-no}" >&6; }
-if test "$nms_checking" = yes ; then
+IFS="${IFS= 	}"; ac_save_IFS="$IFS"; IFS="$IFS,"
+for check in release $ac_checking_flags
+do
+	case $check in
+	# these set all the flags to specific states
+	yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+	no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
+	release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+	# these enable particular checks
+	assert) ac_assert_checking=1 ;;
+	misc) ac_checking=1 ;;
+	valgrind) ac_valgrind_checking=1 ;;
+	# accept
+	*) ;;
+	esac
+done
+IFS="$ac_save_IFS"
 
-cat >>confdefs.h <<_ACEOF
-#define NMS_CHECKING 0${nms_checking:+1}
-_ACEOF
+if test x$ac_checking != x ; then
+
+$as_echo "#define NMS_CHECKING 1" >>confdefs.h
+
+else
+  $as_echo "#define NMS_CHECKING 0" >>confdefs.h
 
 fi
+
+
 # Check whether --enable-exceptions was given.
 if test "${enable_exceptions+set}" = set; then :
   enableval=$enable_exceptions;
diff --git i/libcody/configure.ac w/libcody/configure.ac
index 31f041e6679..c3db5534f1f 100644
--- i/libcody/configure.ac
+++ w/libcody/configure.ac
@@ -24,7 +24,47 @@ NMS_LINK_OPT([-Wl,--no-undefined])
 NMS_CONFIG_FILES([gdbinit dox.cfg])
 
 NMS_BUGURL
-NMS_ENABLE_CHECKING
+dnl NMS_ENABLE_CHECKING
+dnl cloned from ../libcpp/configure.ac
+AC_ARG_ENABLE(checking,
+[AS_HELP_STRING([[--enable-checking[=LIST]]],
+		[enable expensive run-time checks.  With LIST,
+		 enable only specific categories of checks.
+		 Categories are: yes,no,all,none,release.
+		 Flags are: misc,valgrind or other strings])],
+[ac_checking_flags="${enableval}"],[
+# Determine the default checks.
+if test x$is_release = x ; then
+  ac_checking_flags=yes
+else
+  ac_checking_flags=release
+fi])
+IFS="${IFS= 	}"; ac_save_IFS="$IFS"; IFS="$IFS,"
+for check in release $ac_checking_flags
+do
+	case $check in
+	# these set all the flags to specific states
+	yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+	no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
+	release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+	# these enable particular checks
+	assert) ac_assert_checking=1 ;;
+	misc) ac_checking=1 ;;
+	valgrind) ac_valgrind_checking=1 ;;
+	# accept
+	*) ;;
+	esac
+done
+IFS="$ac_save_IFS"
+
+if test x$ac_checking != x ; then
+  AC_DEFINE(NMS_CHECKING, 1,
+[Define to 1 if you want more run-time sanity checks.])
+else
+  AC_DEFINE(NMS_CHECKING, 0)
+fi
+
+
 NMS_ENABLE_EXCEPTIONS
 
 AC_CONFIG_HEADERS([config.h])

Re: [PATCH] varasm: Fix up __patchable_function_entries handling

[Jeff Law via Gcc-patches]

On 12/16/20 6:47 AM, Jakub Jelinek wrote:
> On Wed, Dec 16, 2020 at 05:36:04AM -0800, H.J. Lu wrote:
>> gas is correct.
>>
>>> comdat or for retain), then we should do something like the following
>>> untested change, but if it is gas bug, it should be fixed there.
>>>
>>> 2020-12-15  Jakub Jelinek  
>>>
>>> * varasm.c (default_elf_asm_named_section): Always force
>>> section flags even for sections with SECTION_LINK_ORDER flag.
>>>
>> LGTM.  But I can't approve it.
> Bootstrapped/regtested on x86_64-linux and i686-linux successfully.
> Ok for trunk?
Yes.  I probably wasn't clear about that yesterday ;-)

jeff

Re: [PATCH] libcody: Fix build for older GCC versions

[Nathan Sidwell]

On 12/16/20 8:05 AM, Jonathan Wakely wrote:

Before CWG DR 1955 the controlling expression for an #elif must be
syntactically correct, meaning this won't compile with C++11 compilers
such as gcc 4.8:

The solution is to define __has_include(X) as 0 for compilers that don't
support it.

The second problem is that when  is found, it is used
without the std:: qualification.

libcody/ChangeLog:

* internal.hh: Define fallback macros for __has_builtin and
__has_include. Use __has_builtin for __builtin_FILE and
__builtin_LINE. Define alias for std::source_location.

Built on GNu/Linux using both gcc-11 and gcc-4.8, and also by hacking
it so that __builtin_FILE and __builtin_LINE aren't found, and
 gets used.

OK for trunk?


great, thanks!

nathan


--
Nathan Sidwell

Re: libcody: Fix for dash

[Nathan Sidwell]

On 12/16/20 5:02 AM, Richard Sandiford wrote:

Nathan Sidwell  writes:

Apparently 'var+=...' is not a dash thing.  Fixed thusly.

* config.m4: Avoid non-dash idiom
  * configure: Rebuilt.

pushed (2 patches, because I didn't look carefully enough the first time)


Thanks.  I think the other uses of += need the same treatment though:


thanks, I think this gets them all.

There were still some dash-killing uses of +=.  Fixed thusly.

* config.m4: Replace V+="..." with V="$V..."
* configure: Rebuilt.

nathan

--
Nathan Sidwell
diff --git i/libcody/config.m4 w/libcody/config.m4
index 801cfbdb593..ce5e84d0278 100644
--- i/libcody/config.m4
+++ w/libcody/config.m4
@@ -2,6 +2,8 @@
 # Copyright (C) 2020 Nathan Sidwell, nat...@acm.org
 # License: Apache v2.0
 
+# Note: VAR+=... is not dashing, despite its looks
+
 AC_DEFUN([NMS_NOT_IN_SOURCE],
 [if test -e configure ; then
 AC_MSG_ERROR([Do not build in the source tree.  Reasons])
@@ -28,14 +30,13 @@ fi])
 
 AC_DEFUN([NMS_TOOL_DIRS],
 [if test "$tools" && test -d "$tools/include" ; then
-  CXX+=" -I$tools/include"
+  CXX="$CXX -I$tools/include"
 fi
 if test "$tools" && test -d "$tools/lib" ; then
   toollib="$tools/lib"
   if os=$(CXX -print-multi-os-directory 2>/dev/null) ; then
-toollib+="/${os}"
+toollib="$toollib/${os}"
   fi
-  ## VAR+=... is not dashing
   LDFLAGS="$LDFLAGS -L $toollib"
   unset toollib
 fi])
@@ -86,7 +87,7 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 ]])],
 [AC_MSG_RESULT([yes])],
 [CXX_ORIG="$CXX"
-CXX+=" -std=c++11"
+CXX="$CXX -std=c++11"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#if __cplusplus != 201103
 #error "C++11 is required"
@@ -112,7 +113,7 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 #endif
 ]])],
 [AC_MSG_RESULT([yes])],
-[CXX+=" -std=c++20"
+[CXX="$CXX -std=c++20"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#if __cplusplus <= 201703
 #error "C++20 is required"
@@ -248,7 +249,7 @@ if test "${enable_backtrace:-maybe}" != no ; then
 AC_CHECK_HEADERS([demangle.h libiberty/demangle.h],[break])
 # libbfd prevents distribution because of licensing
 AC_CHECK_HEADERS([bfd.h])
-AC_SEARCH_LIBS([bfd_openr],[bfd],[LIBS+="-lz -liberty -ldl"],,[-lz -liberty -ldl])
+AC_SEARCH_LIBS([bfd_openr],[bfd],[LIBS="$LIBS -lz -liberty -ldl"],,[-lz -liberty -ldl])
   fi
   if test "$ac_cv_func_backtrace" = yes ; then
 nms_backtrace=yes
@@ -272,8 +273,8 @@ for generated in config.h.in configure ; do
 done
 for dir in . $SUBDIRS
 do
-  CONFIG_FILES+=" $dir/Makesub"
-  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES+=" $dir/tests/Makesub"
+  CONFIG_FILES="$CONFIG_FILES $dir/Makesub"
+  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES="$CONFIG_FILES $dir/tests/Makesub"
 done
 AC_CONFIG_FILES([$CONFIG_FILES])
 AC_SUBST(configure_args,[$ac_configure_args])
diff --git i/libcody/configure w/libcody/configure
index 1a119c59b9f..4cc03dcaa3a 100755
--- i/libcody/configure
+++ w/libcody/configure
@@ -1824,6 +1824,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 # Copyright (C) 2020 Nathan Sidwell, nat...@acm.org
 # License: Apache v2.0
 
+# Note: VAR+=... is not dashing, despite its looks
+
 
 
 # thanks to Zack Weinberg for fixing this!
@@ -2574,7 +2576,7 @@ if ac_fn_cxx_try_compile "$LINENO"; then :
 $as_echo "yes" >&6; }
 else
   CXX_ORIG="$CXX"
-CXX+=" -std=c++11"
+CXX="$CXX -std=c++11"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
@@ -2625,14 +2627,13 @@ unset CXX_ORIG
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
 if test "$tools" && test -d "$tools/include" ; then
-  CXX+=" -I$tools/include"
+  CXX="$CXX -I$tools/include"
 fi
 if test "$tools" && test -d "$tools/lib" ; then
   toollib="$tools/lib"
   if os=$(CXX -print-multi-os-directory 2>/dev/null) ; then
-toollib+="/${os}"
+toollib="$toollib/${os}"
   fi
-  ## VAR+=... is not dashing
   LDFLAGS="$LDFLAGS -L $toollib"
   unset toollib
 fi
@@ -2671,8 +2672,8 @@ for generated in config.h.in configure ; do
 done
 for dir in . $SUBDIRS
 do
-  CONFIG_FILES+=" $dir/Makesub"
-  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES+=" $dir/tests/Makesub"
+  CONFIG_FILES="$CONFIG_FILES $dir/Makesub"
+  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES="$CONFIG_FILES $dir/tests/Makesub"
 done
 ac_config_files="$ac_config_files $CONFIG_FILES"
 

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/15/20 3:00 AM, Nikhil Benesch wrote:

If this patch looks good, I'll submit it upstream tomorrow.


Assuming no news is good news, I sent
https://go-review.googlesource.com/c/gofrontend/+/278672.

c++: Fix detailed-mem-stat breakage

[Nathan Sidwell]

module.cc has a static initializer that ends up in a circular
dependency when detailed mem stats are enabled.  This removes the need
for that initializer to be dynamic, and we punt to the lazy
initializing we already had inside the object in question anyway.  At
the cost of an additional indirection.

gcc/cp/
* module.cc (loc_spans): Make spans a pointer, not inline.
Adjust all accesses.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index 1b40a72a0d6..d2806966e43 100644
--- i/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -3273,32 +3273,34 @@ public:
   };
 
 private:
-  vec spans;
+  vec *spans;
 
 public:
   loc_spans ()
+/* Do not preallocate spans, as that causes
+   --enable-detailed-mem-stats problems.  */
+: spans (nullptr)
   {
-spans.create (20);
   }
   ~loc_spans ()
   {
-spans.release ();
+delete spans;
   }
 
 public:
   span [] (unsigned ix)
   {
-return spans[ix];
+return (*spans)[ix];
   }
   unsigned length () const
   {
-return spans.length ();
+return spans->length ();
   }
 
 public:
   bool init_p () const
   {
-return spans.length () != 0;
+return spans != nullptr;
   }
   /* Initializer.  */
   void init (const line_maps *lmaps, const line_map_ordinary *map);
@@ -3321,7 +3323,7 @@ public:
 public:
   location_t main_start () const
   {
-return spans[SPAN_MAIN].ordinary.first;
+return (*spans)[SPAN_MAIN].ordinary.first;
   }
 
 public:
@@ -13656,7 +13658,8 @@ void
 loc_spans::init (const line_maps *lmaps, const line_map_ordinary *map)
 {
   gcc_checking_assert (!init_p ());
-  spans.reserve (20);
+  spans = new vec ();
+  spans->reserve (20);
 
   span interval;
   interval.ordinary.first = 0;
@@ -13668,10 +13671,10 @@ loc_spans::init (const line_maps *lmaps, const line_map_ordinary *map)
 = MAP_START_LOCATION (LINEMAPS_ORDINARY_MAP_AT (line_table, 0));
   interval.macro.first = interval.macro.second;
   dump (dumper::LOCATION)
-&& dump ("Fixed span %u ordinary:[%u,%u) macro:[%u,%u)", spans.length (),
+&& dump ("Fixed span %u ordinary:[%u,%u) macro:[%u,%u)", spans->length (),
 	 interval.ordinary.first, interval.ordinary.second,
 	 interval.macro.first, interval.macro.second);
-  spans.quick_push (interval);
+  spans->quick_push (interval);
 
   /* A span for command line & forced headers.  */
   interval.ordinary.first = interval.ordinary.second;
@@ -13682,18 +13685,18 @@ loc_spans::init (const line_maps *lmaps, const line_map_ordinary *map)
   interval.macro.first = LINEMAPS_MACRO_LOWEST_LOCATION (lmaps);
 }
   dump (dumper::LOCATION)
-&& dump ("Pre span %u ordinary:[%u,%u) macro:[%u,%u)", spans.length (),
+&& dump ("Pre span %u ordinary:[%u,%u) macro:[%u,%u)", spans->length (),
 	 interval.ordinary.first, interval.ordinary.second,
 	 interval.macro.first, interval.macro.second);
-  spans.quick_push (interval);
+  spans->quick_push (interval);
   
   /* Start an interval for the main file.  */
   interval.ordinary.first = interval.ordinary.second;
   interval.macro.second = interval.macro.first;
   dump (dumper::LOCATION)
-&& dump ("Main span %u ordinary:[%u,*) macro:[*,%u)", spans.length (),
+&& dump ("Main span %u ordinary:[%u,*) macro:[*,%u)", spans->length (),
 	 interval.ordinary.first, interval.macro.second);
-  spans.quick_push (interval);
+  spans->quick_push (interval);
 }
 
 /* Reopen the span, if we want the about-to-be-inserted set of maps to
@@ -13727,9 +13730,9 @@ loc_spans::open (location_t hwm = UNKNOWN_LOCATION)
   interval.ordinary_delta = interval.macro_delta = 0;
   dump (dumper::LOCATION)
 && dump ("Opening span %u ordinary:[%u,... macro:...,%u)",
-	 spans.length (), interval.ordinary.first,
+	 spans->length (), interval.ordinary.first,
 	 interval.macro.second);
-  spans.safe_push (interval);
+  spans->safe_push (interval);
 }
 
 /* Close out the current linemap interval.  The last maps are within
@@ -13738,7 +13741,7 @@ loc_spans::open (location_t hwm = UNKNOWN_LOCATION)
 void
 loc_spans::close ()
 {
-  span  = spans.last ();
+  span  = spans->last ();
 
   interval.ordinary.second
 = ((line_table->highest_location + (1 << line_table->default_range_bits))
@@ -13746,7 +13749,7 @@ loc_spans::close ()
   interval.macro.first = LINEMAPS_MACRO_LOWEST_LOCATION (line_table);
   dump (dumper::LOCATION)
 && dump ("Closing span %u ordinary:[%u,%u) macro:[%u,%u)",
-	 spans.length () - 1,
+	 spans->length () - 1,
 	 interval.ordinary.first,interval.ordinary.second,
 	 interval.macro.first, interval.macro.second);
 }
@@ -13757,12 +13760,12 @@ loc_spans::close ()
 const loc_spans::span *
 loc_spans::ordinary (location_t loc)
 {
-  unsigned len = spans.length ();
+  unsigned len = spans->length ();
   unsigned pos = 0;
   while (len)
 {
   unsigned half = len / 2;
-  const span  = spans[pos + half];
+  const span  = (*spans)[pos + half];
   if 

Re: [PATCH] varasm: Fix up __patchable_function_entries handling

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 05:36:04AM -0800, H.J. Lu wrote:
> gas is correct.
> 
> > comdat or for retain), then we should do something like the following
> > untested change, but if it is gas bug, it should be fixed there.
> >
> > 2020-12-15  Jakub Jelinek  
> >
> > * varasm.c (default_elf_asm_named_section): Always force
> > section flags even for sections with SECTION_LINK_ORDER flag.
> >

> LGTM.  But I can't approve it.

Bootstrapped/regtested on x86_64-linux and i686-linux successfully.
Ok for trunk?

Jakub

[committed] libstdc++: Fix errors from Library Fundamentals TS headers in C++11 [PR 98319]

[Jonathan Wakely via Gcc-patches]

Currently the ,  and
 headers can be included in C++98 and C++11 modes,
but gives errors. With this change they can be included, but define
nothing.

libstdc++-v3/ChangeLog:

PR libstdc++/98319
* include/experimental/random: Only define contents for C++14
and later.
* include/experimental/source_location: Likewise.
* include/experimental/utility: Likewise.
* testsuite/experimental/feat-lib-fund.cc: Include all LFTS
headers that are present. Allow test to run for all modes.

Tested powerpc64le-linux. Committed to trunk.

commit ab9bd93271061f436c10e35e261ecb73e2108ccc
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:37:17 2020

libstdc++: Fix errors from Library Fundamentals TS headers in C++11 [PR 
98319]

Currently the ,  and
 headers can be included in C++98 and C++11 modes,
but gives errors. With this change they can be included, but define
nothing.

libstdc++-v3/ChangeLog:

PR libstdc++/98319
* include/experimental/random: Only define contents for C++14
and later.
* include/experimental/source_location: Likewise.
* include/experimental/utility: Likewise.
* testsuite/experimental/feat-lib-fund.cc: Include all LFTS
headers that are present. Allow test to run for all modes.

diff --git a/libstdc++-v3/include/experimental/random 
b/libstdc++-v3/include/experimental/random
index 2ec1a4b7e42..4165a8520c8 100644
--- a/libstdc++-v3/include/experimental/random
+++ b/libstdc++-v3/include/experimental/random
@@ -30,6 +30,7 @@
 #ifndef _GLIBCXX_EXPERIMENTAL_RANDOM
 #define _GLIBCXX_EXPERIMENTAL_RANDOM 1
 
+#if __cplusplus >= 201402L
 #include 
 #include 
 
@@ -78,4 +79,5 @@ inline namespace fundamentals_v2 {
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 
-#endif
+#endif // C++14
+#endif // _GLIBCXX_EXPERIMENTAL_RANDOM
diff --git a/libstdc++-v3/include/experimental/source_location 
b/libstdc++-v3/include/experimental/source_location
index 9d5b5eae5f3..b4f00f1c039 100644
--- a/libstdc++-v3/include/experimental/source_location
+++ b/libstdc++-v3/include/experimental/source_location
@@ -30,6 +30,7 @@
 #ifndef _GLIBCXX_EXPERIMENTAL_SRCLOC
 #define _GLIBCXX_EXPERIMENTAL_SRCLOC 1
 
+#if __cplusplus >= 201402L
 #include 
 
 namespace std {
@@ -84,4 +85,5 @@ inline namespace fundamentals_v2 {
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 
-#endif
+#endif // C++14
+#endif // _GLIBCXX_EXPERIMENTAL_SRCLOC
diff --git a/libstdc++-v3/include/experimental/utility 
b/libstdc++-v3/include/experimental/utility
index f0c3b4fcd90..8abf55c0526 100644
--- a/libstdc++-v3/include/experimental/utility
+++ b/libstdc++-v3/include/experimental/utility
@@ -30,6 +30,7 @@
 #ifndef _GLIBCXX_EXPERIMENTAL_UTILITY
 #define _GLIBCXX_EXPERIMENTAL_UTILITY 1
 
+#if __cplusplus >= 201402L
 #include 
 #include 
 #include 
@@ -47,4 +48,5 @@ inline namespace fundamentals_v2 {
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 
-#endif
+#endif // C++14
+#endif // _GLIBCXX_EXPERIMENTAL_UTILITY
diff --git a/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc 
b/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
index b0e6e289009..342edc5352d 100644
--- a/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
+++ b/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
@@ -1,57 +1,36 @@
-// { dg-do preprocess { target c++14 } }
+// { dg-do preprocess }
 
-#if !__has_include()
-#  error ""
+// Include all the LFTS headers. This should work with any -std flag.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if __has_include() // not supported as of GCC 11
+# include 
 #endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-//#if !__has_include()
-//#  error ""
-//#endif
-
-//#if !__has_include()
-//#  error ""
-//#endif
-
-//#if !__has_include()
-//#  error ""
-//#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-//#if !__has_include()
-//#  error ""
-//#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

[committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]

[Jonathan Wakely via Gcc-patches]

This fixes a bug caused by a mismatch between the macros defined by
 when GCC is built and the macros defined by  when
users include . If the user code is compiled with
_XOPEN_SOURCE defined to 500 or 600, Darwin suppresses the
ENOTRECOVERABLE and EOWNERDEAD macros, which are not defined by SUSv3
(aka POSIX.1-2001).

Since POSIX requires the errno macros to be macros (and not variables or
enumerators) we can just test for them directly using the preprocessor.
That means that  will match what is actuallydefined when
it's included, not what was defined when GCC was built. With that change
there is no need for the GLIBCXX_CHECK_SYSTEM_ERROR configure checks and
they can be removed.

libstdc++-v3/ChangeLog:

PR libstdc++/93151
* acinclude.m4 (GLIBCXX_CHECK_SYSTEM_ERROR): Remove.
* configure.ac: Regenerate.
* config/os/generic/error_constants.h: Test POSIX errno macros
directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Likewise.
* testsuite/19_diagnostics/headers/system_error/93151.cc: New
test.

Tested powerpc64le-linux. Committed to trunk.

commit a2c2eec183acf25c9b214fa0827718e4d2fdfc93
Author: Jonathan Wakely 
Date:   Tue Dec 15 20:28:11 2020

libstdc++: Test errno macros directly, not via autoconf [PR 93151]

This fixes a bug caused by a mismatch between the macros defined by
 when GCC is built and the macros defined by  when
users include . If the user code is compiled with
_XOPEN_SOURCE defined to 500 or 600, Darwin suppresses the
ENOTRECOVERABLE and EOWNERDEAD macros, which are not defined by SUSv3
(aka POSIX.1-2001).

Since POSIX requires the errno macros to be macros (and not variables or
enumerators) we can just test for them directly using the preprocessor.
That means that  will match what is actuallydefined when
it's included, not what was defined when GCC was built. With that change
there is no need for the GLIBCXX_CHECK_SYSTEM_ERROR configure checks and
they can be removed.

libstdc++-v3/ChangeLog:

PR libstdc++/93151
* acinclude.m4 (GLIBCXX_CHECK_SYSTEM_ERROR): Remove.
* configure.ac: Regenerate.
* config/os/generic/error_constants.h: Test POSIX errno macros
directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Likewise.
* testsuite/19_diagnostics/headers/system_error/93151.cc: New
test.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index df8be3bf805..e4175ea3e64 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2372,35 +2372,6 @@ AC_DEFUN([GLIBCXX_CHECK_MATH11_PROTO], [
   AC_LANG_RESTORE
 ])
 
-dnl
-dnl Check whether macros, etc are present for 
-dnl
-AC_DEFUN([GLIBCXX_CHECK_SYSTEM_ERROR], [
-
-m4_pushdef([n_syserr], [1])dnl
-m4_foreach([syserr], [EOWNERDEAD, ENOTRECOVERABLE, ENOLINK, EPROTO, ENODATA,
- ENOSR, ENOSTR, ETIME, EBADMSG, ECANCELED,
- EOVERFLOW, ENOTSUP, EIDRM, ETXTBSY,
- ECHILD, ENOSPC, EPERM,
- ETIMEDOUT, EWOULDBLOCK],
-[m4_pushdef([SYSERR], m4_toupper(syserr))dnl
-AC_MSG_CHECKING([for syserr])
-AC_CACHE_VAL([glibcxx_cv_system_error[]n_syserr], [
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]],
-  [int i = syserr;])],
- [glibcxx_cv_system_error[]n_syserr=yes],
- [glibcxx_cv_system_error[]n_syserr=no])
-])
-AC_MSG_RESULT([$glibcxx_cv_system_error[]n_syserr])
-if test x"$glibcxx_cv_system_error[]n_syserr" = x"yes"; then
-  AC_DEFINE([HAVE_]SYSERR, 1, [Define if ]syserr[ exists.])
-fi
-m4_define([n_syserr], m4_incr(n_syserr))dnl
-m4_popdef([SYSERR])dnl
-])
-m4_popdef([n_syserr])dnl
-])
-
 dnl
 dnl Check for what type of C headers to use.
 dnl
diff --git a/libstdc++-v3/config/os/generic/error_constants.h 
b/libstdc++-v3/config/os/generic/error_constants.h
index b5b0ea6b9ad..0d34f7179b6 100644
--- a/libstdc++-v3/config/os/generic/error_constants.h
+++ b/libstdc++-v3/config/os/generic/error_constants.h
@@ -48,7 +48,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   bad_address =EFAULT,
   bad_file_descriptor =EBADF,
 
-#ifdef _GLIBCXX_HAVE_EBADMSG
+#ifdef EBADMSG
   bad_message =EBADMSG,
 #endif
 
@@ -68,7 +68,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   function_not_supported = ENOSYS,
   host_unreachable =   EHOSTUNREACH,
 
-#ifdef _GLIBCXX_HAVE_EIDRM
+#ifdef EIDRM
   identifier_removed = EIDRM,
 #endif
 
@@ -86,13 +86,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   no_buffer_space =ENOBUFS,
   no_child_process =

[committed] libstdc++: Add performance test for atomic_flag [PR 46447]

[Jonathan Wakely via Gcc-patches]

This adds a test to compare the performance of std::atomic_flag with
similar operations on std::atomic_uchar and std::atomic_int.

libstdc++-v3/ChangeLog:

PR libstdc++/46447
* testsuite/performance/29_atomics/atomic_flag.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

commit 3cee0c6562e5d8df69a9d6ad613a6f3edcfcc797
Author: Jonathan Wakely 
Date:   Wed Dec 16 11:51:42 2020

libstdc++: Add performance test for atomic_flag [PR 46447]

This adds a test to compare the performance of std::atomic_flag with
similar operations on std::atomic_uchar and std::atomic_int.

libstdc++-v3/ChangeLog:

PR libstdc++/46447
* testsuite/performance/29_atomics/atomic_flag.cc: New test.

diff --git a/libstdc++-v3/testsuite/performance/29_atomics/atomic_flag.cc 
b/libstdc++-v3/testsuite/performance/29_atomics/atomic_flag.cc
new file mode 100644
index 000..af1a269a0e0
--- /dev/null
+++ b/libstdc++-v3/testsuite/performance/29_atomics/atomic_flag.cc
@@ -0,0 +1,71 @@
+// Copyright (C) 2009-2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+
+#include 
+#include 
+
+volatile std::atomic_flag af;
+volatile std::atomic_uchar ac;
+volatile std::atomic_int ai;
+
+int main()
+{
+  using namespace __gnu_test;
+  time_counter time;
+  resource_counter resource;
+
+  const int n = 1;
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+af.test_and_set();
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_flag::test_and_set()", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+af.clear();
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_flag::clear()", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+ac |= 1;
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_uchar::operator|=(1)", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+ac = 0;
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_flag::operator=(0)", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+ai |= 1;
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_int::operator|=(1)", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+ai = 0;
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_int::operator=(0)", time, resource);
+
+  return 0;
+}

Re: [PATCH] varasm: Fix up __patchable_function_entries handling

[H.J. Lu via Gcc-patches]

On Wed, Dec 16, 2020 at 5:05 AM Jakub Jelinek  wrote:
>
> On Wed, Dec 02, 2020 at 05:15:21AM -0800, H.J. Lu via Gcc-patches wrote:
> > gcc/
> >
> >   PR middle-end/93195
> >   PR middle-end/93197
> >   * configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New.  Define 1 if
> >   the assembler supports the section flag 'o' for specifying
> >   section with link-order.
> >   * output.h (SECTION_LINK_ORDER): New.  Defined to 0x800.
> >   (SECTION_MACH_DEP): Changed from 0x800 to 0x1000.
> >   * targhooks.c (default_print_patchable_function_entry): Pass
> >   SECTION_LINK_ORDER to switch_to_section if the section flag 'o'
> >   works.  Pass current_function_decl to switch_to_section.
> >   * varasm.c (default_elf_asm_named_section): Use 'o' flag for
> >   SECTION_LINK_ORDER if assembler supports it.
> >   * config.in: Regenerated.
> >   * configure: Likewise.
>
> Dunno if it is an assembler bug or gcc bug, but this SECTION_LINK_ORDER
> stuff doesn't seem to work properly.
>
> If I compile:
> static inline __attribute__((__gnu_inline__)) __attribute__((__unused__)) 
> __attribute__((patchable_function_entry(0, 0))) int foo (int x)
> {
>   return x + 1;
> }
>
> static inline __attribute__((__gnu_inline__)) __attribute__((__unused__)) 
> __attribute__((patchable_function_entry(0, 0))) int bar (int x)
> {
>   return x + 2;
> }
>
> int
> baz (int x)
> {
>   return foo (x) + 1;
> }
>
> int
> qux (int x)
> {
>   return bar (x) + 2;
> }
> (distilled from aarch64 Linux kernel) with
> -O2 -fpatchable-function-entry=2 on aarch64 compiler configured against
> latest binutils, I get:
> ...
> .section__patchable_function_entries,"awo",@progbits,baz
> ...
> .section__patchable_function_entries
> ...
> in the assembly, but when it is assembled, one gets:
>   [ 4] __patchable_function_entries PROGBITS 60 
> 08 00 WAL  1   0  8
>   [ 5] .rela__patchable_function_entries RELA 
> 000280 18 18   I 12   4  8
>   [ 6] __patchable_function_entries PROGBITS 68 
> 08 00  0   0  8
>   [ 7] .rela__patchable_function_entries RELA 
> 000298 18 18   I 12   6  8
> i.e. one writable allocated section with SHF_LINK_ORDER and another
> non-allocated non-writable without link order.  In the kernel case there is
> always one entry in the WAL section and then dozens or more in the
> non-allocated one.
> The kernel then fails to link:
> WARNING: modpost: vmlinux.o (__patchable_function_entries): unexpected 
> non-allocatable section.
> Did you forget to use "ax"/"aw" in a .S file?
> Note that for example  contains
> section definitions for use in .S files.
> ld: .init.data has both ordered [`__patchable_function_entries' in 
> init/main.o] and unordered [`.init.data' in 
> ./drivers/firmware/efi/libstub/vsprintf.stub.o] sections
> ld: final link failed: bad value
> make: *** [Makefile:1175: vmlinux] Error 1
>
> If it is correct that the assembler requires full section flags for the
> SECTION_LINK_ORDER .section directives in every case (like it does for

gas is correct.

> comdat or for retain), then we should do something like the following
> untested change, but if it is gas bug, it should be fixed there.
>
> 2020-12-15  Jakub Jelinek  
>
> * varasm.c (default_elf_asm_named_section): Always force
> section flags even for sections with SECTION_LINK_ORDER flag.
>
> --- gcc/varasm.c.jj 2020-12-13 17:07:53.910477664 +0100
> +++ gcc/varasm.c2020-12-15 21:33:35.169314414 +0100
> @@ -6781,10 +6781,10 @@ default_elf_asm_named_section (const cha
>
>/* If we have already declared this section, we can use an
>   abbreviated form to switch back to it -- unless this section is
> - part of a COMDAT groups or with SHF_GNU_RETAIN, in which case GAS
> - requires the full declaration every time.  */
> + part of a COMDAT groups or with SHF_GNU_RETAIN or with SHF_LINK_ORDER,
> + in which case GAS requires the full declaration every time.  */
>if (!(HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
> -  && !(flags & SECTION_RETAIN)
> +  && !(flags & (SECTION_RETAIN | SECTION_LINK_ORDER))
>&& (flags & SECTION_DECLARED))
>  {
>fprintf (asm_out_file, "\t.section\t%s\n", name);
>
>
> Jakub
>

LGTM.  But I can't approve it.

Thanks.

--
H.J.

[PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Jakub Jelinek via Gcc-patches]

Hi!

As mentioned in the PR, shrink-wrapping disqualifies for prologue
placement basic blocks that have EDGE_CROSSING incoming edge.
I don't see why that is necessary, those edges seem to be redirected
just fine, both on x86_64 and powerpc64.  In the former case, they
are usually conditional jumps that patch_jump_insn can handle just fine,
after all, they were previously crossing and will be crossing after
the redirection too, just to a different label.  And in the powerpc64
case, it is a simple_jump instead that again seems to be handled by
patch_jump_insn just fine.
Sure, redirecting an edge that was previously not crossing to be crossing or
vice versa can fail, but that is not what shrink-wrapping needs.
Also tested in GCC 8 with this patch and don't see ICEs there either
(though, of course, I'm not suggesting we should backport this to release
branches).

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

2020-12-16  Jakub Jelinek  

PR rtl-optimization/98289
* shrink-wrap.c (can_get_prologue): Don't punt on EDGE_CROSSING
incoming edges.

* gcc.target/i386/pr98289.c: New test.
* gcc.dg/torture/pr98289.c: New test.

--- gcc/shrink-wrap.c.jj2020-07-28 15:39:09.983756571 +0200
+++ gcc/shrink-wrap.c   2020-12-15 19:15:00.213861334 +0100
@@ -494,7 +494,7 @@ can_get_prologue (basic_block pro, HARD_
   edge e;
   edge_iterator ei;
   FOR_EACH_EDGE (e, ei, pro->preds)
-if (e->flags & (EDGE_COMPLEX | EDGE_CROSSING)
+if (e->flags & EDGE_COMPLEX
&& !dominated_by_p (CDI_DOMINATORS, e->src, pro))
   return false;
 
--- gcc/testsuite/gcc.target/i386/pr98289.c.jj  2020-12-16 13:15:08.579847596 
+0100
+++ gcc/testsuite/gcc.target/i386/pr98289.c 2020-12-16 14:26:16.863157527 
+0100
@@ -0,0 +1,54 @@
+/* PR rtl-optimization/98289 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-require-effective-target freorder } */
+/* { dg-options "-O2 -freorder-blocks-and-partition 
-fdump-rtl-pro_and_epilogue-details" } */
+/* { dg-final { scan-rtl-dump-times "Performing shrink-wrapping" 4 
"pro_and_epilogue" } } */
+
+int bar (void) __attribute__((cold));
+
+void
+foo (int x)
+{
+  if (x)
+__builtin_abort ();
+}
+
+void
+baz (int x)
+{
+  if (__builtin_expect (x, 0))
+{
+  bar ();
+  bar ();
+  bar ();
+}
+}
+
+void
+qux (int x, int y, int z, int w)
+{
+  if (x || y || z || w)
+__builtin_abort ();
+}
+
+int
+corge (int x, int y, int z, int w, int u)
+{
+  if (__builtin_expect (x, 0))
+goto lab;
+  u++;
+  if (__builtin_expect (y, 0))
+goto lab;
+  u *= 2;
+  if (__builtin_expect (z, 0))
+goto lab;
+  u |= 42;
+  if (__builtin_expect (w, 0))
+{
+  lab:;
+  bar ();
+  bar ();
+  if (bar () > 32) goto lab;
+}
+  return u;
+}
--- gcc/testsuite/gcc.dg/torture/pr98289.c.jj   2020-12-16 14:27:01.391659297 
+0100
+++ gcc/testsuite/gcc.dg/torture/pr98289.c  2020-12-16 14:27:29.442345443 
+0100
@@ -0,0 +1,52 @@
+/* PR rtl-optimization/98289 */
+/* { dg-do compile { target freorder } } */
+/* { dg-options "-O2 -freorder-blocks-and-partition" } */
+
+int bar (void) __attribute__((cold));
+
+void
+foo (int x)
+{
+  if (x)
+__builtin_abort ();
+}
+
+void
+baz (int x)
+{
+  if (__builtin_expect (x, 0))
+{
+  bar ();
+  bar ();
+  bar ();
+}
+}
+
+void
+qux (int x, int y, int z, int w)
+{
+  if (x || y || z || w)
+__builtin_abort ();
+}
+
+int
+corge (int x, int y, int z, int w, int u)
+{
+  if (__builtin_expect (x, 0))
+goto lab;
+  u++;
+  if (__builtin_expect (y, 0))
+goto lab;
+  u *= 2;
+  if (__builtin_expect (z, 0))
+goto lab;
+  u |= 42;
+  if (__builtin_expect (w, 0))
+{
+  lab:;
+  bar ();
+  bar ();
+  if (bar () > 32) goto lab;
+}
+  return u;
+}

Jakub

Re: [x86] recompute opt flags after opt level change

[Uros Bizjak via Gcc-patches]

On Wed, Dec 16, 2020 at 2:18 PM Martin Liška  wrote:
>
> On 10/1/19 10:58 AM, Alexandre Oliva wrote:
> > +  if (opts->x_flag_asynchronous_unwind_tables == 2)
> > + opts->x_flag_unwind_tables
> > +   = opts->x_flag_asynchronous_unwind_tables = 1;
>
> Hello.
>
> Spotted that when I tried to make x_flag_asynchronous_unwind_tables a boolean 
> flag.
>
> Anyway the code seems fishy, shouldn't it be:
>
>if (opts->x_flag_asynchronous_unwind_tables == 2)
> opts->x_flag_unwind_tables
>   = opts->x_flag_asynchronous_unwind_tables == 1; < '==' instead 
> of '='

It should be OK. Please note that

opts->x_flag_asynchronous_unwind_tables == 1

will never be true due to preceding condition.

Uros.
>
> Thanks,
> Martin

Re: [PATCH] genemit: Handle `const_double_zero' rtx

[Maciej W. Rozycki]

On Wed, 16 Dec 2020, Richard Sandiford wrote:

> >> Presumably you can't use CONST0_RTX (mode) here?  Assuming that's the
> >> case, then this is fine.
> >
> >  Well, `mode' is VOID for simplicity and to match what the middle end 
> > presents as an operand to the COMPARE operation, as also shown with the 
> > diff above, so with CONST0_RTX (mode) we'd be back to what amounts to 
> > `const0_rtx' aka `const_int 0', which is exactly what we want to get away 
> > from.
> >
> >  Alternatively we could possibly give `const_double_zero' a proper FP 
> > mode, but it seems to me like an unnecessary complication, as it would 
> > then have to be individually requested and iterated over all the relevant 
> > modes.
> 
> Generated FP const_double rtxes have to have a proper (non-VOID) mode
> though.  VOIDmode CONST_DOUBLEs are always (legacy) integers instead
> of FP values.
> 
> So yeah, giving const_double_zero a proper mode seems like the way to go.
> It's technically possible to drop it in a pure matching context, but I'm
> not sure how valuable that is in practice, given that other parts of the
> matched pattern would usually need to refer to the same mode anyway.

 Fair enough.  For some reason however VOIDmode CONST_DOUBLEs seem to work 
with the FP operations in the VAX backend for the purpose of post-reload 
comparison elimination while CONST_INTs do not.

> >  Have I missed anything here?
> >
> >  NB the PDP-11 pieces affected here and tripping this assertion are I 
> > believe dead code, as these insns are only ever produced by splitters and 
> > do not appear to be referred by their names.  We need this change however 
> > for completeness so that `const_double_zero' can be used in contexts where 
> > an insn actually will be referred by its name.
> >
> >  However the PDP-11 code being dead makes it a bit more difficult to 
> > examine actual consequences of such a change like I have proposed than it 
> > would otherwise be.  In these circumstances I think my proposal is safe if 
> > a bit overly cautious.
> 
> CONST_DOUBLE_ATOF ("0", VOIDmode) seems malformed though, and I'd expect
> it to assert in REAL_MODE_FORMAT (via the format_helper constructor).
> I'm not sure the patch is strictly safer than the status quo.

 I may have missed that, though I did follow the chain of calls involved 
here to see if there is anything problematic.  As I say I have a limited 
way to verify this in practice as the PDP-11 code involved appears to me 
to be dead, and the situation does not apply to the VAX backend.  Maybe I 
could simulate it somehow artificially to see what happens.

> FWIW, I agree with Jeff that this ought to be CONST0_RTX (mode).

 I'll have to update several places then and push the changes through full 
regression testing, so it'll probably take until the next week.

 Thanks for your input!

  Maciej

[PATCH] doc: Document that libstdc++ uses __STRICT_ANSI__

[Jonathan Wakely via Gcc-patches]

Libstdc++ has been using __STRICT_ANSI__ for years, e.g. to decide
whether or not std::is_integral<__int128> should be true.

gcc/ChangeLog:

* doc/cpp.texi (Common Predefined Macros): Mention that
__STRICT_ANSI__ is used by libstdc++ too.

OK for trunk?

I'd also like to tell users they're not allowed to undefine the
macro, would that be acceptable, or is that supposed to work?

I don't see how it's possible to make it work with libstdc++ if users
do stupid things like:

#include 
#undef __STRICT_ANSI__
#include 

This causes the library to be in an inconsistent (broken) state,
because some templates are defined according to strict ISO C++ rules
and then other templates are not, but assume the earlier definitions
are consistent.

We frequently see users doing -std=c++11 -U__STRICT_ANSI__ which makes
me smash my head on the table. Just use -std=gnu++11 and stop being
dumb.


commit c516abe37ef82444e125b32933ea44a00a99d1ec
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:21:24 2020

doc: Document that libstdc++ uses __STRICT_ANSI__

Libstdc++ has been using __STRICT_ANSI__ for years, e.g. to decide
whether or not std::is_integral<__int128> should be true.

gcc/ChangeLog:

* doc/cpp.texi (Common Predefined Macros): Mention that
__STRICT_ANSI__ is used by libstdc++ too.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 5dcd67259e3..c5cdd5cb069 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -1996,8 +1996,8 @@ testing @code{@w{(__GNUC__ && __cplusplus)}}.
 GCC defines this macro if and only if the @option{-ansi} switch, or a
 @option{-std} switch specifying strict conformance to some version of ISO C
 or ISO C++, was specified when GCC was invoked.  It is defined to @samp{1}.
-This macro exists primarily to direct GNU libc's header files to use only
-definitions found in standard C.
+This macro exists primarily to direct libstdc++ and GNU libc's header files
+to use only definitions found in standard C and C++.
 
 @item __BASE_FILE__
 This macro expands to the name of the main input file, in the form

Re: [Ada] Fix serial port baud rate setting on GNU/Linux

[Rainer Orth]

Hi Pierre-Marie,

> On Wed, Dec 16, 2020 at 1:18 PM Pierre-Marie de Rodat
>  wrote:
>> Thank you. I can reproduce the issue: at this point I suspect that my
>> testing hasn’t detected this because of some inconsistency with my
>> incremental builds. The actual correction is a few patches later in my
>> porting queue: I’m about to commit it. Sorry for the trouble!
>
> The fix is now in master
> (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cbe22e189a355f19eb1344fcaf91bc2bb0b95f36),
> so the bootstrap for Ada should now be fixed. I’ll update the PR:
> should I wait for confirmation before moving it to RESOLVED?

The ICANON part matches almost exactly what I used to restore
Linux/x86_64 bootstrap.  I'd suggest you close the PR: in case there are
unexpected problems, it can always be reopened.

Thanks.
Rainer

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

Re: [Ada] Fix serial port baud rate setting on GNU/Linux

[Pierre-Marie de Rodat]

On Wed, Dec 16, 2020 at 1:18 PM Pierre-Marie de Rodat
 wrote:
> Thank you. I can reproduce the issue: at this point I suspect that my
> testing hasn’t detected this because of some inconsistency with my
> incremental builds. The actual correction is a few patches later in my
> porting queue: I’m about to commit it. Sorry for the trouble!

The fix is now in master
(https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cbe22e189a355f19eb1344fcaf91bc2bb0b95f36),
so the bootstrap for Ada should now be fixed. I’ll update the PR:
should I wait for confirmation before moving it to RESOLVED?

-- 
Pierre-Marie de Rodat 

c++tools: Fix (an) install issue

[Nathan Sidwell]

David reported an AIX problem, which I think this addresses.  I've not 
looked at pr98314 yet but there's certainly overlap


This fixes installers that don't understand -p.

c++tools/
(install): Do not use -p, use mkinstalldirs.
(clean): Fix typo.

pushing to trunk
--
Nathan Sidwell
diff --git i/c++tools/Makefile.in w/c++tools/Makefile.in
index 49b7fae1526..4ec1419fa5b 100644
--- i/c++tools/Makefile.in
+++ w/c++tools/Makefile.in
@@ -38,7 +38,7 @@ mostlyclean::
 	rm -f $(MAPPER.O)
 
 clean::
-	rm -f c++-mapper-server$(exeext)
+	rm -f g++-mapper-server$(exeext)
 
 distclean::
 	rm -f config.log config.status config.h
@@ -86,10 +86,11 @@ g++-mapper-server$(exeext): $(MAPPER.O) $(CODYLIB)
 all::../gcc/g++-mapper-server$(exeext)
 
 ../gcc/g++-mapper-server$(exeext): g++-mapper-server$(exeext)
-	$(INSTALL) -p $< $@
+	$(INSTALL) $< $@
 
 install::
-	$(INSTALL) -p g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir)
+	$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(libexecsubdir)
+	$(INSTALL) g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir)
 
 endif
 

Re: [x86] recompute opt flags after opt level change

[Martin Liška]

On 10/1/19 10:58 AM, Alexandre Oliva wrote:

+  if (opts->x_flag_asynchronous_unwind_tables == 2)
+   opts->x_flag_unwind_tables
+ = opts->x_flag_asynchronous_unwind_tables = 1;


Hello.

Spotted that when I tried to make x_flag_asynchronous_unwind_tables a boolean 
flag.

Anyway the code seems fishy, shouldn't it be:

  if (opts->x_flag_asynchronous_unwind_tables == 2)
opts->x_flag_unwind_tables
  = opts->x_flag_asynchronous_unwind_tables == 1; < '==' instead of 
'='

Thanks,
Martin

[Ada] armhf-linux: symbolic tracebacks

[Pierre-Marie de Rodat]

Implement symbolic tracebacks on armhf-linux.  It's an ELF target so
just a matter of some bookkeeping changes.

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

gcc/ada/

* libgnat/s-objrea.ads (Object_Arch): Add ARM enum
* libgnat/s-objrea.adb (Initialize): Add EM_ARM case.
(Read_Address): Add ARM case to 32bit read.
* Makefile.rtl: Add trasym units to the runtime for armhf-linux.diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
--- a/gcc/ada/Makefile.rtl
+++ b/gcc/ada/Makefile.rtl
@@ -2381,12 +2381,14 @@ ifeq ($(strip $(filter-out arm% linux-gnueabi%,$(target_cpu) $(target_os))),)
   s-tasinf.adb
Res.Arch := x86_64;
 
+when EM_ARM =>
+   Res.Arch := ARM;
+
 when others =>
raise Format_Error with "unrecognized architecture";
  end case;
@@ -2030,6 +2033,7 @@ package body System.Object_Reader is
 | MIPS
 | PPC
 | SPARC
+| ARM
  =>
 Address_32 := Read (S);
 return uint64 (Address_32);


diff --git a/gcc/ada/libgnat/s-objrea.ads b/gcc/ada/libgnat/s-objrea.ads
--- a/gcc/ada/libgnat/s-objrea.ads
+++ b/gcc/ada/libgnat/s-objrea.ads
@@ -117,9 +117,12 @@ package System.Object_Reader is
   PPC,
   --  32-bit PowerPC
 
-  PPC64);
+  PPC64,
   --  64-bit PowerPC
 
+  ARM);
+  --  32-bit ARM
+
--
-- Target types --
--

[Ada] Handle iterator filters on loop specifications over containers

[Pierre-Marie de Rodat]

A loop parameter specification over a container is rewrtten as an
iterator specification, so that expansion can use the Iterator
opwrations declared for the container type. If an Ada2020 interator
filter appears on the loop_parameter_specification it must be transfered
to the iterator, and preanalyzed for semantic correctness. Expansion of
the filter must be deferred to expansion of the enclosing loop, to
prevent premature references to the loop parameter outside of its scope.

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

gcc/ada/

* sem_ch5.adb (Analyze_Iterator_Specification): If iterator
filter is present, preanalyze filter without expansion.
(Analyze_Loop_Parameter_Specification): When
loop_Parameter_Specification is rewritten as
Iterator_Specification, transfer Iterator_Filter if present.diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -2620,7 +2620,10 @@ package body Sem_Ch5 is
   end if;
 
   if Present (Iterator_Filter (N)) then
- Analyze_And_Resolve (Iterator_Filter (N), Standard_Boolean);
+ --  Preanalyze the filter. Expansion will take place when enclosing
+ --  loop is expanded.
+
+ Preanalyze_And_Resolve (Iterator_Filter (N), Standard_Boolean);
   end if;
end Analyze_Iterator_Specification;
 
@@ -3017,6 +3020,9 @@ package body Sem_Ch5 is
 begin
Set_Iterator_Specification (Scheme, I_Spec);
Set_Loop_Parameter_Specification (Scheme, Empty);
+   Set_Iterator_Filter (I_Spec,
+ Relocate_Node (Iterator_Filter (N)));
+
Analyze_Iterator_Specification (I_Spec);
 
--  In a generic context, analyze the original domain of

[Ada] Add contracts to Ada.Strings.Fixed

[Pierre-Marie de Rodat]

This adds complete postconditions and contract cases to subprograms in
Ada.Strings.Fixed.

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

gcc/ada/

* libgnat/a-strfix.ads: Add postconditions and contract cases to
subprograms.

patch.diff.gz
Description: application/gzip

[Ada] Code cleanup: rename ALI.Scope

[Pierre-Marie de Rodat]

Rename it to IS_Scope so that calling scope (node) under gdb is
unambiguous, so ease debugging sessions.

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

gcc/ada/

* ali.ads, ali.adb, bindo-writers.adb, lib-writ.adb (Scope):
Renamed to IS_Scope.diff --git a/gcc/ada/ali.adb b/gcc/ada/ali.adb
--- a/gcc/ada/ali.adb
+++ b/gcc/ada/ali.adb
@@ -3814,15 +3814,15 @@ package body ALI is
  return No_ALI_Id;
end Scan_ALI;
 
-   ---
-   -- Scope --
-   ---
+   --
+   -- IS_Scope --
+   --
 
-   function Scope (IS_Id : Invocation_Signature_Id) return Name_Id is
+   function IS_Scope (IS_Id : Invocation_Signature_Id) return Name_Id is
begin
   pragma Assert (Present (IS_Id));
   return Invocation_Signatures.Table (IS_Id).Scope;
-   end Scope;
+   end IS_Scope;
 
-
-- SEq --


diff --git a/gcc/ada/ali.ads b/gcc/ada/ali.ads
--- a/gcc/ada/ali.ads
+++ b/gcc/ada/ali.ads
@@ -1350,8 +1350,8 @@ package ALI is
pragma Inline (Name);
--  Obtain the name of invocation signature IS_Id
 
-   function Scope (IS_Id : Invocation_Signature_Id) return Name_Id;
-   pragma Inline (Scope);
+   function IS_Scope (IS_Id : Invocation_Signature_Id) return Name_Id;
+   pragma Inline (IS_Scope);
--  Obtain the scope of invocation signature IS_Id
 
procedure Set_Invocation_Graph_Encoding


diff --git a/gcc/ada/bindo-writers.adb b/gcc/ada/bindo-writers.adb
--- a/gcc/ada/bindo-writers.adb
+++ b/gcc/ada/bindo-writers.adb
@@ -222,7 +222,7 @@ package body Bindo.Writers is
  Write_Eol;
 
  Write_Str  ("  Scope = ");
- Write_Name (Scope (IS_Id));
+ Write_Name (IS_Scope (IS_Id));
  Write_Eol;
   end Write_Invocation_Signature;
 


diff --git a/gcc/ada/lib-writ.adb b/gcc/ada/lib-writ.adb
--- a/gcc/ada/lib-writ.adb
+++ b/gcc/ada/lib-writ.adb
@@ -1724,7 +1724,7 @@ package body Lib.Writ is
 
   --  scope
 
-  Write_Info_Name (Scope (IS_Id));
+  Write_Info_Name (IS_Scope (IS_Id));
   Write_Info_Char (' ');
 
   --  line

[Ada] Simplify membership tests with N_Delay_Statement subtype

[Pierre-Marie de Rodat]

Simplify membership test on N_Delay_Relative_Statement and
N_Delay_Until_Statement using the collective N_Delay_Statement subtype.
Cleanup only; semantics is unaffected.

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

gcc/ada/

* exp_ch9.adb, sem_warn.adb: Simplify membership test.diff --git a/gcc/ada/exp_ch9.adb b/gcc/ada/exp_ch9.adb
--- a/gcc/ada/exp_ch9.adb
+++ b/gcc/ada/exp_ch9.adb
@@ -7161,8 +7161,7 @@ package body Exp_Ch9 is
  if Ada_Version >= Ada_2005
and then
  (No (Original_Node (Ecall))
-   or else Nkind (Original_Node (Ecall)) not in
- N_Delay_Relative_Statement | N_Delay_Until_Statement)
+   or else Nkind (Original_Node (Ecall)) not in N_Delay_Statement)
  then
 Extract_Dispatching_Call (Ecall, Call_Ent, Obj, Actuals, Formals);
 


diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -750,9 +750,7 @@ package body Sem_Warn is
  Fstm : constant Node_Id :=
   Original_Node (First (Statements (Loop_Statement)));
   begin
- if Nkind (Fstm) = N_Delay_Relative_Statement
-   or else Nkind (Fstm) = N_Delay_Until_Statement
- then
+ if Nkind (Fstm) in N_Delay_Statement then
 return;
  end if;
   end;

[Ada] Fix typo in checks for implementation defined units

[Pierre-Marie de Rodat]

Fix mismatch in iterating over a range for Ada 2012 and referencing an
array for Ada 95. This didn't affect the behaviour, because the
referenced boolean flags in both arrays were the same for the iterated
subrange.

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

gcc/ada/

* impunit.adb (Not_Impl_Defined_Unit): Fix typo in iteration
over Non_Imp_File_Names_12 array.diff --git a/gcc/ada/impunit.adb b/gcc/ada/impunit.adb
--- a/gcc/ada/impunit.adb
+++ b/gcc/ada/impunit.adb
@@ -999,7 +999,7 @@ package body Impunit is
 
   for J in Non_Imp_File_Names_12'Range loop
  if Name_Buffer (1 .. 8) = Non_Imp_File_Names_12 (J).Fname then
-return Non_Imp_File_Names_95 (J).RMdef
+return Non_Imp_File_Names_12 (J).RMdef
   and then Ada_Version >= Ada_2012;
  end if;
   end loop;

[Ada] Remove inconsistent colons in messages for Ada 83 violations

[Pierre-Marie de Rodat]

Most of the errors of the form "(Ada 83) ..." don't have a colon; fix
inconsistencies.

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

gcc/ada/

* par-ch3.adb (P_Modular_Type_Definition): Remove colon from
error message.
* sem_ch11.adb (Check_Duplication): Likewise.
* sem_ch3.adb (Derived_Type_Declaration): Likewise.diff --git a/gcc/ada/par-ch3.adb b/gcc/ada/par-ch3.adb
--- a/gcc/ada/par-ch3.adb
+++ b/gcc/ada/par-ch3.adb
@@ -2430,7 +2430,7 @@ package body Ch3 is
 
begin
   if Ada_Version = Ada_83 then
- Error_Msg_SC ("(Ada 83): modular types not allowed");
+ Error_Msg_SC ("(Ada 83) modular types not allowed");
   end if;
 
   Typedef_Node := New_Node (N_Modular_Type_Definition, Token_Ptr);


diff --git a/gcc/ada/sem_ch11.adb b/gcc/ada/sem_ch11.adb
--- a/gcc/ada/sem_ch11.adb
+++ b/gcc/ada/sem_ch11.adb
@@ -127,7 +127,7 @@ package body Sem_Ch11 is
and then Comes_From_Source (Id)
  then
 Error_Msg_N
-  ("(Ada 83): duplicate exception choice&", Id);
+  ("(Ada 83) duplicate exception choice&", Id);
  end if;
   end if;
end if;


diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -16943,7 +16943,7 @@ package body Sem_Ch3 is
   then
  if Ada_Version = Ada_83 and then Comes_From_Source (Indic) then
 Error_Msg_N
-  ("(Ada 83): premature use of type for derivation", Indic);
+  ("(Ada 83) premature use of type for derivation", Indic);
  end if;
   end if;
 

[Ada] Fix memory leak in GNAT.Expect.Non_Blocking_Spawn on Windows

[Pierre-Marie de Rodat]

It is not leaking on Linux because the memory heap is reinitialized when
the new executable is loaded into the child process after calling fork.

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

gcc/ada/

* libgnat/g-expect.adb (Non_Blocking_Spawn): Deallocate elements
on Arg_List after calling Set_Up_Child_Communications.diff --git a/gcc/ada/libgnat/g-expect.adb b/gcc/ada/libgnat/g-expect.adb
--- a/gcc/ada/libgnat/g-expect.adb
+++ b/gcc/ada/libgnat/g-expect.adb
@@ -1181,6 +1181,12 @@ package body GNAT.Expect is
  Set_Up_Child_Communications
(Descriptor, Pipe1, Pipe2, Pipe3, Command_With_Path.all,
 C_Arg_List'Address);
+
+ --  On Windows systems we need to release memory taken for Arg_List
+
+ for A of Arg_List loop
+Free (A);
+ end loop;
   end if;
 
   Free (Command_With_Path);