Re: [PATCH] PR c++/103338 - Add testcase for issue fixed by recent commit

2024-06-04 Thread Simon Martin
Hi Jason,

On 4 Jun 2024, at 18:12, Jason Merrill wrote:

> On 6/4/24 11:54, Simon Martin wrote:
>> The case in that PR used to ICE until commit f04dc89.
>
> Interesting, I don't remember expecting that patch to change behavior 
> at all.
This is the patch that git bisect identified. I have to admit that I did 
not look further.

> BTW, it looks like your recent commits and emails have had 
> non-conventional subject lines; see 
> https://gcc.gnu.org/contribute.html#patches for more guidance.
>
Thanks for the pointer and apologies for not providing great subject 
lines; I’ll fix this moving forward (starting with that patch).

> For instance, the subject for this patch could be
>
> c++: add testcase for PR103338
>
> OK with that adjustment.
Thanks again.
>
>> This patch simply adds
>> the case to the testsuite.
>>
>> Successfully tested on x86_64-pc-linux-gnu.
>>
>>  PR c++/1033388
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * g++.dg/parse/crash73.C: New test.
>>
>> ---
>>   gcc/testsuite/g++.dg/parse/crash73.C | 19 +++
>>   1 file changed, 19 insertions(+)
>>   create mode 100644 gcc/testsuite/g++.dg/parse/crash73.C
>>
>> diff --git a/gcc/testsuite/g++.dg/parse/crash73.C 
>> b/gcc/testsuite/g++.dg/parse/crash73.C
>> new file mode 100644
>> index 000..5923b98b719
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.dg/parse/crash73.C
>> @@ -0,0 +1,19 @@
>> +// PR c++/1033388
>> +// { dg-do compile { target c++11 } }
>> +
>> +template
>> +struct zip_view {
>> +  struct Iterator;
>> +};
>> +
>> +template
>> +struct zip_transform_view;
>> +
>> +template
>> +struct zip_view::Iterator { // { dg-error "no class 
>> template" }
>> +  template
>> +  template
>> +  friend class zip_transform_view::Iterator;
>> +};
>> +
>> +zip_view<>::Iterator iter;



Re: [PATCH] PR c++/103338 - Add testcase for issue fixed by recent commit

2024-06-04 Thread Jason Merrill

On 6/4/24 11:54, Simon Martin wrote:

The case in that PR used to ICE until commit f04dc89.


Interesting, I don't remember expecting that patch to change behavior at 
all.


BTW, it looks like your recent commits and emails have had 
non-conventional subject lines; see 
https://gcc.gnu.org/contribute.html#patches for more guidance.


For instance, the subject for this patch could be

c++: add testcase for PR103338

OK with that adjustment.


This patch simply adds
the case to the testsuite.

Successfully tested on x86_64-pc-linux-gnu.

PR c++/1033388

gcc/testsuite/ChangeLog:

* g++.dg/parse/crash73.C: New test.

---
  gcc/testsuite/g++.dg/parse/crash73.C | 19 +++
  1 file changed, 19 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/parse/crash73.C

diff --git a/gcc/testsuite/g++.dg/parse/crash73.C 
b/gcc/testsuite/g++.dg/parse/crash73.C
new file mode 100644
index 000..5923b98b719
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/crash73.C
@@ -0,0 +1,19 @@
+// PR c++/1033388
+// { dg-do compile { target c++11 } }
+
+template
+struct zip_view {
+  struct Iterator;
+};
+
+template
+struct zip_transform_view;
+
+template
+struct zip_view::Iterator { // { dg-error "no class template" }
+  template
+  template
+  friend class zip_transform_view::Iterator;
+};
+
+zip_view<>::Iterator iter;




[PATCH] PR c++/103338 - Add testcase for issue fixed by recent commit

2024-06-04 Thread Simon Martin
The case in that PR used to ICE until commit f04dc89. This patch simply adds
the case to the testsuite.

Successfully tested on x86_64-pc-linux-gnu.

PR c++/1033388

gcc/testsuite/ChangeLog:

* g++.dg/parse/crash73.C: New test.

---
 gcc/testsuite/g++.dg/parse/crash73.C | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/parse/crash73.C

diff --git a/gcc/testsuite/g++.dg/parse/crash73.C 
b/gcc/testsuite/g++.dg/parse/crash73.C
new file mode 100644
index 000..5923b98b719
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/crash73.C
@@ -0,0 +1,19 @@
+// PR c++/1033388
+// { dg-do compile { target c++11 } }
+
+template
+struct zip_view {
+  struct Iterator;
+};
+
+template
+struct zip_transform_view;
+
+template
+struct zip_view::Iterator { // { dg-error "no class template" }
+  template
+  template
+  friend class zip_transform_view::Iterator;
+};
+
+zip_view<>::Iterator iter;
-- 
2.44.0




Re: [Patch] contrib/gcc-changelog/git_update_version.py: Improve diagnostic (was: [Patch] contrib/gcc-changelog/git_update_version.py: Add ignore commit, improve diagnostic)

2024-05-20 Thread Jakub Jelinek
On Mon, May 20, 2024 at 08:31:02AM +0200, Tobias Burnus wrote:
> Hmm, there were now two daily bumps:
> 
> Date:   Mon May 20 00:16:30 2024 +
> 
> Date:   Sun May 19 18:15:28 2024 +
> 
> I really wonder why.

Because I've done it by hand.
I have in ~gccadmin a gcc-changelog copy and adjusted update_version_git
script which doesn't use contrib/gcc-changelog subdirectory from the
checkout it makes but from the ~gccadmin directory, because I don't want to
constantly try to add some commit number to IGNORED_COMMITS, see that it
either works or doesn't (I think sometimes it needs the hash of the revert
commit, at other times the commit hash referenced in the revert commit)
or that further ones are needed.

> From f56b1764f2b5c2c83c6852607405e5be0a763a2c Mon Sep 17 00:00:00 2001
> From: Tobias Burnus 
> Date: Sun, 19 May 2024 08:17:42 +0200
> Subject: [PATCH] contrib/gcc-changelog/git_update_version.py: Improve 
> diagnostic
> 
> contrib/ChangeLog:
> 
> * gcc-changelog/git_update_version.py (prepend_to_changelog_files): 
> Output

8 spaces rather than tab

>   git hash in case errors occurred.
> 
> diff --git a/contrib/gcc-changelog/git_update_version.py 
> b/contrib/gcc-changelog/git_update_version.py
> index 24f6c43d0b2..ec0151b83fe 100755
> --- a/contrib/gcc-changelog/git_update_version.py
> +++ b/contrib/gcc-changelog/git_update_version.py
> @@ -58,6 +58,7 @@ def read_timestamp(path):
>  
>  def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):
>  if not git_commit.success:
> +logging.info(f"While processing {git_commit.info.hexsha}:")
>  for error in git_commit.errors:
>  logging.info(error)
>  raise AssertionError()

So, your commit is useful part of it, I'm already using something similar in
my hack (just was doing it for even successful commits, but I think your
patch is better).
And, I think best would be if update_version_git script simply
accepted a list of ignored commits from the command line too,
passed it to the git_update_version.py script and that one
added those to IGNORED_COMMITS.
Because typically if the DATESTAMP/ChangeLog updates gets stuck,
one doesn't just adjust IGNORED_COMMITS and wait up to another
day to see if it worked, but runs the script by hand to make sure
it works.

--- gcc-checkout/contrib/gcc-changelog/git_update_version.py2024-05-13 
16:52:57.890151748 +
+++ gcc-changelog/git_update_version.py 2024-05-19 18:13:44.953648834 +
@@ -41,7 +41,21 @@ IGNORED_COMMITS = (
 '040e5b0edbca861196d9e2ea2af5e805769c8d5d',
 '8057f9aa1f7e70490064de796d7a8d42d446caf8',
 '109f1b28fc94c93096506e3df0c25e331cef19d0',
-'39f81924d88e3cc197fc3df74204c9b5e01e12f7')
+'39f81924d88e3cc197fc3df74204c9b5e01e12f7',
+'d7bb8eaade3cd3aa70715c8567b4d7b08098e699',
+'89feb3557a018893cfe50c2e07f91559bd3cde2b',
+'ccf8d3e3d26c6ba3d5e11fffeed8d64018e9c060',
+'e0c52905f666e3d23881f82dbf39466a24f009f4',
+'b38472ffc1e631bd357573b44d956ce16d94e666',
+'a0b13d0860848dd5f2876897ada1e22e4e681e91',
+'b8c772cae97b54386f7853edf0f9897012bfa90b',
+'810d35a7e054bcbb5b66d2e5924428e445f5fba9',
+'0df1ee083434ac00ecb19582b1e5b25e105981b2',
+'2c688f6afce4cbb414f5baab1199cd525f309fca',
+'60dcb710b6b4aa22ea96abc8df6dfe9067f3d7fe',
+'44968a0e00f656e9bb3e504bb2fa1a8282002015',
+'d7bb8eaade3cd3aa70715c8567b4d7b08098e699',
+'da73261ce7731be7f2b164f1db796878cdc23365')
 
 FORMAT = '%(asctime)s:%(levelname)s:%(name)s:%(message)s'
 logging.basicConfig(level=logging.INFO, format=FORMAT,
@@ -125,6 +139,7 @@ def update_current_branch(ref_name):
   % (commit.hexsha, head.hexsha), ref_name)
 commits = [c for c in commits if c.info.hexsha not in IGNORED_COMMITS]
 for git_commit in reversed(commits):
+logging.info('trying %s', git_commit.info.hexsha)
 prepend_to_changelog_files(repo, args.git_path, git_commit,
not args.dry_mode)
 if args.dry_mode:

Jakub



[Patch] contrib/gcc-changelog/git_update_version.py: Improve diagnostic (was: [Patch] contrib/gcc-changelog/git_update_version.py: Add ignore commit, improve diagnostic)

2024-05-20 Thread Tobias Burnus

Hmm, there were now two daily bumps:

Date:   Mon May 20 00:16:30 2024 +

Date:   Sun May 19 18:15:28 2024 +

I really wonder why.

I guess, the 'ignore commit' is hence not needed – but I think the 
improved diagnostic part still makes sense.


See updated patch.

On May 19, 24 Tobias Burnus wrote:

I noticed that the last bump happened on Thursday.

* * *

The error is according to
https://gcc.gnu.org/pipermail/gccadmin/2024q2/021298.html

2024-05-19 00:17:28,643:INFO:root:cannot find a ChangeLog location in 
message


That's the commit
---
    Revert "Revert: "Enable prange support.""

    This reverts commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 and 
enables prange

    support again.
---

* * * The attached patch adds this commit to the ignore list and helps 
with the diagnosis by showing the failing hash in the error message.


OK for mainline?

Post commit: Can someone install the new version + fix the ChangeLog 
for the ignored commit?


* * *

What I do not understand: Why does this commit get applied? I do see 
for both


contrib/gcc-changelog/git_check_commit.py -v -p 
da73261ce7731be7f2b164f1db796878cdc23365


and

contrib/gcc-changelog/git_email.py 
0001-Revert-Revert-Enable-prange-support.patch the error above. - And 
I do not understand why it made it past the commit check but now fails?


Likewise for8057f9aa1f7e70490064de796d7a8d42d446caf8

Does the commit hook use an older version of the check scripts? Does 
it ignore the errors? Or what goes wrong here? Any idea?


TobiasFrom f56b1764f2b5c2c83c6852607405e5be0a763a2c Mon Sep 17 00:00:00 2001
From: Tobias Burnus 
Date: Sun, 19 May 2024 08:17:42 +0200
Subject: [PATCH] contrib/gcc-changelog/git_update_version.py: Improve diagnostic

contrib/ChangeLog:

* gcc-changelog/git_update_version.py (prepend_to_changelog_files): Output
	git hash in case errors occurred.

diff --git a/contrib/gcc-changelog/git_update_version.py b/contrib/gcc-changelog/git_update_version.py
index 24f6c43d0b2..ec0151b83fe 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -58,6 +58,7 @@ def read_timestamp(path):
 
 def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):
 if not git_commit.success:
+logging.info(f"While processing {git_commit.info.hexsha}:")
 for error in git_commit.errors:
 logging.info(error)
 raise AssertionError()
-- 
2.45.0



[Patch] contrib/gcc-changelog/git_update_version.py: Add ignore commit, improve diagnostic

2024-05-19 Thread Tobias Burnus

I noticed that the last bump happened on Thursday.

* * *

The error is according to
https://gcc.gnu.org/pipermail/gccadmin/2024q2/021298.html

2024-05-19 00:17:28,643:INFO:root:cannot find a ChangeLog location in message

That's the commit
---
Revert "Revert: "Enable prange support.""

    This reverts commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 and enables 
prange
support again.
---

* * * The attached patch adds this commit to the ignore list and helps 
with the diagnosis by showing the failing hash in the error message. OK 
for mainline? Post commit: Can someone install the new version + fix the 
ChangeLog for the ignored commit? * * * What I do not understand: Why does this commit get applied? I do see for both
contrib/gcc-changelog/git_check_commit.py -v -p 
da73261ce7731be7f2b164f1db796878cdc23365 and 
contrib/gcc-changelog/git_email.py 
0001-Revert-Revert-Enable-prange-support.patch the error above. - And I 
do not understand why it made it past the commit check but now fails?

Likewise for8057f9aa1f7e70490064de796d7a8d42d446caf8
Does the commit hook use an older version of the check scripts? Does it 
ignore the errors? Or what goes wrong here? Any idea? Tobias
From f56b1764f2b5c2c83c6852607405e5be0a763a2c Mon Sep 17 00:00:00 2001
From: Tobias Burnus 
Date: Sun, 19 May 2024 08:17:42 +0200
Subject: [PATCH] contrib/gcc-changelog/git_update_version.py: Add ignore
 commit, improve diagnostic

contrib/ChangeLog:

* gcc-changelog/git_update_version.py (IGNORED_COMMITS): Add
	cfceb070e2aea3cef9bd1f50d8d030c51449f45b.
	(prepend_to_changelog_files): Output git hash in case of error.

diff --git a/contrib/gcc-changelog/git_update_version.py b/contrib/gcc-changelog/git_update_version.py
index 24f6c43d0b2..ec0151b83fe 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -41,7 +41,8 @@ IGNORED_COMMITS = (
 '040e5b0edbca861196d9e2ea2af5e805769c8d5d',
 '8057f9aa1f7e70490064de796d7a8d42d446caf8',
 '109f1b28fc94c93096506e3df0c25e331cef19d0',
-'39f81924d88e3cc197fc3df74204c9b5e01e12f7')
+'39f81924d88e3cc197fc3df74204c9b5e01e12f7',
+'da73261ce7731be7f2b164f1db796878cdc23365')
 
 FORMAT = '%(asctime)s:%(levelname)s:%(name)s:%(message)s'
 logging.basicConfig(level=logging.INFO, format=FORMAT,
@@ -58,6 +59,7 @@ def read_timestamp(path):
 
 def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):
 if not git_commit.success:
+logging.info(f"While processing {git_commit.info.hexsha}:")
 for error in git_commit.errors:
 logging.info(error)
 raise AssertionError()
-- 
2.45.0



[commit] Regenerate opt.urls

2024-03-15 Thread YunQiang Su
Fixes: acc38ff59976 ("MIPS: Add -m(no-)strict-align option")

gcc/ChangeLog:

* config/riscv/riscv.opt.urls: Regenerated.
* config/rs6000/sysv4.opt.urls: Likewise.
* config/xtensa/xtensa.opt.urls: Likewise.
---
 gcc/config/riscv/riscv.opt.urls   | 2 +-
 gcc/config/rs6000/sysv4.opt.urls  | 2 +-
 gcc/config/xtensa/xtensa.opt.urls | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/riscv/riscv.opt.urls b/gcc/config/riscv/riscv.opt.urls
index f40795866cf..da31820e234 100644
--- a/gcc/config/riscv/riscv.opt.urls
+++ b/gcc/config/riscv/riscv.opt.urls
@@ -44,7 +44,7 @@ UrlSuffix(gcc/RISC-V-Options.html#index-mshorten-memrefs)
 ; skipping UrlSuffix for 'mcmodel=' due to finding no URLs
 
 mstrict-align
-UrlSuffix(gcc/RISC-V-Options.html#index-mstrict-align-3)
+UrlSuffix(gcc/RISC-V-Options.html#index-mstrict-align-4)
 
 ; skipping UrlSuffix for 'mexplicit-relocs' due to finding no URLs
 
diff --git a/gcc/config/rs6000/sysv4.opt.urls b/gcc/config/rs6000/sysv4.opt.urls
index f8d58d6602c..c155cddfa36 100644
--- a/gcc/config/rs6000/sysv4.opt.urls
+++ b/gcc/config/rs6000/sysv4.opt.urls
@@ -12,7 +12,7 @@ mbit-align
 UrlSuffix(gcc/RS_002f6000-and-PowerPC-Options.html#index-mbit-align)
 
 mstrict-align
-UrlSuffix(gcc/RS_002f6000-and-PowerPC-Options.html#index-mstrict-align-4)
+UrlSuffix(gcc/RS_002f6000-and-PowerPC-Options.html#index-mstrict-align-5)
 
 mrelocatable
 UrlSuffix(gcc/RS_002f6000-and-PowerPC-Options.html#index-mrelocatable)
diff --git a/gcc/config/xtensa/xtensa.opt.urls 
b/gcc/config/xtensa/xtensa.opt.urls
index 146db23d1e3..1f193a7da0c 100644
--- a/gcc/config/xtensa/xtensa.opt.urls
+++ b/gcc/config/xtensa/xtensa.opt.urls
@@ -33,5 +33,5 @@ mabi=windowed
 UrlSuffix(gcc/Xtensa-Options.html#index-mabi_003dwindowed)
 
 mstrict-align
-UrlSuffix(gcc/Xtensa-Options.html#index-mstrict-align-5)
+UrlSuffix(gcc/Xtensa-Options.html#index-mstrict-align-6)
 
-- 
2.39.2



[commit] MIPS: Add -m(no-)strict-align option

2024-03-15 Thread YunQiang Su
We support options -m(no-)unaligned-access 2 years ago, while
currently most of other ports prefer -m(no-)strict-align.
Let's support -m(no-)strict-align, and keep -m(no-)unaligned-access
as alias.

gcc
* config/mips/mips.opt: Support -mstrict-align, and use
TARGET_STRICT_ALIGN as the flag; keep -m(no-)unaligned-access
as alias.
* config/mips/mips.h: Use TARGET_STRICT_ALIGN.
* config/mips/mips.opt.urls: Regenerate.
* doc/invoke.texi: Document -m(no-)strict-algin for MIPSr6.
---
 gcc/config/mips/mips.h|  2 +-
 gcc/config/mips/mips.opt  | 12 ++--
 gcc/config/mips/mips.opt.urls |  6 ++
 gcc/doc/invoke.texi   | 18 --
 4 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 7145d23c650..6444a68dfd5 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -251,7 +251,7 @@ struct mips_cpu_info {
 || ISA_HAS_MSA))
 
 /* ISA load/store instructions can handle unaligned address */
-#define ISA_HAS_UNALIGNED_ACCESS (TARGET_UNALIGNED_ACCESS \
+#define ISA_HAS_UNALIGNED_ACCESS (!TARGET_STRICT_ALIGN \
 && (mips_isa_rev >= 6))
 
 /* The ISA compression flags that are currently in effect.  */
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index ce36942aabe..c1abb36212f 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -429,9 +429,17 @@ mtune=
 Target RejectNegative Joined Var(mips_tune_option) ToLower 
Enum(mips_arch_opt_value)
 -mtune=PROCESSOR   Optimize the output for PROCESSOR.
 
+mstrict-align
+Target Var(TARGET_STRICT_ALIGN) Init(0)
+Don't generate code with unaligned load store, only valid for MIPS R6.
+
 munaligned-access
-Target Var(TARGET_UNALIGNED_ACCESS) Init(1)
-Generate code with unaligned load store, valid for MIPS R6.
+Target RejectNegative Alias(mstrict-align) NegativeAlias
+Generate code with unaligned load store for R6 (alias of -mno-strict-align).
+
+mno-unaligned-access
+Target RejectNegative Alias(mstrict-align)
+Don't generate code with unaligned load store for R6 (alias of -mstrict-align).
 
 muninit-const-in-rodata
 Target Var(TARGET_UNINIT_CONST_IN_RODATA)
diff --git a/gcc/config/mips/mips.opt.urls b/gcc/config/mips/mips.opt.urls
index 96aba041026..9d166646d65 100644
--- a/gcc/config/mips/mips.opt.urls
+++ b/gcc/config/mips/mips.opt.urls
@@ -233,9 +233,15 @@ UrlSuffix(gcc/MIPS-Options.html#index-mmadd4)
 mtune=
 UrlSuffix(gcc/MIPS-Options.html#index-mtune-10)
 
+mstrict-align
+UrlSuffix(gcc/MIPS-Options.html#index-mstrict-align-3)
+
 munaligned-access
 UrlSuffix(gcc/MIPS-Options.html#index-munaligned-access-1)
 
+mno-unaligned-access
+UrlSuffix(gcc/MIPS-Options.html#index-mno-unaligned-access-1)
+
 muninit-const-in-rodata
 UrlSuffix(gcc/MIPS-Options.html#index-muninit-const-in-rodata)
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 85c938d4a14..864768fd2f4 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1143,7 +1143,8 @@ Objective-C and Objective-C++ Dialects}.
 -mcheck-zero-division  -mno-check-zero-division
 -mdivide-traps  -mdivide-breaks
 -mload-store-pairs  -mno-load-store-pairs
--munaligned-access  -mno-unaligned-access
+-mstrict-align  -mno-strict-align
+-mno-unaligned-access  -munaligned-access
 -mmemcpy  -mno-memcpy  -mlong-calls  -mno-long-calls
 -mmad  -mno-mad  -mimadd  -mno-imadd  -mfused-madd  -mno-fused-madd  -nocpp
 -mfix-24k  -mno-fix-24k
@@ -28561,14 +28562,19 @@ instructions to enable load/store bonding.  This 
option is enabled by
 default but only takes effect when the selected architecture is known
 to support bonding.
 
+@opindex mstrict-align
+@opindex mno-strict-align
 @opindex munaligned-access
 @opindex mno-unaligned-access
-@item -munaligned-access
+@item -mstrict-align
+@itemx -mno-strict-align
+@itemx -munaligned-access
 @itemx -mno-unaligned-access
-Enable (disable) direct unaligned access for MIPS Release 6.
-MIPSr6 requires load/store unaligned-access support,
-by hardware or trap
-So @option{-mno-unaligned-access} may be needed by kernel.
+Disable (enable) direct unaligned access for MIPS Release 6.
+MIPSr6 requires load/store unaligned-access support, by hardware or
+trap  So @option{-mstrict-align} may be needed by kernel.  The
+options @option{-munaligned-access} and @option{-mno-unaligned-access}
+are obsoleted, and only for backward-compatible.
 
 @opindex mmemcpy
 @opindex mno-memcpy
-- 
2.39.2



[commit] invoke.texi: Fix some skipping UrlSuffix problem for MIPS

2024-02-21 Thread YunQiang Su
The problem is that, there are these lines in mips.opt.urls:
  ; skipping UrlSuffix for 'mabi=' due to finding no URLs
  ; skipping UrlSuffix for 'mno-flush-func' due to finding no URLs
  ; skipping UrlSuffix for 'mexplicit-relocs' due to finding no URLs

These lines is not fixed by this patch due to that we don't
document these options:
  ; skipping UrlSuffix for 'mlra' due to finding no URLs
  ; skipping UrlSuffix for 'mdebug' due to finding no URLs
  ; skipping UrlSuffix for 'meb' due to finding no URLs
  ; skipping UrlSuffix for 'mel' due to finding no URLs

gcc
* doc/invoke.texi(MIPS Options): Fix skipping UrlSuffix
problem of mabi=, mno-flush-func, mexplicit-relocs;
add missing leading - of mbranch-cost option.
* config/mips/mips.opt.urls: Regenerate.
---
 gcc/config/mips/mips.opt.urls | 12 ++--
 gcc/doc/invoke.texi   | 14 +-
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/gcc/config/mips/mips.opt.urls b/gcc/config/mips/mips.opt.urls
index ff2f0aee0e3..96aba041026 100644
--- a/gcc/config/mips/mips.opt.urls
+++ b/gcc/config/mips/mips.opt.urls
@@ -6,7 +6,8 @@ UrlSuffix(gcc/MIPS-Options.html#index-EB-2)
 EL
 UrlSuffix(gcc/MIPS-Options.html#index-EL-2)
 
-; skipping UrlSuffix for 'mabi=' due to finding no URLs
+mabi=
+UrlSuffix(gcc/MIPS-Options.html#index-mabi-3)
 
 mabicalls
 UrlSuffix(gcc/MIPS-Options.html#index-mabicalls)
@@ -65,9 +66,15 @@ UrlSuffix(gcc/MIPS-Options.html#index-membedded-data)
 meva
 UrlSuffix(gcc/MIPS-Options.html#index-meva)
 
+mexplicit-relocs=
+UrlSuffix(gcc/MIPS-Options.html#index-mexplicit-relocs-2)
+
 mexplicit-relocs
 UrlSuffix(gcc/MIPS-Options.html#index-mexplicit-relocs-2)
 
+mno-explicit-relocs
+UrlSuffix(gcc/MIPS-Options.html#index-mno-explicit-relocs-2)
+
 mextern-sdata
 UrlSuffix(gcc/MIPS-Options.html#index-mextern-sdata)
 
@@ -173,7 +180,8 @@ UrlSuffix(gcc/MIPS-Options.html#index-mno-float)
 mmcu
 UrlSuffix(gcc/MIPS-Options.html#index-mmcu-1)
 
-; skipping UrlSuffix for 'mno-flush-func' due to finding no URLs
+mno-flush-func
+UrlSuffix(gcc/MIPS-Options.html#index-mno-flush-func-1)
 
 mno-mdmx
 UrlSuffix(gcc/MIPS-Options.html#index-mno-mdmx)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8219a6a5947..58527e1ea3c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -27995,11 +27995,7 @@ Aliases of @option{-minterlink-compressed} and
 @option{-mno-interlink-compressed}.  These options predate the microMIPS ASE
 and are retained for backwards compatibility.
 
-@opindex mabi=32
-@opindex mabi=o64
-@opindex mabi=n32
-@opindex mabi=64
-@opindex mabi=eabi
+@opindex mabi
 @item -mabi=32
 @itemx -mabi=o64
 @itemx -mabi=n32
@@ -28486,9 +28482,8 @@ Enable (disable) use of the @code{%hi()} and 
@code{%lo()} assembler
 relocation operators.  This option has been superseded by
 @option{-mexplicit-relocs} but is retained for backwards compatibility.
 
-@opindex mexplicit-relocs=none
-@opindex mexplicit-relocs=base
-@opindex mexplicit-relocs=pcrel
+@opindex mexplicit-relocs
+@opindex mno-explicit-relocs
 @item -mexplicit-relocs=none
 @itemx -mexplicit-relocs=base
 @itemx -mexplicit-relocs=pcrel
@@ -28767,6 +28762,7 @@ Disable the insertion of cache barriers.  This is the 
default setting.
 @end table
 
 @opindex mflush-func
+@opindex mno-flush-func
 @item -mflush-func=@var{func}
 @itemx -mno-flush-func
 Specifies the function to call to flush the I and D caches, or to not
@@ -28778,7 +28774,7 @@ depends on the target GCC was configured for, but 
commonly is either
 @code{_flush_func} or @code{__cpu_flush}.
 
 @opindex mbranch-cost
-@item mbranch-cost=@var{num}
+@item -mbranch-cost=@var{num}
 Set the cost of branches to roughly @var{num} ``simple'' instructions.
 This cost is only a heuristic and is not guaranteed to produce
 consistent results across releases.  A zero cost redundantly selects
-- 
2.39.2



[commit] Sanitizer/MIPS: Use $t9 for preemptible function call

2024-01-17 Thread YunQiang Su
From: YunQiang Su 

Currently, almost all of the shared libraries of MIPS, rely on $t9
to get the address of current function, instead of PCREL instructions,
even on MIPSr6. So we have to set $t9 properly.

To get the address of preemptible function, we need the help of GOT.
MIPS/O32 has .cpload, which can help to generate 3 instructions to get GOT.
For __mips64, we can get GOT by:

lui $t8, %hi(%neg(%gp_rel(SANITIZER_STRINGIFY(TRAMPOLINE(func)
daddu $t8, $t8, $t9
daddiu $t8, $t8, %hi(%neg(%gp_rel(SANITIZER_STRINGIFY(TRAMPOLINE(func)

And then get the address of __interceptor_func, and jump to it

ld $t9, %got_disp(_interceptor" SANITIZER_STRINGIFY(func) ")($t8)
jr $t9

Upstream-Commit: 0a64367a72f1634321f5051221f05f2f364bd882

libsanitizer

* interception/interception.h (substitution_##func_name):
Use macro C_ASM_TAIL_CALL.
* sanitizer_common/sanitizer_asm.h: Define C_ASM_TAIL_CALL
for MIPS with help of t9.
---
 libsanitizer/interception/interception.h  |  5 ++--
 libsanitizer/sanitizer_common/sanitizer_asm.h | 23 +++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/libsanitizer/interception/interception.h 
b/libsanitizer/interception/interception.h
index 9d8b60b2eef..58e969378a9 100644
--- a/libsanitizer/interception/interception.h
+++ b/libsanitizer/interception/interception.h
@@ -205,8 +205,9 @@ const interpose_substitution substitution_##func_name[] 
\
  ASM_TYPE_FUNCTION_STR "\n"
\
SANITIZER_STRINGIFY(TRAMPOLINE(func)) ":\n" 
\
SANITIZER_STRINGIFY(CFI_STARTPROC) "\n" 
\
-   SANITIZER_STRINGIFY(ASM_TAIL_CALL) " __interceptor_"
\
- SANITIZER_STRINGIFY(ASM_PREEMPTIBLE_SYM(func)) "\n"   
\
+   C_ASM_TAIL_CALL(SANITIZER_STRINGIFY(TRAMPOLINE(func)),  
\
+   "__interceptor_"
\
+ SANITIZER_STRINGIFY(ASM_PREEMPTIBLE_SYM(func))) "\n"  
\
SANITIZER_STRINGIFY(CFI_ENDPROC) "\n"   
\
".size  " SANITIZER_STRINGIFY(TRAMPOLINE(func)) ", "
\
 ".-" SANITIZER_STRINGIFY(TRAMPOLINE(func)) "\n"
\
diff --git a/libsanitizer/sanitizer_common/sanitizer_asm.h 
b/libsanitizer/sanitizer_common/sanitizer_asm.h
index bbb18cfbdf1..3af66a4e449 100644
--- a/libsanitizer/sanitizer_common/sanitizer_asm.h
+++ b/libsanitizer/sanitizer_common/sanitizer_asm.h
@@ -53,6 +53,29 @@
 # define ASM_TAIL_CALL tail
 #endif
 
+// Currently, almost all of the shared libraries rely on the value of
+// $t9 to get the address of current function, instead of PCREL, even
+// on MIPSr6. To be compatiable with them, we have to set $t9 properly.
+// MIPS uses GOT to get the address of preemptible functions.
+#if defined(__mips64)
+#  define C_ASM_TAIL_CALL(t_func, i_func)   \
+"lui $t8, %hi(%neg(%gp_rel(" t_func ")))\n" \
+"daddu $t8, $t8, $t9\n" \
+"daddiu $t8, $t8, %lo(%neg(%gp_rel(" t_func ")))\n" \
+"ld $t9, %got_disp(" i_func ")($t8)\n"  \
+"jr $t9\n"
+#elif defined(__mips__)
+#  define C_ASM_TAIL_CALL(t_func, i_func)   \
+".setnoreorder\n"   \
+".cpload $t9\n" \
+".setreorder\n" \
+"lw $t9, %got(" i_func ")($gp)\n"   \
+"jr $t9\n"
+#elif defined(ASM_TAIL_CALL)
+#  define C_ASM_TAIL_CALL(t_func, i_func)   \
+SANITIZER_STRINGIFY(ASM_TAIL_CALL) " " i_func
+#endif
+
 #if defined(__ELF__) && defined(__x86_64__) || defined(__i386__) || \
 defined(__riscv)
 # define ASM_PREEMPTIBLE_SYM(sym) sym@plt
-- 
2.39.2



Re: [commit] MIPS: Add ATTRIBUTE_UNUSED to mips_start_function_definition

2024-01-15 Thread rep . dot . nop
On 11 January 2024 10:59:21 CET, YunQiang Su  wrote:
>Fix build warning:
>  mips.cc: warning: unused parameter 'decl'.
>
>gcc
>   * config/mips/mips.cc (mips_start_function_definition):
>   Add ATTRIBUTE_UNUSED.
>---
> gcc/config/mips/mips.cc | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
>index 60b336e43d0..e752019b5e2 100644
>--- a/gcc/config/mips/mips.cc
>+++ b/gcc/config/mips/mips.cc
>@@ -7330,7 +7330,8 @@ mips_start_unique_function (const char *name)
>function contains MIPS16 code.  */
> 
> static void
>-mips_start_function_definition (const char *name, bool mips16_p, tree decl)
>+mips_start_function_definition (const char *name, bool mips16_p,
>+  tree decl ATTRIBUTE_UNUSED)

Nowadays in C++ you can just remove the identifier name:

+mips_start_function_definition (const char *name, bool mips16_p, tree)

> {
>   if (mips16_p)
> fprintf (asm_out_file, "\t.set\tmips16\n");



[commit] MIPS: Add ATTRIBUTE_UNUSED to mips_start_function_definition

2024-01-11 Thread YunQiang Su
Fix build warning:
  mips.cc: warning: unused parameter 'decl'.

gcc
* config/mips/mips.cc (mips_start_function_definition):
Add ATTRIBUTE_UNUSED.
---
 gcc/config/mips/mips.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index 60b336e43d0..e752019b5e2 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -7330,7 +7330,8 @@ mips_start_unique_function (const char *name)
function contains MIPS16 code.  */
 
 static void
-mips_start_function_definition (const char *name, bool mips16_p, tree decl)
+mips_start_function_definition (const char *name, bool mips16_p,
+   tree decl ATTRIBUTE_UNUSED)
 {
   if (mips16_p)
 fprintf (asm_out_file, "\t.set\tmips16\n");
-- 
2.39.2



Re: [commit v3 1/2] MIPS: Put the ret to the end of args of reconcat [PR112759]

2023-12-23 Thread Andreas Schwab
On Dez 23 2023, YunQiang Su wrote:

> diff --git a/gcc/config/mips/driver-native.cc 
> b/gcc/config/mips/driver-native.cc
> index afc276f5278..4ef48e14916 100644
> --- a/gcc/config/mips/driver-native.cc
> +++ b/gcc/config/mips/driver-native.cc
> @@ -44,6 +44,8 @@ const char *
>  host_detect_local_cpu (int argc, const char **argv)
>  {
>const char *cpu = NULL;
> +  /* Don't assigne any static string to ret.  If you need to do so,
  assign

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


[commit v3 2/2] MIPS: Don't add nan2008 option for -mtune=native

2023-12-23 Thread YunQiang Su
Users may wish just use -mtune=native for performance tuning only.
Let's don't make trouble for its case.

gcc/

* config/mips/driver-native.cc (host_detect_local_cpu):
don't add nan2008 option for -mtune=native.
---
 gcc/config/mips/driver-native.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/mips/driver-native.cc b/gcc/config/mips/driver-native.cc
index 4ef48e14916..b8c37d69215 100644
--- a/gcc/config/mips/driver-native.cc
+++ b/gcc/config/mips/driver-native.cc
@@ -93,7 +93,8 @@ host_detect_local_cpu (int argc, const char **argv)
 fallback_cpu:
 #if defined (__mips_nan2008)
   /* Put the ret to the end of list, since it may be NULL.  */
-  ret = reconcat (ret, " -mnan=2008 ", ret, NULL);
+  if (arch)
+ret = reconcat (ret, " -mnan=2008 ", ret, NULL);
 #endif
 
 #ifdef HAVE_GETAUXVAL
-- 
2.39.2



[commit v3 1/2] MIPS: Put the ret to the end of args of reconcat [PR112759]

2023-12-23 Thread YunQiang Su
The function `reconcat` cannot append string(s) to NULL,
as the concat process will stop at the first NULL.

Let's always put the `ret` to the end, as it may be NULL.
We keep use reconcat here, due to that reconcat can make it
easier if we add more hardware features detecting, for example
by hwcap.

gcc/

PR target/112759
* config/mips/driver-native.cc (host_detect_local_cpu):
Put the ret to the end of args of reconcat.
---
 gcc/config/mips/driver-native.cc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/config/mips/driver-native.cc b/gcc/config/mips/driver-native.cc
index afc276f5278..4ef48e14916 100644
--- a/gcc/config/mips/driver-native.cc
+++ b/gcc/config/mips/driver-native.cc
@@ -44,6 +44,8 @@ const char *
 host_detect_local_cpu (int argc, const char **argv)
 {
   const char *cpu = NULL;
+  /* Don't assigne any static string to ret.  If you need to do so,
+ use concat.  */
   char *ret = NULL;
   char buf[128];
   FILE *f;
@@ -90,7 +92,8 @@ host_detect_local_cpu (int argc, const char **argv)
 
 fallback_cpu:
 #if defined (__mips_nan2008)
-  ret = reconcat (ret, " -mnan=2008 ", NULL);
+  /* Put the ret to the end of list, since it may be NULL.  */
+  ret = reconcat (ret, " -mnan=2008 ", ret, NULL);
 #endif
 
 #ifdef HAVE_GETAUXVAL
@@ -104,7 +107,7 @@ fallback_cpu:
 #endif
 
   if (cpu)
-ret = reconcat (ret, ret, "-m", argv[0], "=", cpu, NULL);
+ret = reconcat (ret, " -m", argv[0], "=", cpu, ret, NULL);
 
   return ret;
 }
-- 
2.39.2



[Commit QUEUE V3] RISC-V: Support strided load/store

2023-11-13 Thread Juzhe-Zhong
Strided load/store has been approved.

Rebase on V3 and adapt for middle-end IR change.

Will commit after middle-end patche is approved.

gcc/ChangeLog:

* config/riscv/autovec.md (mask_len_strided_load_): New pattern.
(mask_len_strided_store_): Ditto.
* config/riscv/riscv-protos.h (expand_strided_load_store): New function.
* config/riscv/riscv-v.cc (expand_strided_load_store): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-1.c: Adapt 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_store-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_store-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_load-1.c: 
New test.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_load_run-1.c: New test.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_store-1.c: 
New test.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_store_run-1.c: New 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-3.c: New 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-3.c: New 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_store-3.c: New 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_store_run-3.c: 
New test.

---
 gcc/config/riscv/autovec.md   | 30 ++
 gcc/config/riscv/riscv-protos.h   |  1 +
 gcc/config/riscv/riscv-v.cc   | 56 +++
 .../gather-scatter/mask_strided_load-1.c  | 47 +
 .../gather-scatter/mask_strided_load_run-1.c  | 97 +++
 .../gather-scatter/mask_strided_store-1.c | 48 +
 .../gather-scatter/mask_strided_store_run-1.c | 89 +
 .../autovec/gather-scatter/strided_load-1.c   |  2 +-
 .../autovec/gather-scatter/strided_load-2.c   |  2 +-
 .../autovec/gather-scatter/strided_load-3.c   | 45 +
 .../gather-scatter/strided_load_run-3.c   | 84 
 .../autovec/gather-scatter/strided_store-1.c  |  2 +-
 .../autovec/gather-scatter/strided_store-2.c  |  2 +-
 .../autovec/gather-scatter/strided_store-3.c  | 45 +
 .../gather-scatter/strided_store_run-3.c  | 82 
 15 files changed, 628 insertions(+), 4 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_load-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_load_run-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_store-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_store_run-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/strided_store-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/strided_store_run-3.c

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 80e41af6334..e0c294ffd10 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -272,6 +272,36 @@
   DONE;
 })
 
+;; =
+;; == Strided Load/Store
+;; =
+
+(define_expand "mask_len_strided_load_"
+  [(match_operand:V 0 "register_operand")
+   (match_operand 1 "pmode_reg_or_0_operand")
+   (match_operand 2 "pmode_reg_or_0_operand")
+   (match_operand: 3 "vector_mask_operand")
+   (match_operand 4 "autovec_length_operand")
+   (match_operand 5 "const_0_operand")]
+  "TARGET_VECTOR"
+{
+  riscv_vector::expand_strided_load_store (mode, operands, true);
+  DONE;
+})
+
+(define_expand "mask_len_strided_store_"
+  [(match_operand 0 "pmode_reg_or_0_operand")
+   (match_operand 1 "pmode_reg_or_0_operand")
+   (match_operand:V 2 "register_operand")
+   (match_operand: 3 "vector_mask_operand")
+   (match_operand 4 "autovec_length_operand")
+   (match_operand 5 "const_0_operand")]
+  "TARGET_VECTOR"
+{
+  riscv_vector::expand_strided_load_store (mode, operands, false);
+  DONE;
+})
+
 ;; =
 ;; == Array Load/Store
 ;; =
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 8cdfadbcf10..3ef5740cf5b 100644
--- a/gcc/config/riscv/riscv-protos.h
+

[Commit Pending V2] RISC-V: Support strided load/store

2023-10-31 Thread Juzhe-Zhong
This patch is depending on middle-end patches which are under review.

I will commit it after middle-end patches are approved.

Consider this following case:
void foo (int * __restrict a, int * __restrict b, int stride, int n)
{
for (int i = 0; i < n; i++)
  a[i*stride] = b[i*stride] + 100;
}

Before this patch:

sllia6,a2,2
vid.v   v1
vmul.vx v1,v1,a2
vsetvli zero,zero,e64,m2,ta,ma
vsext.vf2   v4,v1
vsll.vi v4,v4,2
.L4:
vsetvli a5,a3,e32,m1,ta,ma
mul a4,a6,a5
vluxei64.v  v1,(a1),v4
sub a3,a3,a5
vadd.vv v1,v1,v2
vsuxei64.v  v1,(a0),v4
add a1,a1,a4
add a0,a0,a4
bne a3,zero,.L4
ret

After this patch:

sllia6,a2,2
mv  a4,a6
.L4:
vsetvli a5,a3,e32,m1,ta,ma
mul a2,a6,a5
vlse32.vv1,0(a1),a4
sub a3,a3,a5
vadd.vv v1,v1,v2
vsse32.vv1,0(a0),a4
add a1,a1,a2
add a0,a0,a2
bne a3,zero,.L4
ret

gcc/ChangeLog:

* config/riscv/autovec.md (mask_len_strided_load): 
New pattern.
(mask_len_strided_store): Ditto.
* config/riscv/predicates.md (vector_stride_extension_operand): New 
predicate.
* config/riscv/riscv-protos.h (expand_strided_load_store): New function.
* config/riscv/riscv-v.cc (expand_strided_load_store): Ditto.
* config/riscv/vector-iterators.md: New attribute.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-1.c: Adapt 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_store-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_store-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_load-1.c: 
New test.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_load_run-1.c: New test.
* gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_store-1.c: 
New test.
* 
gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_store_run-1.c: New 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-3.c: New 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-3.c: New 
test.
* gcc.target/riscv/rvv/autovec/gather-scatter/strided_store-3.c: New 
test.

---
 gcc/config/riscv/autovec.md   | 34 +++
 gcc/config/riscv/predicates.md|  9 ++
 gcc/config/riscv/riscv-protos.h   |  1 +
 gcc/config/riscv/riscv-v.cc   | 76 +++
 gcc/config/riscv/vector-iterators.md  |  5 +
 .../gather-scatter/mask_strided_load-1.c  | 47 +
 .../gather-scatter/mask_strided_load_run-1.c  | 97 +++
 .../gather-scatter/mask_strided_store-1.c | 48 +
 .../gather-scatter/mask_strided_store_run-1.c | 89 +
 .../autovec/gather-scatter/strided_load-1.c   |  2 +-
 .../autovec/gather-scatter/strided_load-2.c   |  2 +-
 .../autovec/gather-scatter/strided_load-3.c   | 45 +
 .../gather-scatter/strided_load_run-3.c   | 84 
 .../autovec/gather-scatter/strided_store-1.c  |  2 +-
 .../autovec/gather-scatter/strided_store-2.c  |  2 +-
 .../autovec/gather-scatter/strided_store-3.c  | 45 +
 16 files changed, 584 insertions(+), 4 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_load-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_load_run-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_store-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/mask_strided_store_run-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/strided_load-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/gather-scatter/strided_store-3.c

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index f5e3e347ace..3e4493c42cc 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -272,6 +272,40 @@
   DONE;
 })
 
+;; =
+;; == Strided Load/Store
+;; =
+
+(define_expand "mask_len_strided_load"
+  [(match_operand:V 0 "register_operand")
+   (match_operand 1 "pmode_reg_or_0_operand")
+   (match_operand:ANYI 2 "register_operand")
+   (match_operand 3 "")
+   (match_operand 4 "")
+   (match_operand: 5 "vector_mask_operand")
+   (match_

RE: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

2023-10-29 Thread Li, Pan2
Should be fixed by the below PATCH, feel free to ping me if any issues.

https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634616.html

Pan

-Original Message-
From: Andreas Schwab  
Sent: Saturday, October 28, 2023 4:16 PM
To: 钟居哲 
Cc: patrick ; gcc-patches ; 
kito.cheng ; rdapp.gcc 
Subject: Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV 
auto-vectorization

../../gcc/config/riscv/riscv-avlprop.cc: In member function 'virtual unsigned 
int pass_avlprop::execute(function*)':
../../gcc/config/riscv/riscv-avlprop.cc:346:23: error: loop variable 
'candidate' creates a copy from type 'const std::pair' [-Werror=range-loop-construct]
  346 |   for (const auto candidate : m_candidates)
  |   ^
../../gcc/config/riscv/riscv-avlprop.cc:346:23: note: use reference type to 
prevent copying
  346 |   for (const auto candidate : m_candidates)
  |   ^
  |   &

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


Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

2023-10-28 Thread Andreas Schwab
../../gcc/config/riscv/riscv-avlprop.cc: In member function 'virtual unsigned 
int pass_avlprop::execute(function*)':
../../gcc/config/riscv/riscv-avlprop.cc:346:23: error: loop variable 
'candidate' creates a copy from type 'const std::pair' [-Werror=range-loop-construct]
  346 |   for (const auto candidate : m_candidates)
  |   ^
../../gcc/config/riscv/riscv-avlprop.cc:346:23: note: use reference type to 
prevent copying
  346 |   for (const auto candidate : m_candidates)
  |   ^
  |   &

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


Re: Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

2023-10-26 Thread juzhe.zh...@rivai.ai
ossible.

Thanks.


juzhe.zh...@rivai.ai
 
From: Patrick O'Neill
Date: 2023-10-27 02:43
To: Robin Dapp; Juzhe-Zhong
CC: Kito Cheng; gcc-patches
Subject: Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV 
auto-vectorization
On 10/26/23 11:15, Robin Dapp wrote:
rv32gcv:
FAIL: gfortran.dg/intrinsic_pack_6.f90   -O2  execution test
FAIL: gfortran.dg/intrinsic_pack_6.f90   -O3 -g  execution test
FAIL: gfortran.dg/matmul_3.f90   -O2  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2 
-fbounds-check
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2 
-fomit-frame-pointer -finline-functions
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O3 -g
rv64gcv:
FAIL: gfortran.dg/matmul_6.f90   -O2  execution test
Those might also flip flop, I have them seen FAIL and PASS before
randomly.  It looks like there is at least 10 of those, really need
to figure out the root cause...
Regards
 Robin
I've seen the same thing on CI for some of these failures on rv32gcv but always 
as a group:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111969
Example CI run with the flaky group:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/75
The fact that some are resolved while not resolving the full group makes me 
hopeful that:
FAIL: gfortran.dg/intrinsic_pack_6.f90  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution
are really resolved
I haven't seen these testcases be flaky on CI:
FAIL: gfortran.dg/matmul_3.f90   -O2  execution test
FAIL: gfortran.dg/matmul_6.f90   -O2  execution test
Patrick



Re: Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

2023-10-26 Thread 钟居哲
Thanks Patrick. Committed.



juzhe.zh...@rivai.ai
 
From: Patrick O'Neill
Date: 2023-10-27 02:12
To: Juzhe-Zhong; gcc-patches
CC: Kito Cheng; Robin Dapp
Subject: Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV 
auto-vectorization
popcount and mask_gather_load_run fails seem to be an issue with my setup or a 
bug with QEMU based on the v2 discussion :-)

OK with me regarding testing (I don't have the authority to approve a patch, 
but Kito already said LGTM):
https://inbox.sourceware.org/gcc-patches/CALLt3ThXmk4pey2QhSUvK183uuK3oY5bU=a4m8qyv-6uukb...@mail.gmail.com/

Thanks for your patience and the revisions!

Your patch resolves these failures on glibc qemu:

rv32gcv:
FAIL: gfortran.dg/intrinsic_pack_6.f90   -O2  execution test
FAIL: gfortran.dg/intrinsic_pack_6.f90   -O3 -g  execution test
FAIL: gfortran.dg/matmul_3.f90   -O2  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2 
-fbounds-check
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2 
-fomit-frame-pointer -finline-functions
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O3 -g

rv64gcv:
FAIL: gfortran.dg/matmul_6.f90   -O2  execution test

Tested-by: Patrick O'Neill 

Patrick
On 10/26/23 01:13, Juzhe-Zhong wrote:
This patch addresses the redundant AVL/VL toggling in RVV partial 
auto-vectorization
which is a known issue for a long time and I finally find the time to address 
it.
Consider a simple vector addition operation:
https://godbolt.org/z/7hfGfEjW3
void
foo (int *__restrict a,
 int *__restrict b,
 int *__restrict n)
{
  for (int i = 0; i < n; i++)
  a[i] = a[i] + b[i];
}
Optimized IR:
Loop body:
  _38 = .SELECT_VL (ivtmp_36, POLY_INT_CST [4, 4]);  -> 
vsetvli a5,a2,e8,mf4,ta,ma
  ...
  vect__4.8_27 = .MASK_LEN_LOAD (vectp_a.6_29, 32B, { -1, ... }, _38, 0);-> 
vle32.v v2,0(a0)
  vect__6.11_20 = .MASK_LEN_LOAD (vectp_b.9_25, 32B, { -1, ... }, _38, 0);   -> 
vle32.v v1,0(a1)
  vect__7.12_19 = vect__6.11_20 + vect__4.8_27;  -> 
vsetvli a6,zero,e32,m1,ta,ma + vadd.vv v1,v1,v2
  .MASK_LEN_STORE (vectp_a.13_11, 32B, { -1, ... }, _38, 0, vect__7.12_19);  -> 
vsetvli zero,a5,e32,m1,ta,ma + vse32.v v1,0(a4)
We can see 2 redundant vsetvls inside the loop body due to AVL/VL toggling.
The AVL/VL toggling is because we are missing LEN information in simple 
PLUS_EXPR GIMPLE assignment:
vect__7.12_19 = vect__6.11_20 + vect__4.8_27;
GCC apply partial predicate load/store and un-predicated full vector operation 
on partial vectorization.
Such flow are used by all other targets like ARM SVE (RVV also uses such flow):
ARM SVE:
   
.L3:
ld1wz30.s, p7/z, [x0, x3, lsl 2]   -> predicated load
ld1wz31.s, p7/z, [x1, x3, lsl 2]   -> predicated load
add z31.s, z31.s, z30.s-> un-predicated add
st1wz31.s, p7, [x0, x3, lsl 2] -> predicated store
Such vectorization flow causes AVL/VL toggling on RVV so we need AVL 
propagation PASS for it.
Also, It's very unlikely that we can apply predicated operations on all 
vectorization for following reasons:
1. It's very heavy workload to support them on all vectorization and we don't 
see any benefits if we can handle that on targets backend.
2. Changing Loop vectorizer for it will make code base ugly and hard to 
maintain.
3. We will need so many patterns for all operations. Not only COND_LEN_ADD, 
COND_LEN_SUB, 
   We also need COND_LEN_EXTEND, , COND_LEN_CEIL, ... .. over 100+ 
patterns, unreasonable number of patterns.
To conclude, we prefer un-predicated operations here, and design a nice and 
clean AVL propagation PASS for it to elide the redundant vsetvls
due to AVL/VL toggling.
The second question is that why we separate a PASS called AVL propagation. Why 
not optimize it in VSETVL PASS (We definitetly can optimize AVL in VSETVL PASS)
Frankly, I was planning to address such issue in VSETVL PASS that's why we 
recently refactored VSETVL PASS. However, I changed my mind recently after 
several
experiments and tries.
The reasons as follows:
1. For code base management and maintainience. Current VSETVL PASS is 
complicated enough and aleady has enough aggressive and fancy optimizations 
which
   turns out it can always generate optimal codegen in most of the cases. It's 
not a good idea keep adding more features into VSETVL PASS to make VSETVL
 PASS become heavy and heavy again, then we will need to refactor it 
again in the future.
 Actuall, the VSETVL PASS is very stable and optimal after the recent 
refactoring. Hopefully, we should not change VSETVL PASS any more except the 
minor
 fixes.
2. vsetvl insertion (VSETVL PASS does this thing) and AVL propagation are 2 
different things,  I don't think we should fuse them into same PASS.
3. VSETVL PASS 

Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

2023-10-26 Thread Patrick O'Neill

On 10/26/23 11:15, Robin Dapp wrote:


rv32gcv:
FAIL: gfortran.dg/intrinsic_pack_6.f90   -O2  execution test
FAIL: gfortran.dg/intrinsic_pack_6.f90   -O3 -g  execution test
FAIL: gfortran.dg/matmul_3.f90   -O2  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2 
-fbounds-check
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2 
-fomit-frame-pointer -finline-functions
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O3 -g

rv64gcv:
FAIL: gfortran.dg/matmul_6.f90   -O2  execution test

Those might also flip flop, I have them seen FAIL and PASS before
randomly.  It looks like there is at least 10 of those, really need
to figure out the root cause...

Regards
  Robin


I've seen the same thing on CI for some of these failures on rv32gcv but always 
as a group:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111969

Example CI run with the flaky group:
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/75

The fact that some are resolved while not resolving the full group makes me 
hopeful that:
FAIL: gfortran.dg/intrinsic_pack_6.f90  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution
are really resolved

I haven't seen these testcases be flaky on CI:
FAIL: gfortran.dg/matmul_3.f90   -O2  execution test
FAIL: gfortran.dg/matmul_6.f90   -O2  execution test

Patrick


Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

2023-10-26 Thread Robin Dapp
> rv32gcv:
> FAIL: gfortran.dg/intrinsic_pack_6.f90   -O2  execution test
> FAIL: gfortran.dg/intrinsic_pack_6.f90   -O3 -g  execution test
> FAIL: gfortran.dg/matmul_3.f90   -O2  execution test
> FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2
> FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2 
> -fbounds-check
> FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2 
> -fomit-frame-pointer -finline-functions
> FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O3 -g
> 
> rv64gcv:
> FAIL: gfortran.dg/matmul_6.f90   -O2  execution test

Those might also flip flop, I have them seen FAIL and PASS before
randomly.  It looks like there is at least 10 of those, really need
to figure out the root cause...

Regards
 Robin


Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

2023-10-26 Thread Patrick O'Neill
popcount and mask_gather_load_run fails seem to be an issue with my 
setup or a bug with QEMU based on the v2 discussion :-)


OK with me regarding testing (I don't have the authority to approve a 
patch, but Kito already said LGTM):

https://inbox.sourceware.org/gcc-patches/CALLt3ThXmk4pey2QhSUvK183uuK3oY5bU=a4m8qyv-6uukb...@mail.gmail.com/

Thanks for your patience and the revisions!

Your patch resolves these failures on glibc qemu:

rv32gcv:
FAIL: gfortran.dg/intrinsic_pack_6.f90   -O2  execution test
FAIL: gfortran.dg/intrinsic_pack_6.f90   -O3 -g  execution test
FAIL: gfortran.dg/matmul_3.f90   -O2  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  
-O2 -fbounds-check
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  
-O2 -fomit-frame-pointer -finline-functions
FAIL: gfortran.fortran-torture/execute/intrinsic_matmul.f90 execution,  
-O3 -g


rv64gcv:
FAIL: gfortran.dg/matmul_6.f90   -O2  execution test

Tested-by: Patrick O'Neill 

Patrick

On 10/26/23 01:13, Juzhe-Zhong wrote:

This patch addresses the redundant AVL/VL toggling in RVV partial 
auto-vectorization
which is a known issue for a long time and I finally find the time to address 
it.

Consider a simple vector addition operation:

https://godbolt.org/z/7hfGfEjW3

void
foo (int *__restrict a,
  int *__restrict b,
  int *__restrict n)
{
   for (int i = 0; i < n; i++)
   a[i] = a[i] + b[i];
}

Optimized IR:

Loop body:
   _38 = .SELECT_VL (ivtmp_36, POLY_INT_CST [4, 4]);  
-> vsetvli a5,a2,e8,mf4,ta,ma
   ...
   vect__4.8_27 = .MASK_LEN_LOAD (vectp_a.6_29, 32B, { -1, ... }, _38, 0);
-> vle32.v v2,0(a0)
   vect__6.11_20 = .MASK_LEN_LOAD (vectp_b.9_25, 32B, { -1, ... }, _38, 0);   
-> vle32.v v1,0(a1)
   vect__7.12_19 = vect__6.11_20 + vect__4.8_27;  
-> vsetvli a6,zero,e32,m1,ta,ma + vadd.vv v1,v1,v2
   .MASK_LEN_STORE (vectp_a.13_11, 32B, { -1, ... }, _38, 0, vect__7.12_19);  
-> vsetvli zero,a5,e32,m1,ta,ma + vse32.v v1,0(a4)

We can see 2 redundant vsetvls inside the loop body due to AVL/VL toggling.
The AVL/VL toggling is because we are missing LEN information in simple 
PLUS_EXPR GIMPLE assignment:

vect__7.12_19 = vect__6.11_20 + vect__4.8_27;

GCC apply partial predicate load/store and un-predicated full vector operation 
on partial vectorization.
Such flow are used by all other targets like ARM SVE (RVV also uses such flow):

ARM SVE:

.L3:

 ld1wz30.s, p7/z, [x0, x3, lsl 2]   -> predicated load
 ld1wz31.s, p7/z, [x1, x3, lsl 2]   -> predicated load
 add z31.s, z31.s, z30.s-> un-predicated add
 st1wz31.s, p7, [x0, x3, lsl 2] -> predicated store

Such vectorization flow causes AVL/VL toggling on RVV so we need AVL 
propagation PASS for it.

Also, It's very unlikely that we can apply predicated operations on all 
vectorization for following reasons:

1. It's very heavy workload to support them on all vectorization and we don't 
see any benefits if we can handle that on targets backend.
2. Changing Loop vectorizer for it will make code base ugly and hard to 
maintain.
3. We will need so many patterns for all operations. Not only COND_LEN_ADD, 
COND_LEN_SUB, 
We also need COND_LEN_EXTEND, , COND_LEN_CEIL, ... .. over 100+ 
patterns, unreasonable number of patterns.

To conclude, we prefer un-predicated operations here, and design a nice and 
clean AVL propagation PASS for it to elide the redundant vsetvls
due to AVL/VL toggling.

The second question is that why we separate a PASS called AVL propagation. Why 
not optimize it in VSETVL PASS (We definitetly can optimize AVL in VSETVL PASS)

Frankly, I was planning to address such issue in VSETVL PASS that's why we 
recently refactored VSETVL PASS. However, I changed my mind recently after 
several
experiments and tries.

The reasons as follows:

1. For code base management and maintainience. Current VSETVL PASS is 
complicated enough and aleady has enough aggressive and fancy optimizations 
which
turns out it can always generate optimal codegen in most of the cases. It's 
not a good idea keep adding more features into VSETVL PASS to make VSETVL
 PASS become heavy and heavy again, then we will need to refactor it 
again in the future.
 Actuall, the VSETVL PASS is very stable and optimal after the recent 
refactoring. Hopefully, we should not change VSETVL PASS any more except the 
minor
 fixes.

2. vsetvl insertion (VSETVL PASS does this thing) and AVL propagation are 2 
different things,  I don't think we should fuse them into same PASS.

3. VSETVL PASS is an post-RA PASS, wheras AVL propagtion should be done before 
RA which can reduce register allocation.

4. This patch's AVL propagation PASS only does AVL propagation for RVV partial 
auto-vectorization situations.
This patch's 

[Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

2023-10-26 Thread Juzhe-Zhong
This patch addresses the redundant AVL/VL toggling in RVV partial 
auto-vectorization
which is a known issue for a long time and I finally find the time to address 
it.

Consider a simple vector addition operation:

https://godbolt.org/z/7hfGfEjW3

void
foo (int *__restrict a,
 int *__restrict b,
 int *__restrict n)
{
  for (int i = 0; i < n; i++)
  a[i] = a[i] + b[i];
}

Optimized IR:

Loop body:
  _38 = .SELECT_VL (ivtmp_36, POLY_INT_CST [4, 4]);  -> 
vsetvli a5,a2,e8,mf4,ta,ma
  ...
  vect__4.8_27 = .MASK_LEN_LOAD (vectp_a.6_29, 32B, { -1, ... }, _38, 0);-> 
vle32.v v2,0(a0)
  vect__6.11_20 = .MASK_LEN_LOAD (vectp_b.9_25, 32B, { -1, ... }, _38, 0);   -> 
vle32.v v1,0(a1)
  vect__7.12_19 = vect__6.11_20 + vect__4.8_27;  -> 
vsetvli a6,zero,e32,m1,ta,ma + vadd.vv v1,v1,v2
  .MASK_LEN_STORE (vectp_a.13_11, 32B, { -1, ... }, _38, 0, vect__7.12_19);  -> 
vsetvli zero,a5,e32,m1,ta,ma + vse32.v v1,0(a4)

We can see 2 redundant vsetvls inside the loop body due to AVL/VL toggling.
The AVL/VL toggling is because we are missing LEN information in simple 
PLUS_EXPR GIMPLE assignment:

vect__7.12_19 = vect__6.11_20 + vect__4.8_27;

GCC apply partial predicate load/store and un-predicated full vector operation 
on partial vectorization.
Such flow are used by all other targets like ARM SVE (RVV also uses such flow):

ARM SVE:
   
.L3:
ld1wz30.s, p7/z, [x0, x3, lsl 2]   -> predicated load
ld1wz31.s, p7/z, [x1, x3, lsl 2]   -> predicated load
add z31.s, z31.s, z30.s-> un-predicated add
st1wz31.s, p7, [x0, x3, lsl 2] -> predicated store

Such vectorization flow causes AVL/VL toggling on RVV so we need AVL 
propagation PASS for it.

Also, It's very unlikely that we can apply predicated operations on all 
vectorization for following reasons:

1. It's very heavy workload to support them on all vectorization and we don't 
see any benefits if we can handle that on targets backend.
2. Changing Loop vectorizer for it will make code base ugly and hard to 
maintain.
3. We will need so many patterns for all operations. Not only COND_LEN_ADD, 
COND_LEN_SUB, 
   We also need COND_LEN_EXTEND, , COND_LEN_CEIL, ... .. over 100+ 
patterns, unreasonable number of patterns.

To conclude, we prefer un-predicated operations here, and design a nice and 
clean AVL propagation PASS for it to elide the redundant vsetvls
due to AVL/VL toggling.

The second question is that why we separate a PASS called AVL propagation. Why 
not optimize it in VSETVL PASS (We definitetly can optimize AVL in VSETVL PASS)

Frankly, I was planning to address such issue in VSETVL PASS that's why we 
recently refactored VSETVL PASS. However, I changed my mind recently after 
several
experiments and tries.

The reasons as follows:

1. For code base management and maintainience. Current VSETVL PASS is 
complicated enough and aleady has enough aggressive and fancy optimizations 
which
   turns out it can always generate optimal codegen in most of the cases. It's 
not a good idea keep adding more features into VSETVL PASS to make VSETVL
 PASS become heavy and heavy again, then we will need to refactor it 
again in the future.
 Actuall, the VSETVL PASS is very stable and optimal after the recent 
refactoring. Hopefully, we should not change VSETVL PASS any more except the 
minor
 fixes.

2. vsetvl insertion (VSETVL PASS does this thing) and AVL propagation are 2 
different things,  I don't think we should fuse them into same PASS.

3. VSETVL PASS is an post-RA PASS, wheras AVL propagtion should be done before 
RA which can reduce register allocation.

4. This patch's AVL propagation PASS only does AVL propagation for RVV partial 
auto-vectorization situations.
   This patch's codes are only hundreds lines which is very managable and can 
be very easily extended features and enhancements.
 We can easily extend and enhance more AVL propagation in a clean and 
separate PASS in the future. (If we do it on VSETVL PASS, we will complicate 
 VSETVL PASS again which is already so complicated.) 

Here is an example to demonstrate more:

https://godbolt.org/z/bE86sv3q5

void foo2 (int *__restrict a,
  int *__restrict b,
  int *__restrict c,
  int *__restrict a2,
  int *__restrict b2,
  int *__restrict c2,
  int *__restrict a3,
  int *__restrict b3,
  int *__restrict c3,
  int *__restrict a4,
  int *__restrict b4,
  int *__restrict c4,
  int *__restrict a5,
  int *__restrict b5,
  int *__restrict c5,
  int n)
{
for (int i = 0; i < n; i++){
  a[i] = b[i] + c[i];
  b5[i] = b[i] + c[i];
  a2[i] = b2[i] + c2[i];
  a3[i] = b3[i] + c3[i];
  a4[i] = b4[i] + c4[i];
  a5[i] = a[i] + a4[i];
  a[i] = a5[i] + b5[i]+ a[i];

  a[i] = a[i] + c[i];
  b5[i] = a[i] + 

[committed] Update contrib + libgomp ChangeLogs for failed reject-commit testing (was: [Patch] contrib/gcc-changelog: Check whether revert-commit exists)

2023-09-08 Thread Tobias Burnus

On 07.09.23 11:38, Jakub Jelinek wrote:

On Thu, Sep 07, 2023 at 11:30:53AM +0200, Tobias Burnus wrote:

contrib/gcc-changelog: Check whether revert-commit exists
...

I think not should precede technically (or should we just drop technically)?


'technically' has been dropped (twice), based on the IRC discussion (in
the original commit and in a follow-up fixing commit as the re-commit
patch missed it).

Otherwise, the patch has been applied - but we did struggle with getting
it copied over to the right location on the server + getting it to work.

Last status: The check does work locally but did not for "git push"; in
principle, it should also work on the server but it failed when last
tested. While several directories on the server have now the new script,
it is unclear whether the (or all the) relevant one(s) have it and
whether the script itself is fine or not.

In any case, attached is the commit that rectifies the ChangeLog files
and also lists in the log-message part what the related commits did and
didn't do.

Committed as r14-3806-g478c37e7234530 - after the "Daily Bump", which
also required the same temporary work around as for the original issue.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 478c37e72345307fad0aa06e0dae133eae206b0c
Author: Tobias Burnus 
Date:   Fri Sep 8 12:02:02 2023 +0200

Update contrib + libgomp ChangeLogs for failed reject-commit testing
    
The following commit should have enabled checking for invalid revert hashes;
it worked locally - but did work as pre-commit hook on sourceware
as it wasn't copied to the hook directory:
r14-3777-gff20bce9f58 contrib/gcc-changelog: Check whether revert-commit exists

Hence, the following revert commit was wrongly applied:
r14-3778-gfbbd9001e9b Revert "contrib/gcc-changelog: Check whether revert-commit exists"
(In this commit: contrib/ChangeLog update for the revert.)

r14-3779-g69e83181ebc contrib/gcc-changelog: Check whether revert-commit exists
    Re-applied the commit with a commit-log typo fixed but missing a late commit.

r14-3780-g1b0934b7276 Revert "contrib/gcc-changelog: Check whether revert-commit exists"
This commit still came through but re-instated the late wording fix in
contrib/gcc-changelog/git_commit.py.
(In this commit: contrib/ChangeLog update for the wording change.)

r14-3781-gd22cd7745ff Revert: "Another revert test with a bogus hash"
Another attempt to get a reject, but it still came through.
It removed tailing whitespace in libgomp/target.c
(In this commit: libgomp/ChangeLog was for the whitespace removal.)

diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index e49bbe30446..403a095512c 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2023-09-07  Tobias Burnus  
+
+	* gcc-changelog/git_commit.py (GitCommit.__init__,
+	to_changelog_entries): Fix lost wording fix.
+
 2023-09-07  Tobias Burnus  
 
 	* gcc-changelog/git_commit.py (GitCommit.__init__):
@@ -9,6 +14,20 @@
 	call super() with commit_to_info_hook=None instead
 	of a lambda function.
 
+2023-09-07  Tobias Burnus  
+
+	Revert:
+	2023-09-07  Tobias Burnus  
+
+	* gcc-changelog/git_commit.py (GitCommit.__init__):
+	Handle commit_to_info_hook = None; otherwise, if None,
+	regard it as error.
+	(to_changelog_entries): Handle commit_to_info_hook = None;
+	if info is None, create a warning for it.
+	* gcc-changelog/git_email.py (GitEmail.__init__):
+	call super() with commit_to_info_hook=None instead
+	of a lamda function.
+
 2023-09-07  Tobias Burnus  
 
 	* gcc-changelog/git_commit.py (GitCommit.__init__):
diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index dbd5e4fc4ee..fb96155394e 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -5,6 +5,10 @@
 	omp_get_default_allocator.
 	(OMP_ALLOCATOR): Fix ICV var name; add see-also references.
 
+2023-09-07  Tobias Burnus  
+
+	* target.c (gomp_unload_device): Remove tailing whitespace.
+
 2023-09-04  Tobias Burnus  
 	Thomas Schwinge  
 


Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-08 Thread Jakub Jelinek via Gcc-patches
On Fri, Sep 08, 2023 at 10:25:42AM +0200, Christophe Lyon wrote:
> Revert "libstdc++: Use GLIBCXX_CHECK_LINKER_FEATURES for cross-builds
> (PR111238)"
> 
> diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
> index 8f7b01e0563..0c60149d7f6 100644
> --- a/libstdc++-v3/ChangeLog
> +++ b/libstdc++-v3/ChangeLog
> @@ -4,6 +4,16 @@
> for freestanding.
> * configure: Regenerate.
> 
> +2023-09-04  Christophe Lyon  
> +
> +   Revert
> +   2023-09-04  Christophe Lyon  
> +
> +   PR libstdc++/111238
> +   * configure: Regenerate.
> +   * configure.ac: Call GLIBCXX_CHECK_LINKER_FEATURES in cross,
> +   non-Canadian builds.
> +
>  2023-09-04  Christophe Lyon  
> 
> PR libstdc++/111238
> 
> I inserted my "Revert"  ChangeLog entry between the entry I want to declare
> reverted and Jonathan's more recent patch about GLIBCXX_ENABLE_BACKTRACE.
> Is that OK for the commit hooks?

Yes, thanks.

Jakub



Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-08 Thread Christophe Lyon via Gcc-patches
On Thu, 7 Sept 2023 at 11:45, Jakub Jelinek  wrote:

> On Thu, Sep 07, 2023 at 10:20:19AM +0200, Christophe Lyon via Gcc-patches
> wrote:
> > On Tue, 5 Sept 2023 at 16:38, Tobias Burnus 
> wrote:
> >
> > > That's based on the fail
> > > https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
> > > and on the discussion on IRC.
> > >
> >
> > Sorry I didn't notice the problem, nor the discussion on IRC, but I can
> see
> > that my commits created the problem, sorry for that.
> >
> > I'm not sure how your patch would have prevented me from doing this?
> > What happened is that I had 3 patches on top of master
> > - HEAD: the one I wanted to push
> > - HEAD-1: revert of HEAD-2
>
> git reset HEAD^
> instead of committing a revert would be better I think.
>

The patch I reverted locally was still under discussion, so I wanted to
keep it around until we made a decision.
But yeah.


> > - HEAD-2:  libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch
> >
> > I had actually forgotten about HEAD-1 and HEAD-2, HEAD was unrelated to
> > those, so when I pushed, I pushed 3 commits while I thought there was
> only
> > one.
> > I did run contrib/gcc-changelog/git_check_commit.py (I realize I'm not
> sure
> > whether I used git_check_commit.py or git_commit.py), but only on HEAD
> > since I had forgotten about the other two.
>
> Could you please remove your
> 2023-09-04  Christophe Lyon  
>
> PR libstdc++/111238
> * configure: Regenerate.
> * configure.ac: Call GLIBCXX_CHECK_LINKER_FEATURES in cross,
> non-Canadian builds.
> libstdc++-v3/ChangeLog entry if that commit is indeed not in (or add
> a Revert: entry for it right after it if you think it needs to be in)?
> That is a part I haven't done, my/Arsen's hacks to make the version update
> get through basically ignored that revert commit.
>
> ChangeLog files can be changed by commits which only touch ChangeLog files
> and nothing else (ok, date stamp too, but please don't update that), no
> ChangeLog in the message needs to be provided for such changes.
>

Like so:
 commit d2bb261dbf282bbb258e1e5f17c1b6230327e076 (HEAD -> master)
Author: Christophe Lyon 
Date:   Fri Sep 8 08:13:32 2023 +

Revert "libstdc++: Use GLIBCXX_CHECK_LINKER_FEATURES for cross-builds
(PR111238)"

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 8f7b01e0563..0c60149d7f6 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -4,6 +4,16 @@
for freestanding.
* configure: Regenerate.

+2023-09-04  Christophe Lyon  
+
+   Revert
+   2023-09-04  Christophe Lyon  
+
+   PR libstdc++/111238
+   * configure: Regenerate.
+   * configure.ac: Call GLIBCXX_CHECK_LINKER_FEATURES in cross,
+   non-Canadian builds.
+
 2023-09-04  Christophe Lyon  

PR libstdc++/111238

I inserted my "Revert"  ChangeLog entry between the entry I want to declare
reverted and Jonathan's more recent patch about GLIBCXX_ENABLE_BACKTRACE.
Is that OK for the commit hooks?


Jakub
>
>


Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-07 Thread Jakub Jelinek via Gcc-patches
On Thu, Sep 07, 2023 at 10:20:19AM +0200, Christophe Lyon via Gcc-patches wrote:
> On Tue, 5 Sept 2023 at 16:38, Tobias Burnus  wrote:
> 
> > That's based on the fail
> > https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
> > and on the discussion on IRC.
> >
> 
> Sorry I didn't notice the problem, nor the discussion on IRC, but I can see
> that my commits created the problem, sorry for that.
> 
> I'm not sure how your patch would have prevented me from doing this?
> What happened is that I had 3 patches on top of master
> - HEAD: the one I wanted to push
> - HEAD-1: revert of HEAD-2

git reset HEAD^
instead of committing a revert would be better I think.

> - HEAD-2:  libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch
> 
> I had actually forgotten about HEAD-1 and HEAD-2, HEAD was unrelated to
> those, so when I pushed, I pushed 3 commits while I thought there was only
> one.
> I did run contrib/gcc-changelog/git_check_commit.py (I realize I'm not sure
> whether I used git_check_commit.py or git_commit.py), but only on HEAD
> since I had forgotten about the other two.

Could you please remove your
2023-09-04  Christophe Lyon  

PR libstdc++/111238
* configure: Regenerate.
* configure.ac: Call GLIBCXX_CHECK_LINKER_FEATURES in cross,
non-Canadian builds.
libstdc++-v3/ChangeLog entry if that commit is indeed not in (or add
a Revert: entry for it right after it if you think it needs to be in)?
That is a part I haven't done, my/Arsen's hacks to make the version update
get through basically ignored that revert commit.

ChangeLog files can be changed by commits which only touch ChangeLog files
and nothing else (ok, date stamp too, but please don't update that), no
ChangeLog in the message needs to be provided for such changes.

Jakub



Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-07 Thread Jakub Jelinek via Gcc-patches
On Thu, Sep 07, 2023 at 11:30:53AM +0200, Tobias Burnus wrote:
> contrib/gcc-changelog: Check whether revert-commit exists
> 
> contrib/ChangeLog:
> 
>   * gcc-changelog/git_commit.py (GitCommit.__init__):
>   Handle commit_to_info_hook = None; otherwise, if None,
>   regard it as error.
>   (to_changelog_entries): Handle commit_to_info_hook = None;
>   if info is None, create a warning for it.
>   * gcc-changelog/git_email.py (GitEmail.__init__):
>   call super() with commit_to_info_hook=None instead
>   of a lamda function.
> 
>  contrib/gcc-changelog/git_commit.py | 20 +++-
>  contrib/gcc-changelog/git_email.py  |  3 +--
>  2 files changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/contrib/gcc-changelog/git_commit.py 
> b/contrib/gcc-changelog/git_commit.py
> index 4f3131021f2..4f1bd4d7293 100755
> --- a/contrib/gcc-changelog/git_commit.py
> +++ b/contrib/gcc-changelog/git_commit.py
> @@ -329,11 +329,15 @@ class GitCommit:
>  self.revert_commit = m.group('hash')
>  break
>  if self.revert_commit:
> +# The following happens for get_email.py:
> +if not self.commit_to_info_hook:
> +self.warnings.append(f"Invoked script can technically not 
> obtain info about "
> + f"reverted commits such as 
> '{self.revert_commit}'")

I think not should precede technically (or should we just drop technically)?

> +self.warnings.append(f"Invoked script can 
> technically not obtain info about "
> + f"cherry-picked commits such as 
> '{self.revert_commit}'")

Likewise.

>  timestamp = current_timestamp
>  elif not timestamp or use_commit_ts:
>  timestamp = current_timestamp
> diff --git a/contrib/gcc-changelog/git_email.py 
> b/contrib/gcc-changelog/git_email.py
> index 49f41f2ec99..93808dfabb6 100755
> --- a/contrib/gcc-changelog/git_email.py
> +++ b/contrib/gcc-changelog/git_email.py
> @@ -89,8 +89,7 @@ class GitEmail(GitCommit):
>  t = 'M'
>  modified_files.append((target if t != 'D' else source, t))
>  git_info = GitInfo(None, date, author, message, modified_files)
> -super().__init__(git_info,
> - commit_to_info_hook=lambda x: None)
> +super().__init__(git_info, commit_to_info_hook=None)
>  
>  
>  def show_help():

Otherwise LGTM, but it would be good after committing it try to commit
reversion commit of some non-existent hash (willing to handle ChangeLog
manually again if it makes it through).

Jakub



Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-07 Thread Tobias Burnus

First: Hi all,

attached is an updated patch (v3) where I changed the wording
of the warning to distinguish technical reasons for not using
the commit data (→ git_email.py) from not-found lookups (git_check_commit.py)
to avoid confusion. (See also below.)

Any remarks/suggestions - related to this (e.g. wording improvements or ...)
or to the patch in general?

Hi Christoph,

On 07.09.23 10:20, Christophe Lyon wrote:


On Tue, 5 Sept 2023 at 16:38, Tobias Burnus 
wrote:

That's based on the fail
https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
and on the discussion on IRC.


Sorry I didn't notice the problem, nor the discussion on IRC, but I
can see that my commits created the problem, sorry for that.


Well, as the saying goes: you can't make an omelette without breaking eggs.

And there were three issues: The invalid reference, the missing check
for the former, and that it caused the nightly script to break.

While we cannot prevent human errors (nor KI ones) and have fixed/worked
around the latter, we can improve on the checking part :-)


I'm not sure how your patch would have prevented me from doing this?


There are two checking scripts:

One for manual running on a file produced by 'git format-patch', which is
  ./contrib/gcc-changelog/git_email.py

Before it crashed for the revert, now it prints OK with the warning:
  Cannot obtain info about reverted commit 
'46c2e94ca66ed9991c45a6ba6204ed02869efc39'
re-reading it, I think the wording is wrong. It should be:
  Invoked script cannot obtain info about reverted commits such as 
'46c2e94ca66ed9991c45a6ba6204ed02869efc39'
as that's a generic limitation - we simply do not know whether
that commit exists or not. (Changed in the attached patch.)


And the other operates on the git repository:
  ./contrib/gcc-changelog/git_check_commit.py
the latter now fails with:
  ERR: Cannot find to-be-reverted commit: 
"46c2e94ca66ed9991c45a6ba6204ed02869efc39"

That script can be run manually on any commit (e.g. before the commit;
consider using the '-v' and/or '-p' options; see '--help').

But that script is also run on the GCC server as pre-commit hook.

Therefore, the latter would have rejected your commit with the error message
during "git push", permitting to fix the commit (git commit --amend) before
trying again, similar to missing '\t' in the changelog or ...

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
contrib/gcc-changelog: Check whether revert-commit exists

contrib/ChangeLog:

	* gcc-changelog/git_commit.py (GitCommit.__init__):
	Handle commit_to_info_hook = None; otherwise, if None,
	regard it as error.
	(to_changelog_entries): Handle commit_to_info_hook = None;
	if info is None, create a warning for it.
	* gcc-changelog/git_email.py (GitEmail.__init__):
	call super() with commit_to_info_hook=None instead
	of a lamda function.

 contrib/gcc-changelog/git_commit.py | 20 +++-
 contrib/gcc-changelog/git_email.py  |  3 +--
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 4f3131021f2..4f1bd4d7293 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -329,11 +329,15 @@ class GitCommit:
 self.revert_commit = m.group('hash')
 break
 if self.revert_commit:
+# The following happens for get_email.py:
+if not self.commit_to_info_hook:
+self.warnings.append(f"Invoked script can technically not obtain info about "
+ f"reverted commits such as '{self.revert_commit}'")
+return
 self.info = self.commit_to_info_hook(self.revert_commit)
-
-# The following happens for get_email.py:
-if not self.info:
-return
+if not self.info:
+self.errors.append(Error('Cannot find to-be-reverted commit', self.revert_commit))
+return
 
 self.check_commit_email()
 
@@ -796,12 +800,18 @@ class GitCommit:
 orig_date = self.original_info.date
 current_timestamp = orig_date.strftime(DATE_FORMAT)
 elif self.cherry_pick_commit:
-info = self.commit_to_info_hook(self.cherry_pick_commit)
+info = (self.commit_to_info_hook
+and self.commit_to_info_hook(self.cherry_pick_commit))
 # it can happen that it is a cherry-pick for a different
 # repository
 if info:
 timestamp = info.date.strftime(DATE_FORMAT)
 else:
+if self.commit_to_info_hook:
+  

Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-07 Thread Christophe Lyon via Gcc-patches
Hi!

On Tue, 5 Sept 2023 at 16:38, Tobias Burnus  wrote:

> That's based on the fail
> https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
> and on the discussion on IRC.
>

Sorry I didn't notice the problem, nor the discussion on IRC, but I can see
that my commits created the problem, sorry for that.

I'm not sure how your patch would have prevented me from doing this?
What happened is that I had 3 patches on top of master
- HEAD: the one I wanted to push
- HEAD-1: revert of HEAD-2
- HEAD-2:  libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch

I had actually forgotten about HEAD-1 and HEAD-2, HEAD was unrelated to
those, so when I pushed, I pushed 3 commits while I thought there was only
one.
I did run contrib/gcc-changelog/git_check_commit.py (I realize I'm not sure
whether I used git_check_commit.py or git_commit.py), but only on HEAD
since I had forgotten about the other two.

Are these scripts executed by the commit hooks too? (and thus they would
now warn?)

Thanks,

Christophe


> The problem in for the cron job was that
> r14-3661-g084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
> referenced a commit that did not exist.
>
> This was temporarily fixed by Jakub, but it makes sense to detect this
> in the pre-commit hook.
>
>
> With the patch,
>contrib/gcc-changelog/git_email.py
> 0001-Revert-libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch
> now prints:
> OK
> Warnings:
> Cannot obtain info about reverted commit
> '46c2e94ca66ed9991c45a6ba6204ed02869efc39'
>
> while
>contrib/gcc-changelog/git_check_commit.py
> 084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
> now fails with:
>Checking 084a7cf9fb2d9cb98dfbe7d91602c840ec50b002: FAILED
>ERR: Cannot find to-be-reverted commit:
> "46c2e94ca66ed9991c45a6ba6204ed02869efc39"
>
> (check_email.py always shows the warning, git_check_commit.py only with
> '-v')
>
> Notes:
> - I am not sure whether a sensible testcase can be added - and, hence, I
> have not added one.
> - I have run "pytest-3' but my python is too old and thus might miss some
> checks which
>newer pytest/flake8 will find. But at least it did pass here.
> - I have not tested the cherry-pick + commit does not exist case,
>which now creates a warning as I did not quickly find a testcase.
>
> Comments, remarks, suggestions, approval?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
> Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
> Registergericht München, HRB 106955
>


Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-05 Thread Arsen Arsenović via Gcc-patches

Tobias Burnus  writes:

> Attached an old patch. See attached patch for the current one.
>
> Difference is one line: the warning that is shown in the example output
> below.

Python-wise, the changes seem fine.  Unsure if it does the right thing,
though, since I'm not familiar with the full script.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature


Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-05 Thread Tobias Burnus

Attached an old patch. See attached patch for the current one.

Difference is one line: the warning that is shown in the example output
below.

On 05.09.23 16:37, Tobias Burnus wrote:

That's based on the fail
https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
and on the discussion on IRC.

The problem in for the cron job was that
r14-3661-g084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
referenced a commit that did not exist.

This was temporarily fixed by Jakub, but it makes sense to detect this
in the pre-commit hook.


With the patch,
  contrib/gcc-changelog/git_email.py
0001-Revert-libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch
now prints:
OK
Warnings:
Cannot obtain info about reverted commit
'46c2e94ca66ed9991c45a6ba6204ed02869efc39'

while
  contrib/gcc-changelog/git_check_commit.py
084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
now fails with:
  Checking 084a7cf9fb2d9cb98dfbe7d91602c840ec50b002: FAILED
  ERR: Cannot find to-be-reverted commit:
"46c2e94ca66ed9991c45a6ba6204ed02869efc39"

(check_email.py always shows the warning, git_check_commit.py only
with '-v')

Notes:
- I am not sure whether a sensible testcase can be added - and, hence,
I have not added one.
- I have run "pytest-3' but my python is too old and thus might miss
some checks which
  newer pytest/flake8 will find. But at least it did pass here.
- I have not tested the cherry-pick + commit does not exist case,
  which now creates a warning as I did not quickly find a testcase.

Comments, remarks, suggestions, approval?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
contrib/gcc-changelog: Check whether revert-commit exists

contrib/ChangeLog:

	* gcc-changelog/git_commit.py (GitCommit.__init__):
	Handle commit_to_info_hook = None; otherwise, if None,
	regard it as error.
	(to_changelog_entries): Handle commit_to_info_hook = None;
	if info is None, create a warning for it.
	* gcc-changelog/git_email.py (GitEmail.__init__):
	call super() with commit_to_info_hook=None instead
	of a lamda function.

 contrib/gcc-changelog/git_commit.py | 14 +-
 contrib/gcc-changelog/git_email.py  |  3 +--
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 4f3131021f2..99e40c3c0d4 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -329,11 +329,14 @@ class GitCommit:
 self.revert_commit = m.group('hash')
 break
 if self.revert_commit:
+# The following happens for get_email.py:
+if not self.commit_to_info_hook:
+self.warnings.append(f"Cannot obtain info about reverted commit '{self.revert_commit}'")
+return
 self.info = self.commit_to_info_hook(self.revert_commit)
-
-# The following happens for get_email.py:
-if not self.info:
-return
+if not self.info:
+self.errors.append(Error('Cannot find to-be-reverted commit', self.revert_commit))
+return
 
 self.check_commit_email()
 
@@ -796,12 +799,14 @@ class GitCommit:
 orig_date = self.original_info.date
 current_timestamp = orig_date.strftime(DATE_FORMAT)
 elif self.cherry_pick_commit:
-info = self.commit_to_info_hook(self.cherry_pick_commit)
+info = (self.commit_to_info_hook
+and self.commit_to_info_hook(self.cherry_pick_commit))
 # it can happen that it is a cherry-pick for a different
 # repository
 if info:
 timestamp = info.date.strftime(DATE_FORMAT)
 else:
+self.warnings.append(f"Cherry-picked commit not found: '{self.cherry_pick_commit}'")
 timestamp = current_timestamp
 elif not timestamp or use_commit_ts:
 timestamp = current_timestamp
diff --git a/contrib/gcc-changelog/git_email.py b/contrib/gcc-changelog/git_email.py
index 49f41f2ec99..93808dfabb6 100755
--- a/contrib/gcc-changelog/git_email.py
+++ b/contrib/gcc-changelog/git_email.py
@@ -89,8 +89,7 @@ class GitEmail(GitCommit):
 t = 'M'
 modified_files.append((target if t != 'D' else source, t))
 git_info = GitInfo(None, date, author, message, modified_files)
-super().__init__(git_info,
- commit_to_info_hook=lambda x: None)
+super().__init__(git_info, commit_to_info_hook=None)
 
 
 def show_help():


[Patch] contrib/gcc-changelog: Check whether revert-commit exists

2023-09-05 Thread Tobias Burnus

That's based on the fail 
https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html
and on the discussion on IRC.

The problem in for the cron job was that 
r14-3661-g084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
referenced a commit that did not exist.

This was temporarily fixed by Jakub, but it makes sense to detect this
in the pre-commit hook.


With the patch,
  contrib/gcc-changelog/git_email.py 
0001-Revert-libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch
now prints:
OK
Warnings:
Cannot obtain info about reverted commit 
'46c2e94ca66ed9991c45a6ba6204ed02869efc39'

while
  contrib/gcc-changelog/git_check_commit.py 
084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
now fails with:
  Checking 084a7cf9fb2d9cb98dfbe7d91602c840ec50b002: FAILED
  ERR: Cannot find to-be-reverted commit: 
"46c2e94ca66ed9991c45a6ba6204ed02869efc39"

(check_email.py always shows the warning, git_check_commit.py only with '-v')

Notes:
- I am not sure whether a sensible testcase can be added - and, hence, I have 
not added one.
- I have run "pytest-3' but my python is too old and thus might miss some 
checks which
  newer pytest/flake8 will find. But at least it did pass here.
- I have not tested the cherry-pick + commit does not exist case,
  which now creates a warning as I did not quickly find a testcase.

Comments, remarks, suggestions, approval?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
contrib/gcc-changelog: Check whether revert-commit exists

contrib/ChangeLog:

	* gcc-changelog/git_commit.py (GitCommit.__init__):
	Handle commit_to_info_hook = None; otherwise, if None,
	regard it as error.
	(to_changelog_entries): Handle commit_to_info_hook = None;
	if info is None, create a warning for it.
	* gcc-changelog/git_email.py (GitEmail.__init__):
	call super() with commit_to_info_hook=None instead
	of a lamda function.

 contrib/gcc-changelog/git_commit.py | 14 +-
 contrib/gcc-changelog/git_email.py  |  3 +--
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 4f3131021f2..4d024026f2b 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -329,11 +329,13 @@ class GitCommit:
 self.revert_commit = m.group('hash')
 break
 if self.revert_commit:
+# The following happens for get_email.py:
+if not self.commit_to_info_hook:
+return
 self.info = self.commit_to_info_hook(self.revert_commit)
-
-# The following happens for get_email.py:
-if not self.info:
-return
+if not self.info:
+self.errors.append(Error('Cannot find to-be-reverted commit', self.revert_commit))
+return
 
 self.check_commit_email()
 
@@ -796,12 +798,14 @@ class GitCommit:
 orig_date = self.original_info.date
 current_timestamp = orig_date.strftime(DATE_FORMAT)
 elif self.cherry_pick_commit:
-info = self.commit_to_info_hook(self.cherry_pick_commit)
+info = (self.commit_to_info_hook
+and self.commit_to_info_hook(self.cherry_pick_commit))
 # it can happen that it is a cherry-pick for a different
 # repository
 if info:
 timestamp = info.date.strftime(DATE_FORMAT)
 else:
+self.warnings.append(f"Cherry-picked commit not found: '{self.cherry_pick_commit}'")
 timestamp = current_timestamp
 elif not timestamp or use_commit_ts:
 timestamp = current_timestamp
diff --git a/contrib/gcc-changelog/git_email.py b/contrib/gcc-changelog/git_email.py
index 49f41f2ec99..93808dfabb6 100755
--- a/contrib/gcc-changelog/git_email.py
+++ b/contrib/gcc-changelog/git_email.py
@@ -89,8 +89,7 @@ class GitEmail(GitCommit):
 t = 'M'
 modified_files.append((target if t != 'D' else source, t))
 git_info = GitInfo(None, date, author, message, modified_files)
-super().__init__(git_info,
- commit_to_info_hook=lambda x: None)
+super().__init__(git_info, commit_to_info_hook=None)
 
 
 def show_help():


Re: [PATCH 1/3] xtensa: Addendum of the commit e33d2dcb463161a110ac345a451132ce8b2b23d9

2023-05-26 Thread Max Filippov via Gcc-patches
On Thu, May 25, 2023 at 8:13 AM Takayuki 'January June' Suwa
 wrote:
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md (*extzvsi-1bit_ashlsi3):
> Retract excessive line folding, and correct the value of
> the "length" insn attribute related to TARGET_DENSITY.
> (*extzvsi-1bit_addsubx): Ditto.
> ---
>  gcc/config/xtensa/xtensa.md | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master with a more readable subject line.

-- 
Thanks.
-- Max


[PATCH 1/3] xtensa: Addendum of the commit e33d2dcb463161a110ac345a451132ce8b2b23d9

2023-05-25 Thread Takayuki 'January June' Suwa via Gcc-patches
gcc/ChangeLog:

* config/xtensa/xtensa.md (*extzvsi-1bit_ashlsi3):
Retract excessive line folding, and correct the value of
the "length" insn attribute related to TARGET_DENSITY.
(*extzvsi-1bit_addsubx): Ditto.
---
 gcc/config/xtensa/xtensa.md | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 6c1d8ee8f81..11258125165 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -1009,8 +1009,7 @@
(ashift:SI (match_dup 0)
   (match_dup 3)))]
 {
-  int pos = INTVAL (operands[2]),
-  shift = floor_log2 (INTVAL (operands[3]));
+  int pos = INTVAL (operands[2]), shift = floor_log2 (INTVAL (operands[3]));
   switch (GET_CODE (operands[4]))
 {
 case ASHIFT:
@@ -1029,7 +1028,10 @@
 }
   [(set_attr "type""arith")
(set_attr "mode""SI")
-   (set_attr "length"  "6")])
+   (set (attr "length")
+(if_then_else (match_test "TARGET_DENSITY && INTVAL (operands[3]) == 
2")
+ (const_int 5)
+ (const_int 6)))])
 
 (define_insn_and_split "*extzvsi-1bit_addsubx"
   [(set (match_operand:SI 0 "register_operand" "=a")
@@ -1053,8 +1055,7 @@
(match_dup 4))
 (match_dup 2)]))]
 {
-  int pos = INTVAL (operands[3]),
-  shift = floor_log2 (INTVAL (operands[4]));
+  int pos = INTVAL (operands[3]), shift = floor_log2 (INTVAL (operands[4]));
   switch (GET_CODE (operands[6]))
 {
 case ASHIFT:
-- 
2.30.2


Re: [PATCH] mklog.py: Add --commit option.

2023-05-11 Thread Jeff Law via Gcc-patches




On 5/11/23 02:29, Robin Dapp via Gcc-patches wrote:

Hi,

this patch allows mklog.py to be called with a commit hash directly.
So, instead of

  git show  | git gcc-mklog

  git gcc-mklog --commit 

can be used.

When no  is given but --commit is specified, HEAD is used
instead.  The behavior without --commit is the same as before.

Is that useful/OK?  I find that option a bit easier to work with.

Regards
  Robin

contrib/ChangeLog:

* mklog.py:  Add optional --commit  argument.
Seems reasonable to me and probably works better with the flows some 
people are using :-)


Jeff


[PATCH] mklog.py: Add --commit option.

2023-05-11 Thread Robin Dapp via Gcc-patches
Hi,

this patch allows mklog.py to be called with a commit hash directly.
So, instead of

 git show  | git gcc-mklog

 git gcc-mklog --commit 

can be used.

When no  is given but --commit is specified, HEAD is used
instead.  The behavior without --commit is the same as before.

Is that useful/OK?  I find that option a bit easier to work with.

Regards
 Robin

contrib/ChangeLog:

* mklog.py:  Add optional --commit  argument.
---
 contrib/mklog.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index 777212c98d7..25a3b6c0757 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -358,13 +358,23 @@ if __name__ == '__main__':
  'file')
 parser.add_argument('--update-copyright', action='store_true',
 help='Update copyright in ChangeLog files')
+parser.add_argument('--commit', const='HEAD', nargs='?',
+help='Use a specific commit instead of a '
+ 'patch file or stdin. (essentially git show '
+ 'commit-id | git gcc-mklog)')
 args = parser.parse_args()
 if args.input == '-':
 args.input = None
 if args.directory:
 root = args.directory
 
-data = open(args.input, newline='\n') if args.input else sys.stdin
+if args.commit:
+args.input = None
+data = subprocess.check_output('git show {}'.format(args.commit),
+   shell=True, encoding='utf8').strip()
+else:
+data = open(args.input, newline='\n') if args.input else sys.stdin
+
 if args.update_copyright:
 update_copyright(data)
 else:
-- 
2.40.0



Re: [PATCH] libsanitizer: cherry-pick commit 05551c658269 from upstream

2023-04-27 Thread H.J. Lu via Gcc-patches
On Thu, Apr 27, 2023 at 12:03 AM Martin Liška  wrote:
>
> On 4/27/23 04:32, H.J. Lu via Gcc-patches wrote:
> > cherry-pick:
>
> Can you please wait a few days before it? I'm going to merge again
> in the near future after https://reviews.llvm.org/D144073 got handled.

Sure.

> Martin
>
> >
> > 05551c658269 [sanitizer] Correct alignment of x32 __sanitizer_siginfo
> >
> >   * sanitizer_common/sanitizer_platform_limits_posix.h
> >   (__sanitizer_siginfo_pad): Use u64 to align x32
> >   __sanitizer_siginfo to 8 bytes.
> > ---
> >  .../sanitizer_common/sanitizer_platform_limits_posix.h   | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git 
> > a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
> > b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> > index cfca7bdedbe..e6f298c26e1 100644
> > --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> > +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> > @@ -578,8 +578,13 @@ struct __sanitizer_sigset_t {
> >  #endif
> >
> >  struct __sanitizer_siginfo_pad {
> > +#if SANITIZER_X32
> > +  // x32 siginfo_t is aligned to 8 bytes.
> > +  u64 pad[128 / sizeof(u64)];
> > +#else
> >// Require uptr, because siginfo_t is always pointer-size aligned on 
> > Linux.
> >uptr pad[128 / sizeof(uptr)];
> > +#endif
> >  };
> >
> >  #if SANITIZER_LINUX
>


-- 
H.J.


Re: [PATCH] libsanitizer: cherry-pick commit 05551c658269 from upstream

2023-04-27 Thread Martin Liška
On 4/27/23 04:32, H.J. Lu via Gcc-patches wrote:
> cherry-pick:

Can you please wait a few days before it? I'm going to merge again
in the near future after https://reviews.llvm.org/D144073 got handled.

Martin

> 
> 05551c658269 [sanitizer] Correct alignment of x32 __sanitizer_siginfo
> 
>   * sanitizer_common/sanitizer_platform_limits_posix.h
>   (__sanitizer_siginfo_pad): Use u64 to align x32
>   __sanitizer_siginfo to 8 bytes.
> ---
>  .../sanitizer_common/sanitizer_platform_limits_posix.h   | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
> b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> index cfca7bdedbe..e6f298c26e1 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
> @@ -578,8 +578,13 @@ struct __sanitizer_sigset_t {
>  #endif
>  
>  struct __sanitizer_siginfo_pad {
> +#if SANITIZER_X32
> +  // x32 siginfo_t is aligned to 8 bytes.
> +  u64 pad[128 / sizeof(u64)];
> +#else
>// Require uptr, because siginfo_t is always pointer-size aligned on Linux.
>uptr pad[128 / sizeof(uptr)];
> +#endif
>  };
>  
>  #if SANITIZER_LINUX



[PATCH] libsanitizer: cherry-pick commit 05551c658269 from upstream

2023-04-26 Thread H.J. Lu via Gcc-patches
cherry-pick:

05551c658269 [sanitizer] Correct alignment of x32 __sanitizer_siginfo

* sanitizer_common/sanitizer_platform_limits_posix.h
(__sanitizer_siginfo_pad): Use u64 to align x32
__sanitizer_siginfo to 8 bytes.
---
 .../sanitizer_common/sanitizer_platform_limits_posix.h   | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index cfca7bdedbe..e6f298c26e1 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -578,8 +578,13 @@ struct __sanitizer_sigset_t {
 #endif
 
 struct __sanitizer_siginfo_pad {
+#if SANITIZER_X32
+  // x32 siginfo_t is aligned to 8 bytes.
+  u64 pad[128 / sizeof(u64)];
+#else
   // Require uptr, because siginfo_t is always pointer-size aligned on Linux.
   uptr pad[128 / sizeof(uptr)];
+#endif
 };
 
 #if SANITIZER_LINUX
-- 
2.40.0



[PATCH (pushed)] libsanitizer: cherry-pick commit 8f5962b1ccb5fcd4d4544121d43efb860ac3cc6d from upstream

2023-02-24 Thread Martin Liška
ASAN: keep support for Global::location

We as GCC still emit __asan_global_source_location for global variables
and we would like to use it in the future. On other hand, we don't
support llvm-symbolizer and the default libbacktraace symbolizer
does not support location info.
---
 libsanitizer/asan/asan_globals.cpp  | 9 +
 libsanitizer/asan/asan_interface_internal.h | 7 ---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/libsanitizer/asan/asan_globals.cpp 
b/libsanitizer/asan/asan_globals.cpp
index 8f3491f0199..01a243927ca 100644
--- a/libsanitizer/asan/asan_globals.cpp
+++ b/libsanitizer/asan/asan_globals.cpp
@@ -92,6 +92,10 @@ static void ReportGlobal(const Global , const char 
*prefix) {
   if (info.line != 0) {
 Report("  location: name=%s, %d\n", info.file, 
static_cast(info.line));
   }
+  else if (g.gcc_location != 0) {
+// Fallback to Global::gcc_location
+Report("  location: name=%s, %d\n", g.gcc_location->filename, 
g.gcc_location->line_no);
+  }
 }
 
 static u32 FindRegistrationSite(const Global *g) {
@@ -283,6 +287,11 @@ void PrintGlobalLocation(InternalScopedString *str, const 
__asan_global ) {
 
   if (info.line != 0) {
 str->append("%s:%d", info.file, static_cast(info.line));
+  } else if (g.gcc_location != 0) {
+// Fallback to Global::gcc_location
+str->append("%s", g.gcc_location->filename ? g.gcc_location->filename : 
g.module_name);
+if (g.gcc_location->line_no) str->append(":%d", g.gcc_location->line_no);
+if (g.gcc_location->column_no) str->append(":%d", 
g.gcc_location->column_no);
   } else {
 str->append("%s", g.module_name);
   }
diff --git a/libsanitizer/asan/asan_interface_internal.h 
b/libsanitizer/asan/asan_interface_internal.h
index 987f855c0f9..a9982637802 100644
--- a/libsanitizer/asan/asan_interface_internal.h
+++ b/libsanitizer/asan/asan_interface_internal.h
@@ -53,9 +53,10 @@ extern "C" {
 const char *module_name; // Module name as a C string. This pointer is a
  // unique identifier of a module.
 uptr has_dynamic_init;   // Non-zero if the global has dynamic initializer.
-uptr windows_padding;// TODO: Figure out how to remove this padding
- // that's simply here to make the MSVC incremental
- // linker happy...
+__asan_global_source_location *gcc_location;  // Source location of a 
global,
+  // used by GCC compiler. 
LLVM uses
+  // llvm-symbolizer that 
relies
+  // on DWARF debugging info.
 uptr odr_indicator;  // The address of the ODR indicator symbol.
   };
 
-- 
2.39.2



[og12] 'libgomp.c/usm-{1,2,3,4}.c': Re-enable non-GCN offloading compilation (was: [OG12 commit] amdgcn, libgomp: USM allocation update)

2023-02-16 Thread Thomas Schwinge
Hi!

On 2022-10-24T17:26:44+0100, Andrew Stubbs  wrote:
> I've committed this patch to the devel/omp/gcc-12 branch.

> --- a/libgomp/testsuite/libgomp.c/usm-1.c
> +++ b/libgomp/testsuite/libgomp.c/usm-1.c

> --- a/libgomp/testsuite/libgomp.c/usm-2.c
> +++ b/libgomp/testsuite/libgomp.c/usm-2.c

> --- a/libgomp/testsuite/libgomp.c/usm-3.c
> +++ b/libgomp/testsuite/libgomp.c/usm-3.c

> --- a/libgomp/testsuite/libgomp.c/usm-4.c
> +++ b/libgomp/testsuite/libgomp.c/usm-4.c

> @@ -1,5 +1,6 @@
>  /* { dg-do run } */
>  /* { dg-require-effective-target omp_usm } */
> +/* { dg-options "-foffload=amdgcn-amdhsa=-mxnack=on" { target 
> offload_target_amdgcn } } */

I've pushed to devel/omp/gcc-12 branch
commit b4d4603df3fed290ccf721899be6bc69f037fe2b
"'libgomp.c/usm-{1,2,3,4}.c': Re-enable non-GCN offloading compilation",
see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From b4d4603df3fed290ccf721899be6bc69f037fe2b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 14 Feb 2023 18:57:04 +0100
Subject: [PATCH] 'libgomp.c/usm-{1,2,3,4}.c': Re-enable non-GCN offloading
 compilation

Change '-foffload=amdgcn-amdhsa=[...]' to
'-foffload-options=amdgcn-amdhsa=[...]', so that non-GCN offloading compilation
doesn't get disabled.

Fix-up for og12 commit 6ec2c29dbbc19e7d2a8f991a5848e10c65c7c74c
"amdgcn, libgomp: USM allocation update".

	libgomp/
	* testsuite/libgomp.c/usm-1.c: Re-enable non-GCN offloading
	compilation.
	* testsuite/libgomp.c/usm-2.c: Likewise.
	* testsuite/libgomp.c/usm-3.c: Likewise.
	* testsuite/libgomp.c/usm-4.c: Likewise.
---
 libgomp/ChangeLog.omp   | 8 
 libgomp/testsuite/libgomp.c/usm-1.c | 2 +-
 libgomp/testsuite/libgomp.c/usm-2.c | 2 +-
 libgomp/testsuite/libgomp.c/usm-3.c | 2 +-
 libgomp/testsuite/libgomp.c/usm-4.c | 2 +-
 5 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index 2a20516cd09..ecc14b4f537 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,3 +1,11 @@
+2023-02-16  Thomas Schwinge  
+
+	* testsuite/libgomp.c/usm-1.c: Re-enable non-GCN offloading
+	compilation.
+	* testsuite/libgomp.c/usm-2.c: Likewise.
+	* testsuite/libgomp.c/usm-3.c: Likewise.
+	* testsuite/libgomp.c/usm-4.c: Likewise.
+
 2023-02-16  Tobias Burnus  
 
 	Backported from master:
diff --git a/libgomp/testsuite/libgomp.c/usm-1.c b/libgomp/testsuite/libgomp.c/usm-1.c
index f7bf897b839..35f37de7542 100644
--- a/libgomp/testsuite/libgomp.c/usm-1.c
+++ b/libgomp/testsuite/libgomp.c/usm-1.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target omp_usm } */
-/* { dg-options "-foffload=amdgcn-amdhsa=-mxnack=on" { target offload_target_amdgcn } } */
+/* { dg-additional-options -foffload-options=amdgcn-amdhsa=-mxnack=on { target offload_target_amdgcn } } */
 
 #include 
 #include 
diff --git a/libgomp/testsuite/libgomp.c/usm-2.c b/libgomp/testsuite/libgomp.c/usm-2.c
index 3f52adbd7e1..783075edb54 100644
--- a/libgomp/testsuite/libgomp.c/usm-2.c
+++ b/libgomp/testsuite/libgomp.c/usm-2.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target omp_usm } */
-/* { dg-options "-foffload=amdgcn-amdhsa=-mxnack=on" { target offload_target_amdgcn } } */
+/* { dg-additional-options -foffload-options=amdgcn-amdhsa=-mxnack=on { target offload_target_amdgcn } } */
 
 #include 
 #include 
diff --git a/libgomp/testsuite/libgomp.c/usm-3.c b/libgomp/testsuite/libgomp.c/usm-3.c
index 225cba5fe58..733f0f34090 100644
--- a/libgomp/testsuite/libgomp.c/usm-3.c
+++ b/libgomp/testsuite/libgomp.c/usm-3.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target omp_usm } */
-/* { dg-options "-foffload=amdgcn-amdhsa=-mxnack=on" { target offload_target_amdgcn } } */
+/* { dg-additional-options -foffload-options=amdgcn-amdhsa=-mxnack=on { target offload_target_amdgcn } } */
 
 #include 
 #include 
diff --git a/libgomp/testsuite/libgomp.c/usm-4.c b/libgomp/testsuite/libgomp.c/usm-4.c
index d4addfc587a..5bf99df3b24 100644
--- a/libgomp/testsuite/libgomp.c/usm-4.c
+++ b/libgomp/testsuite/libgomp.c/usm-4.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target omp_usm } */
-/* { dg-options "-foffload=amdgcn-amdhsa=-mxnack=on" { target offload_target_amdgcn } } */
+/* { dg-additional-options -foffload-options=amdgcn-amdhsa=-mxnack=on { target offload_target_amdgcn } } */
 
 #include 
 #include 
-- 
2.25.1



Re: [PATCH] libsanitizer: cherry-pick commit 742bcbf685bc from upstream

2023-01-31 Thread Jakub Jelinek via Gcc-patches
On Tue, Jan 31, 2023 at 02:39:54PM -0800, H.J. Lu wrote:
> cherry-pick:
> 
> 742bcbf685bc compiler-rt/lib: Add .Linterceptor_sigsetjmp
> 
>   PR sanitizer/108106
>   * hwasan/hwasan_setjmp_x86_64.S (__interceptor_setjmp): Jump
>   to .Linterceptor_sigsetjmp instead of __interceptor_sigsetjmp.
>   (__interceptor_sigsetjmp): Add a local alias,
>   .Linterceptor_sigsetjmp.

LGTM, thanks.

Jakub



[PATCH] libsanitizer: cherry-pick commit 742bcbf685bc from upstream

2023-01-31 Thread H.J. Lu via Gcc-patches
cherry-pick:

742bcbf685bc compiler-rt/lib: Add .Linterceptor_sigsetjmp

PR sanitizer/108106
* hwasan/hwasan_setjmp_x86_64.S (__interceptor_setjmp): Jump
to .Linterceptor_sigsetjmp instead of __interceptor_sigsetjmp.
(__interceptor_sigsetjmp): Add a local alias,
.Linterceptor_sigsetjmp.
---
 libsanitizer/hwasan/hwasan_setjmp_x86_64.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libsanitizer/hwasan/hwasan_setjmp_x86_64.S 
b/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
index 7566c1ea0a5..a5a3858d94d 100644
--- a/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
+++ b/libsanitizer/hwasan/hwasan_setjmp_x86_64.S
@@ -37,13 +37,14 @@ __interceptor_setjmp:
   CFI_STARTPROC
   _CET_ENDBR
   xorl %esi, %esi
-  jmp  __interceptor_sigsetjmp
+  jmp  .Linterceptor_sigsetjmp
   CFI_ENDPROC
 ASM_SIZE(__interceptor_setjmp)
 
 .global __interceptor_sigsetjmp
 ASM_TYPE_FUNCTION(__interceptor_sigsetjmp)
 __interceptor_sigsetjmp:
+.Linterceptor_sigsetjmp:
   CFI_STARTPROC
   _CET_ENDBR
 
-- 
2.39.1



Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-23 Thread Martin Liška
On 1/20/23 18:33, Jason Merrill wrote:
> Martin, I wonder about having the hooks reject out-of-order CommitDate
> in future?

Yes, I would do that. Looking at the last 30K commmits I see just a few 
violations
of the order:

UNIXTS hash
1668298622 30d77d49628
1630019619 5889e842ae4
1626967834 3f7a2374d31
1624564915 a0accaa9984
1620660174 0498d2d09a2
1606210175 f72175357d0
1605630503 8895913273b
1604409789 1528f34341b
1601415121 f836f3bc8f7
1593773652 9bc2c2347d5
1588873342 b9250b3cb91
1582563261 9069e9484ce

Martin


Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-20 Thread Carlos O'Donell via Gcc-patches
On 1/19/23 23:26, Bernhard Reutner-Fischer wrote:
> On 19 January 2023 20:39:08 CET, Jason Merrill  wrote:
>> On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
>>  wrote:
>>>
>>> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
>>>> This function definition was removed years ago, remove it's prototype.
>>>>
>>>> gcc/fortran/ChangeLog:
>>>>
>>>>   * gfortran.h (gfc_check_include): Remove declaration.
>>>> ---
>>>>   gcc/fortran/gfortran.h | 1 -
>>>>   1 file changed, 1 deletion(-)
>>>> ---
>>>> Regtests cleanly, ok for trunk?
>>>>
>>>> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
>>>> index c4deec0d5b8..ce3ad61bb52 100644
>>>> --- a/gcc/fortran/gfortran.h
>>>> +++ b/gcc/fortran/gfortran.h
>>>> @@ -3208,7 +3208,6 @@ int gfc_at_eof (void);
>>>>   int gfc_at_bol (void);
>>>>   int gfc_at_eol (void);
>>>>   void gfc_advance_line (void);
>>>> -int gfc_check_include (void);
>>>>   int gfc_define_undef_line (void);
>>>>
>>>>   int gfc_wide_is_printable (gfc_char_t);
>>>
>>> OK, thanks.
>>
>> Somehow this was applied with a CommitDate in 2021, breaking scripts
>> that assume monotonically increasing CommitDate.  Anyone know how that
>> could have happened?
> 
> Sorry for that.
> I think i cherry-picked this commit to master before pushing it, not 100% 
> sure though.
> What shall we do now?

I doubt a cherry-pick did this, we cherry pick often in glibc and the
commit is added to the top of checkout and the commit date updated.

There isn't anything we can do now.

I was recently made aware that --since-as-filter= was added specifically to 
address this issue.

https://patchwork.kernel.org/project/git/patch/YlnYDgZRzDI87b/z...@vmiklos.hu/
~~~
This is similar to --since, but it will filter out not matching commits,
rather than stopping at the first not matching commit.

This is useful if you e.g. want to list the commits from the last year,
but one odd commit has a bad commit date and that would hide lots of
earlier commits in that range.

The behavior of --since is left unchanged, since it's valid to depend on
its current behavior.

Signed-off-by: Miklos Vajna 
~~~

"but one odd commit has a bad commit date" :-)

We should try to avoid commits like this because they really complicate
any date-based analysis tooling, and --since-as-filter is fairly new.

-- 
Cheers,
Carlos.



Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-20 Thread Jason Merrill via Gcc-patches
On Thu, Jan 19, 2023 at 11:26 PM Bernhard Reutner-Fischer
 wrote:
>
> On 19 January 2023 20:39:08 CET, Jason Merrill  wrote:
> >On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
> > wrote:
> >>
> >> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> >> > This function definition was removed years ago, remove it's prototype.
> >> >
> >> > gcc/fortran/ChangeLog:
> >> >
> >> >   * gfortran.h (gfc_check_include): Remove declaration.
> >> > ---
> >> >   gcc/fortran/gfortran.h | 1 -
> >> >   1 file changed, 1 deletion(-)
> >> > ---
> >> > Regtests cleanly, ok for trunk?
> >> >
> >> > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> >> > index c4deec0d5b8..ce3ad61bb52 100644
> >> > --- a/gcc/fortran/gfortran.h
> >> > +++ b/gcc/fortran/gfortran.h
> >> > @@ -3208,7 +3208,6 @@ int gfc_at_eof (void);
> >> >   int gfc_at_bol (void);
> >> >   int gfc_at_eol (void);
> >> >   void gfc_advance_line (void);
> >> > -int gfc_check_include (void);
> >> >   int gfc_define_undef_line (void);
> >> >
> >> >   int gfc_wide_is_printable (gfc_char_t);
> >>
> >> OK, thanks.
> >
> >Somehow this was applied with a CommitDate in 2021, breaking scripts
> >that assume monotonically increasing CommitDate.  Anyone know how that
> >could have happened?
>
> Sorry for that.
> I think i cherry-picked this commit to master before pushing it, not 100% 
> sure though.

You would have also needed to override the commit date with
GIT_COMMITTER_DATE.  Do you remember using that environment variable
at all?

> What shall we do now?

I don't think there's anything we can do about this commit at this
point; rewriting the git history would be a bigger disruption than
leaving it alone.

Martin, I wonder about having the hooks reject out-of-order CommitDate
in future?

Jason



Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-19 Thread Bernhard Reutner-Fischer via Gcc-patches
On 19 January 2023 20:39:08 CET, Jason Merrill  wrote:
>On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
> wrote:
>>
>> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
>> > This function definition was removed years ago, remove it's prototype.
>> >
>> > gcc/fortran/ChangeLog:
>> >
>> >   * gfortran.h (gfc_check_include): Remove declaration.
>> > ---
>> >   gcc/fortran/gfortran.h | 1 -
>> >   1 file changed, 1 deletion(-)
>> > ---
>> > Regtests cleanly, ok for trunk?
>> >
>> > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
>> > index c4deec0d5b8..ce3ad61bb52 100644
>> > --- a/gcc/fortran/gfortran.h
>> > +++ b/gcc/fortran/gfortran.h
>> > @@ -3208,7 +3208,6 @@ int gfc_at_eof (void);
>> >   int gfc_at_bol (void);
>> >   int gfc_at_eol (void);
>> >   void gfc_advance_line (void);
>> > -int gfc_check_include (void);
>> >   int gfc_define_undef_line (void);
>> >
>> >   int gfc_wide_is_printable (gfc_char_t);
>>
>> OK, thanks.
>
>Somehow this was applied with a CommitDate in 2021, breaking scripts
>that assume monotonically increasing CommitDate.  Anyone know how that
>could have happened?

Sorry for that.
I think i cherry-picked this commit to master before pushing it, not 100% sure 
though.
What shall we do now?


Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-19 Thread Harald Anlauf via Gcc-patches

Am 19.01.23 um 20:39 schrieb Jason Merrill via Gcc-patches:

On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
 wrote:


Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:

This function definition was removed years ago, remove it's prototype.

gcc/fortran/ChangeLog:

   * gfortran.h (gfc_check_include): Remove declaration.
---
   gcc/fortran/gfortran.h | 1 -
   1 file changed, 1 deletion(-)
---
Regtests cleanly, ok for trunk?

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index c4deec0d5b8..ce3ad61bb52 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3208,7 +3208,6 @@ int gfc_at_eof (void);
   int gfc_at_bol (void);
   int gfc_at_eol (void);
   void gfc_advance_line (void);
-int gfc_check_include (void);
   int gfc_define_undef_line (void);

   int gfc_wide_is_printable (gfc_char_t);


OK, thanks.


Somehow this was applied with a CommitDate in 2021, breaking scripts
that assume monotonically increasing CommitDate.  Anyone know how that
could have happened?


It is quite unusual that the CommitDate is before the AuthorDate:

% git show --pretty=fuller 7ce0cee77adf33397d0ba61e7445effd8a5d8fcc |
head -5
commit 7ce0cee77adf33397d0ba61e7445effd8a5d8fcc
Author: Bernhard Reutner-Fischer 
AuthorDate: Sat Nov 6 06:51:00 2021 +0100
Commit: Bernhard Reutner-Fischer 
CommitDate: Sat Nov 6 06:48:00 2021 +0100

Could this have prevented checks to work properly?

Harald


Jason






git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-19 Thread Jason Merrill via Gcc-patches
On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
 wrote:
>
> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> > This function definition was removed years ago, remove it's prototype.
> >
> > gcc/fortran/ChangeLog:
> >
> >   * gfortran.h (gfc_check_include): Remove declaration.
> > ---
> >   gcc/fortran/gfortran.h | 1 -
> >   1 file changed, 1 deletion(-)
> > ---
> > Regtests cleanly, ok for trunk?
> >
> > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> > index c4deec0d5b8..ce3ad61bb52 100644
> > --- a/gcc/fortran/gfortran.h
> > +++ b/gcc/fortran/gfortran.h
> > @@ -3208,7 +3208,6 @@ int gfc_at_eof (void);
> >   int gfc_at_bol (void);
> >   int gfc_at_eol (void);
> >   void gfc_advance_line (void);
> > -int gfc_check_include (void);
> >   int gfc_define_undef_line (void);
> >
> >   int gfc_wide_is_printable (gfc_char_t);
>
> OK, thanks.

Somehow this was applied with a CommitDate in 2021, breaking scripts
that assume monotonically increasing CommitDate.  Anyone know how that
could have happened?

Jason



Re: [committed] Add another commit to ignore

2022-11-10 Thread Martin Liška

On 11/7/22 09:25, Jakub Jelinek wrote:

Hi!

We can't handle r13-3652-ge4cba49413ca429dc82f6aa2e88129ecb3fdd943
because that commit removed whole liboffloadmic including its
ChangeLog (I'm surprised that touching ChangeLog worked out together
with removing the files), but gcc-changelog/git_update_version.py
then choked on it because it couldn't add the liboffloadmic
entries.


Hi.

Interesting. I'll handle such a situation for the future.


Wonder if next time such removals shouldn't be committed in 2 steps,
in one step everything but the ChangeLog would be removed, wait for
update_git_version and then in a separate commit just remove the
ChangeLog.


Will take a look.

Martin



Anyway, to restore daily bumps I had to commit the following
patch, run update_git_version manually and then commit in
r13-3705-g89d0a14a1fdf89d38d9db1156ffde8c1b276823c the ChangeLog
entries for the removal manually.

2022-11-06  Jakub Jelinek  

 * gcc-changelog/git_update_version.py: Add
 e4cba49413ca429dc82f6aa2e88129ecb3fdd943 to ignored commits.

--- contrib/gcc-changelog/git_update_version.py.jj
+++ contrib/gcc-changelog/git_update_version.py
@@ -33,7 +33,8 @@ IGNORED_COMMITS = (
  '04a040d907a83af54e0a98bdba5bfabc0ef4f700',
  '2e96b5f14e4025691b57d2301d71aa6092ed44bc',
  '3ab5c8cd03d92bf4ec41e351820349d92fbc40c4',
-'86d8e0c0652ef5236a460b75c25e4f7093cc0651')
+'86d8e0c0652ef5236a460b75c25e4f7093cc0651',
+'e4cba49413ca429dc82f6aa2e88129ecb3fdd943')
  
  FORMAT = '%(asctime)s:%(levelname)s:%(name)s:%(message)s'

  logging.basicConfig(level=logging.INFO, format=FORMAT,


Jakub





[committed] Add another commit to ignore

2022-11-07 Thread Jakub Jelinek via Gcc-patches
Hi!

We can't handle r13-3652-ge4cba49413ca429dc82f6aa2e88129ecb3fdd943
because that commit removed whole liboffloadmic including its
ChangeLog (I'm surprised that touching ChangeLog worked out together
with removing the files), but gcc-changelog/git_update_version.py
then choked on it because it couldn't add the liboffloadmic
entries.
Wonder if next time such removals shouldn't be committed in 2 steps,
in one step everything but the ChangeLog would be removed, wait for
update_git_version and then in a separate commit just remove the
ChangeLog.

Anyway, to restore daily bumps I had to commit the following
patch, run update_git_version manually and then commit in
r13-3705-g89d0a14a1fdf89d38d9db1156ffde8c1b276823c the ChangeLog
entries for the removal manually.

2022-11-06  Jakub Jelinek  

* gcc-changelog/git_update_version.py: Add
e4cba49413ca429dc82f6aa2e88129ecb3fdd943 to ignored commits.

--- contrib/gcc-changelog/git_update_version.py.jj
+++ contrib/gcc-changelog/git_update_version.py
@@ -33,7 +33,8 @@ IGNORED_COMMITS = (
 '04a040d907a83af54e0a98bdba5bfabc0ef4f700',
 '2e96b5f14e4025691b57d2301d71aa6092ed44bc',
 '3ab5c8cd03d92bf4ec41e351820349d92fbc40c4',
-'86d8e0c0652ef5236a460b75c25e4f7093cc0651')
+'86d8e0c0652ef5236a460b75c25e4f7093cc0651',
+'e4cba49413ca429dc82f6aa2e88129ecb3fdd943')
 
 FORMAT = '%(asctime)s:%(levelname)s:%(name)s:%(message)s'
 logging.basicConfig(level=logging.INFO, format=FORMAT,


Jakub



Re: [OG12 commit] vect: WORKAROUND vectorizer bug

2022-10-27 Thread Andrew Stubbs

On 24/10/2022 19:06, Richard Biener wrote:




Am 24.10.2022 um 18:51 schrieb Andrew Stubbs :

I've committed this to the OG12 branch to remove some test failures. We 
probably ought to have something on mainline also, but a proper fix would be 
better.

Without this. the libgomp.oacc-c-c++-common/private-variables.c testcase fails to compile 
due to an ICE.  The OpenACC worker broadcasting code is creating SLP optimizable loads 
and stores in amdgcn address-space-4. Previously this was "ok" as SLP didn't 
work with less that 64-lane vectors, but the newly implemented smaller vectors are 
working as intended and optimizing this.

Unfortunately the vectorizer is losing the address-space data from the intermediate 
types, and it all falls apart during expand when it tries the convert a 32-bit address 
into a 64-bit address and that's not something that works. At first sight it looks like 
we could possibly make that work with POINTERS_EXTEND_UNSIGNED, but that only changes the 
error message. Fundamentally we need to make sure that various instances of 
"vectype" have the correct address space, but my attempts to do so showed that 
that's a larger task than I have time for right now.


Istr there were issues like this in the past that I fixed, so any testcase that 
exposes this with just a gcn cc1 would be nice to have.


I've been unable to reproduce this issue on the mainline compiler. The 
SLP vectorizer says the accesses are not consecutive, although I don't 
know why they would be different.


A simple testcase works fine on OG12 as well. It's something weird to do 
with the OpenACC worker broadcasting code that I can't reproduce manually.


Thank you for the offer. I'll let you know if I get a testcase.

Andrew


Re: [OG12 commit] vect: WORKAROUND vectorizer bug

2022-10-24 Thread Richard Biener via Gcc-patches



> Am 24.10.2022 um 18:51 schrieb Andrew Stubbs :
> 
> I've committed this to the OG12 branch to remove some test failures. We 
> probably ought to have something on mainline also, but a proper fix would be 
> better.
> 
> Without this. the libgomp.oacc-c-c++-common/private-variables.c testcase 
> fails to compile due to an ICE.  The OpenACC worker broadcasting code is 
> creating SLP optimizable loads and stores in amdgcn address-space-4. 
> Previously this was "ok" as SLP didn't work with less that 64-lane vectors, 
> but the newly implemented smaller vectors are working as intended and 
> optimizing this.
> 
> Unfortunately the vectorizer is losing the address-space data from the 
> intermediate types, and it all falls apart during expand when it tries the 
> convert a 32-bit address into a 64-bit address and that's not something that 
> works. At first sight it looks like we could possibly make that work with 
> POINTERS_EXTEND_UNSIGNED, but that only changes the error message. 
> Fundamentally we need to make sure that various instances of "vectype" have 
> the correct address space, but my attempts to do so showed that that's a 
> larger task than I have time for right now.

Istr there were issues like this in the past that I fixed, so any testcase that 
exposes this with just a gcn cc1 would be nice to have.

Richard 

> 
> This patch simply prevents the vectorizer working in the case where it would 
> break. This should not be a regression because this code didn't vectorize at 
> all, previously.
> 
> Andrew
> <221024-workarround-vec-addrspace-bug.patch>


[OG12 commit] vect: WORKAROUND vectorizer bug

2022-10-24 Thread Andrew Stubbs
I've committed this to the OG12 branch to remove some test failures. We 
probably ought to have something on mainline also, but a proper fix 
would be better.


Without this. the libgomp.oacc-c-c++-common/private-variables.c testcase 
fails to compile due to an ICE.  The OpenACC worker broadcasting code is 
creating SLP optimizable loads and stores in amdgcn address-space-4. 
Previously this was "ok" as SLP didn't work with less that 64-lane 
vectors, but the newly implemented smaller vectors are working as 
intended and optimizing this.


Unfortunately the vectorizer is losing the address-space data from the 
intermediate types, and it all falls apart during expand when it tries 
the convert a 32-bit address into a 64-bit address and that's not 
something that works. At first sight it looks like we could possibly 
make that work with POINTERS_EXTEND_UNSIGNED, but that only changes the 
error message. Fundamentally we need to make sure that various instances 
of "vectype" have the correct address space, but my attempts to do so 
showed that that's a larger task than I have time for right now.


This patch simply prevents the vectorizer working in the case where it 
would break. This should not be a regression because this code didn't 
vectorize at all, previously.


Andrewvect: WORKAROUND vectorizer bug

This patch disables vectorization of memory accesses to non-default address
spaces where the pointer size is different to the usual pointer size.  This
condition typically occurs in OpenACC programs on amdgcn, where LDS memory is
used for broadcasting gang-private variables between threads. In particular,
see libgomp.oacc-c-c++-common/private-variables.c

The problem is that the address space information is dropped from the various
types in the middle-end and eventually it triggers an ICE trying to do an
address conversion.  That ICE can be avoided by defining
POINTERS_EXTEND_UNSIGNED, but that just produces wrong RTL code later on.

A correct solution would ensure that all the vectypes have the correct address
spaces, but I don't have time for that right now.

gcc/ChangeLog:

* tree-vect-data-refs.cc (vect_analyze_data_refs): Workaround an
address-space bug.

diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index 09223baf718..70b671ed94a 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -4598,7 +4598,21 @@ vect_analyze_data_refs (vec_info *vinfo, poly_uint64 
*min_vf, bool *fatal)
   /* Set vectype for STMT.  */
   scalar_type = TREE_TYPE (DR_REF (dr));
   tree vectype = get_vectype_for_scalar_type (vinfo, scalar_type);
-  if (!vectype)
+
+  /* FIXME: If the object is in an address-space in which the pointer size
+is different to the default address space then vectorizing here will
+lead to an ICE down the road because the address space information
+gets lost.  This work-around fixes the problem until we have a proper
+solution.  */
+  tree base_object = DR_REF (dr);
+  tree op = (TREE_CODE (base_object) == COMPONENT_REF
+|| TREE_CODE (base_object) == ARRAY_REF
+? TREE_OPERAND (base_object, 0) : base_object);
+  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (op));
+  bool addr_space_bug = (!ADDR_SPACE_GENERIC_P (as)
+&& targetm.addr_space.pointer_mode (as) != Pmode);
+
+  if (!vectype || addr_space_bug)
 {
   if (dump_enabled_p ())
 {


[OG12 commit] amdgcn: disallow USM on gfx908

2022-10-24 Thread Andrew Stubbs
I've committed this patch to the devel/omp/gcc-12 branch. I will have to 
fold it into my previous OpenMP memory management patch series when I 
repost it.


The GFX908 (MI100) devices only partially support the Unified Shared 
Memory model that we have, and only then with additional kernel boot 
parameters.  Without that there are unexplained memory access faults at 
runtime, and it's generally not a good user experience.


For this reason we have decided not to support USM on gfx908 in the 
toolchain. The gfx90a (MI200) devices are still supported.


Andrewamdgcn: disallow USM on gfx908

It does work, but not well and only with the amdgpu.noreply=0 kernel boot
option.

gcc/ChangeLog:

* config/gcn/gcn.cc (gcn_init_cumulative_args): Disallow gfx908.

diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
index 9c2fd4c5b8a..720c0a08a13 100644
--- a/gcc/config/gcn/gcn.cc
+++ b/gcc/config/gcn/gcn.cc
@@ -2905,6 +2905,7 @@ gcn_init_cumulative_args (CUMULATIVE_ARGS *cum /* 
Argument info to init */ ,
case PROCESSOR_FIJI:
case PROCESSOR_VEGA10:
case PROCESSOR_VEGA20:
+   case PROCESSOR_GFX908:
  error ("GPU architecture does not support Unified Shared Memory");
default:
  ;


[OG12 commit] amdgcn, libgomp: USM allocation update

2022-10-24 Thread Andrew Stubbs
I've committed this patch to the devel/omp/gcc-12 branch. I will have to 
fold it into my previous OpenMP memory management patch series when I 
repost it.


The patch changes the internal memory allocation method such that memory 
is allocated in the regular heap and then marked as "coarse-grained", as 
opposed to allocating coarse-grained memory in the first place. The 
difference is that this is CPU first, not GPU first, which is typically 
the right way around, especially when we are using this for all possible 
allocations.


Andrewamdgcn, libgomp: USM allocation update

Allocate Unified Shared Memory via malloc and hsa_amd_svm_attributes_set,
instead of hsa_allocate_memory.  This scheme should be more efficient for
for memory that is first accessed by the CPU.

libgomp/ChangeLog:

* plugin/plugin-gcn.c (HSA_AMD_SYSTEM_INFO_SVM_SUPPORTED): New.
(HSA_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT): New.
(HSA_AMD_SVM_ATTRIB_GLOBAL_FLAG): New.
(HSA_AMD_SVM_GLOBAL_FLAG_COARSE_GRAINED): New.
(hsa_amd_svm_attribute_pair_t): New.
(struct hsa_runtime_fn_info): Add hsa_amd_svm_attributes_set_fn.
(dump_hsa_system_info): Dump HSA_AMD_SYSTEM_INFO_SVM_SUPPORTED and
HSA_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT.
(DLSYM_OPT_FN): New.
(init_hsa_runtime_functions): Add hsa_amd_svm_attributes_set.
(GOMP_OFFLOAD_usm_alloc): Use malloc and hsa_amd_svm_attributes_set.
(GOMP_OFFLOAD_usm_free): Use regular free.
* testsuite/libgomp.c/usm-1.c: Add -mxnack=on for amdgcn.
* testsuite/libgomp.c/usm-2.c: Likewise.
* testsuite/libgomp.c/usm-3.c: Likewise.
* testsuite/libgomp.c/usm-4.c: Likewise.

diff --git a/libgomp/plugin/plugin-gcn.c b/libgomp/plugin/plugin-gcn.c
index dd493f63912..4871a6a793b 100644
--- a/libgomp/plugin/plugin-gcn.c
+++ b/libgomp/plugin/plugin-gcn.c
@@ -113,6 +113,16 @@ struct gcn_thread
   int async;
 };
 
+/* TEMPORARY IMPORT, UNTIL hsa_ext_amd.h GETS UPDATED.  */
+const static int HSA_AMD_SYSTEM_INFO_SVM_SUPPORTED = 0x201;
+const static int HSA_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT = 0x202;
+const static int HSA_AMD_SVM_ATTRIB_GLOBAL_FLAG = 0;
+const static int HSA_AMD_SVM_GLOBAL_FLAG_COARSE_GRAINED = 1;
+typedef struct hsa_amd_svm_attribute_pair_s {
+  uint64_t attribute;
+  uint64_t value;
+} hsa_amd_svm_attribute_pair_t;
+
 /* As an HSA runtime is dlopened, following structure defines function
pointers utilized by the HSA plug-in.  */
 
@@ -195,6 +205,9 @@ struct hsa_runtime_fn_info
   hsa_status_t (*hsa_code_object_deserialize_fn)
 (void *serialized_code_object, size_t serialized_code_object_size,
  const char *options, hsa_code_object_t *code_object);
+  hsa_status_t (*hsa_amd_svm_attributes_set_fn)
+(void* ptr, size_t size, hsa_amd_svm_attribute_pair_t* attribute_list,
+ size_t attribute_count);
 };
 
 /* Structure describing the run-time and grid properties of an HSA kernel
@@ -720,6 +733,24 @@ dump_hsa_system_info (void)
 }
   else
 GCN_WARNING ("HSA_SYSTEM_INFO_EXTENSIONS: FAILED\n");
+
+  bool svm_supported;
+  status = hsa_fns.hsa_system_get_info_fn
+(HSA_AMD_SYSTEM_INFO_SVM_SUPPORTED, _supported);
+  if (status == HSA_STATUS_SUCCESS)
+GCN_DEBUG ("HSA_AMD_SYSTEM_INFO_SVM_SUPPORTED: %s\n",
+  (svm_supported ? "TRUE" : "FALSE"));
+  else
+GCN_WARNING ("HSA_AMD_SYSTEM_INFO_SVM_SUPPORTED: FAILED\n");
+
+  bool svm_accessible;
+  status = hsa_fns.hsa_system_get_info_fn
+(HSA_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT, _accessible);
+  if (status == HSA_STATUS_SUCCESS)
+GCN_DEBUG ("HSA_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT: %s\n",
+  (svm_accessible ? "TRUE" : "FALSE"));
+  else
+GCN_WARNING ("HSA_SYSTEM_INFO_SVM_ACCESSIBLE_BY_DEFAULT: FAILED\n");
 }
 
 /* Dump information about the available hardware.  */
@@ -1361,6 +1392,8 @@ init_hsa_runtime_functions (void)
   hsa_fns.function##_fn = dlsym (handle, #function); \
   if (hsa_fns.function##_fn == NULL) \
 return false;
+#define DLSYM_OPT_FN(function) \
+  hsa_fns.function##_fn = dlsym (handle, #function);
   void *handle = dlopen (hsa_runtime_lib, RTLD_LAZY);
   if (handle == NULL)
 return false;
@@ -1395,6 +1428,7 @@ init_hsa_runtime_functions (void)
   DLSYM_FN (hsa_signal_load_acquire)
   DLSYM_FN (hsa_queue_destroy)
   DLSYM_FN (hsa_code_object_deserialize)
+  DLSYM_OPT_FN (hsa_amd_svm_attributes_set)
   return true;
 #undef DLSYM_FN
 }
@@ -3886,15 +3920,38 @@ static struct usm_splay_tree_s usm_map = { NULL };
 
 /* Allocate memory suitable for Unified Shared Memory.
 
-   In fact, AMD memory need only be "coarse grained", which target
-   allocations already are.  We do need to track allocations so that
-   GOMP_OFFLOAD_is_usm_ptr can look them up.  */
+   Normal heap memory is already enabled for USM, but by default it is "fine-
+   grained" memory, meaning that the GPU must access it via the system bus,
+   slowly.  Changing the page to 

Re: [PATCH] Allow space in git commit-mklog args

2022-07-22 Thread Jonathan Wakely via Gcc-patches
On Fri, 22 Jul 2022 at 10:38, Martin Liška wrote:
>
> Hi.
>
> Motivation example:
> $ git commit-mklog -a -b 'PR other/106370,PR other/12345'
>
> Preserving a space from git gcc-mklog hook to contrib/mklog.py seems
> pretty challenging. Thus I recommend preserving extra mklog args via
> env where it's encoded in JSON format.
>
> Thoughts?

This solution looks much better than trying to get the shell quoting
and word splitting right.

For the record, my suggestion was to surround each arg in double
quotes within the env var and then ...

> diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
> index 5da878458cd..969847df6f4 100755
> --- a/contrib/prepare-commit-msg
> +++ b/contrib/prepare-commit-msg
> @@ -78,4 +78,4 @@ else
>  tee="cat"
>  fi
>
> -git $cmd | $tee | git gcc-mklog $GCC_MKLOG_ARGS -c "$COMMIT_MSG_FILE"
> +git $cmd | $tee | git gcc-mklog -c "$COMMIT_MSG_FILE"

... change this to:

mklog() {
  echo "$GCC_MKLOG_ARGS" | xargs -x git gcc-mklog -c "$COMMIT_MSG_FILE"
}
git $cmd | $tee | mklog

This works because xargs respects quotes within its input and so would
pass them correctly to the git gcc-mklog command.

But avoiding this entirely by storing them as json and then not
retrieving them until the mklog.py step is more reliable.


[PATCH] Allow space in git commit-mklog args

2022-07-22 Thread Martin Liška
Hi.

Motivation example:
$ git commit-mklog -a -b 'PR other/106370,PR other/12345'

Preserving a space from git gcc-mklog hook to contrib/mklog.py seems
pretty challenging. Thus I recommend preserving extra mklog args via
env where it's encoded in JSON format.

Thoughts?
Thanks,
Martin

contrib/ChangeLog:

* git-commit-mklog.py: Do not parse -b argument.
Pass mklog_args as json environment variable.
* mklog.py: Parse GCC_MKLOG_ARGS and append it to sys.argv.
* prepare-commit-msg: Do not append GCC_MKLOG_ARGS to args.
---
 contrib/git-commit-mklog.py | 9 +
 contrib/mklog.py| 5 +
 contrib/prepare-commit-msg  | 2 +-
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/contrib/git-commit-mklog.py b/contrib/git-commit-mklog.py
index eda3fc4a892..c7e90c8262f 100755
--- a/contrib/git-commit-mklog.py
+++ b/contrib/git-commit-mklog.py
@@ -24,6 +24,7 @@
 # to mklog.py script.
 
 import argparse
+import json
 import os
 import subprocess
 
@@ -32,8 +33,7 @@ if __name__ == '__main__':
 myenv = os.environ.copy()
 
 parser = argparse.ArgumentParser(description='git-commit-mklog wrapped')
-parser.add_argument('-b', '--pr-numbers', action='store',
-type=lambda arg: arg.split(','), nargs='?',
+parser.add_argument('-b', '--pr-numbers',
 help='Add the specified PRs (comma separated)')
 parser.add_argument('-p', '--fill-up-bug-titles', action='store_true',
 help='Download title of mentioned PRs')
@@ -44,12 +44,13 @@ if __name__ == '__main__':
 myenv['GCC_FORCE_MKLOG'] = '1'
 mklog_args = []
 if args.pr_numbers:
-mklog_args.append(f'-b {",".join(args.pr_numbers)}')
+mklog_args += ['-b', args.pr_numbers]
 if args.fill_up_bug_titles:
 mklog_args.append('-p')
 
 if mklog_args:
-myenv['GCC_MKLOG_ARGS'] = ' '.join(mklog_args)
+# wrap mklog arguments with JSON
+myenv['GCC_MKLOG_ARGS'] = json.dumps(mklog_args)
 
 if args.co:
 for author in args.co.split(','):
diff --git a/contrib/mklog.py b/contrib/mklog.py
index cd5ef0bcc74..fe530ebf773 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -28,6 +28,7 @@
 
 import argparse
 import datetime
+import json
 import os
 import re
 import subprocess
@@ -336,6 +337,10 @@ def skip_line_in_changelog(line):
 
 
 if __name__ == '__main__':
+extra_args = os.getenv('GCC_MKLOG_ARGS')
+if extra_args:
+sys.argv += json.loads(extra_args)
+
 parser = argparse.ArgumentParser(description=help_message)
 parser.add_argument('input', nargs='?',
 help='Patch file (or missing, read standard input)')
diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
index 5da878458cd..969847df6f4 100755
--- a/contrib/prepare-commit-msg
+++ b/contrib/prepare-commit-msg
@@ -78,4 +78,4 @@ else
 tee="cat"
 fi
 
-git $cmd | $tee | git gcc-mklog $GCC_MKLOG_ARGS -c "$COMMIT_MSG_FILE"
+git $cmd | $tee | git gcc-mklog -c "$COMMIT_MSG_FILE"
-- 
2.37.1



Re: [PATCH] libsanitizer: cherry-pick commit b226894d475b from upstream

2022-05-06 Thread H.J. Lu via Gcc-patches
On Thu, May 5, 2022 at 2:02 PM H.J. Lu  wrote:
>
> cherry-pick:
>
> b226894d475b [sanitizer] [sanitizer] Correct GetTls for x32
> ---
>  libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp 
> b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
> index d966d857a76..620267cdd02 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
> +++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
> @@ -462,7 +462,11 @@ static void GetTls(uptr *addr, uptr *size) {
>  #elif SANITIZER_GLIBC && defined(__x86_64__)
>// For aarch64 and x86-64, use an O(1) approach which requires relatively
>// precise ThreadDescriptorSize. g_tls_size was initialized in InitTlsSize.
> +#  if SANITIZER_X32
> +  asm("mov %%fs:8,%0" : "=r"(*addr));
> +#  else
>asm("mov %%fs:16,%0" : "=r"(*addr));
> +#  endif
>*size = g_tls_size;
>*addr -= *size;
>*addr += ThreadDescriptorSize();
> --
> 2.35.1
>

I am backporting this to GCC 12.

-- 
H.J.


[PATCH] libsanitizer: cherry-pick commit b226894d475b from upstream

2022-05-05 Thread H.J. Lu via Gcc-patches
cherry-pick:

b226894d475b [sanitizer] [sanitizer] Correct GetTls for x32
---
 libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp 
b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
index d966d857a76..620267cdd02 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
@@ -462,7 +462,11 @@ static void GetTls(uptr *addr, uptr *size) {
 #elif SANITIZER_GLIBC && defined(__x86_64__)
   // For aarch64 and x86-64, use an O(1) approach which requires relatively
   // precise ThreadDescriptorSize. g_tls_size was initialized in InitTlsSize.
+#  if SANITIZER_X32
+  asm("mov %%fs:8,%0" : "=r"(*addr));
+#  else
   asm("mov %%fs:16,%0" : "=r"(*addr));
+#  endif
   *size = g_tls_size;
   *addr -= *size;
   *addr += ThreadDescriptorSize();
-- 
2.35.1



Re: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-05 Thread H.J. Lu via Gcc-patches
On Thu, May 5, 2022 at 11:28 AM Martin Liška  wrote:
>
> On 5/5/22 18:21, H.J. Lu wrote:
> > On Thu, May 5, 2022 at 4:24 AM Martin Liška  wrote:
> >>
> >> On 5/5/22 01:07, H.J. Lu wrote:
> >>> On Wed, May 4, 2022 at 1:59 AM Martin Liška  wrote:
> 
>  Hello.
> 
>  I'm going to do merge from upstream.
> 
>  Patch can bootstrap on x86_64-linux-gnu and survives regression
>  tests. I've also tested on ppc64le-linux-gnu and verified the ABI.
> 
>  The only real change is a small change in
>  gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c where we
>  need --param=asan-use-after-return=0.
> 
>  I'm going to push the patches.
> >>>
> >>> Hi,
> >>>
> >>> I am checking in this patch to cherry-pick
> >>>
> >>> f52e365092aa [sanitizer] Use newfstatat for x32
> >>>
> >>> to restore x32 build.
> >>>
> >>
> >> I'm going to do one more merge from upstream
> >> (75f9e83ace52773af65dcebca543005ec8a2705d) as we want to include Tobias's
> >> revision 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 and my
> >> revision f1b9245199f3457a4d06d32d1bc6e44573c166e3.
> >
> > I am testing a patch for
> >
> > https://github.com/llvm/llvm-project/issues/55288

I submitted:

https://reviews.llvm.org/D125025

> > to fix:
> >
> > https://gcc.gnu.org/pipermail/gcc-regression/2022-May/076571.html
>
> Interesting. How did you run these tests that the error shows up?

Just normal GCC bootstrap and check with x32 enabled.

> >
> > The same bug is also in GCC 12.  But somehow, it doesn't show up in
> > GCC tests.
>
> So please backport it once it's merged.
>

Will do after GCC 12 is released.

Thanks.

-- 
H.J.


Re: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-05 Thread Martin Liška
On 5/5/22 18:21, H.J. Lu wrote:
> On Thu, May 5, 2022 at 4:24 AM Martin Liška  wrote:
>>
>> On 5/5/22 01:07, H.J. Lu wrote:
>>> On Wed, May 4, 2022 at 1:59 AM Martin Liška  wrote:

 Hello.

 I'm going to do merge from upstream.

 Patch can bootstrap on x86_64-linux-gnu and survives regression
 tests. I've also tested on ppc64le-linux-gnu and verified the ABI.

 The only real change is a small change in
 gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c where we
 need --param=asan-use-after-return=0.

 I'm going to push the patches.
>>>
>>> Hi,
>>>
>>> I am checking in this patch to cherry-pick
>>>
>>> f52e365092aa [sanitizer] Use newfstatat for x32
>>>
>>> to restore x32 build.
>>>
>>
>> I'm going to do one more merge from upstream
>> (75f9e83ace52773af65dcebca543005ec8a2705d) as we want to include Tobias's
>> revision 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 and my
>> revision f1b9245199f3457a4d06d32d1bc6e44573c166e3.
> 
> I am testing a patch for
> 
> https://github.com/llvm/llvm-project/issues/55288
> 
> to fix:
> 
> https://gcc.gnu.org/pipermail/gcc-regression/2022-May/076571.html

Interesting. How did you run these tests that the error shows up?

> 
> The same bug is also in GCC 12.  But somehow, it doesn't show up in
> GCC tests.

So please backport it once it's merged.

Martin



Re: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-05 Thread H.J. Lu via Gcc-patches
On Thu, May 5, 2022 at 4:24 AM Martin Liška  wrote:
>
> On 5/5/22 01:07, H.J. Lu wrote:
> > On Wed, May 4, 2022 at 1:59 AM Martin Liška  wrote:
> >>
> >> Hello.
> >>
> >> I'm going to do merge from upstream.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression
> >> tests. I've also tested on ppc64le-linux-gnu and verified the ABI.
> >>
> >> The only real change is a small change in
> >> gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c where we
> >> need --param=asan-use-after-return=0.
> >>
> >> I'm going to push the patches.
> >
> > Hi,
> >
> > I am checking in this patch to cherry-pick
> >
> > f52e365092aa [sanitizer] Use newfstatat for x32
> >
> > to restore x32 build.
> >
>
> I'm going to do one more merge from upstream
> (75f9e83ace52773af65dcebca543005ec8a2705d) as we want to include Tobias's
> revision 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 and my
> revision f1b9245199f3457a4d06d32d1bc6e44573c166e3.

I am testing a patch for

https://github.com/llvm/llvm-project/issues/55288

to fix:

https://gcc.gnu.org/pipermail/gcc-regression/2022-May/076571.html

The same bug is also in GCC 12.  But somehow, it doesn't show up in
GCC tests.

-- 
H.J.


Re: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-05 Thread Martin Liška
On 5/5/22 01:07, H.J. Lu wrote:
> On Wed, May 4, 2022 at 1:59 AM Martin Liška  wrote:
>> 
>> Hello.
>> 
>> I'm going to do merge from upstream.
>> 
>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>> tests. I've also tested on ppc64le-linux-gnu and verified the ABI.
>> 
>> The only real change is a small change in 
>> gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c where we
>> need --param=asan-use-after-return=0.
>> 
>> I'm going to push the patches.
> 
> Hi,
> 
> I am checking in this patch to cherry-pick
> 
> f52e365092aa [sanitizer] Use newfstatat for x32
> 
> to restore x32 build.
> 

I'm going to do one more merge from upstream
(75f9e83ace52773af65dcebca543005ec8a2705d) as we want to include Tobias's
revision 6f095babc2b7d564168c7afc5bf6afb2188fd6b4 and my
revision f1b9245199f3457a4d06d32d1bc6e44573c166e3.

Martin


[PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

2022-05-04 Thread H.J. Lu via Gcc-patches
On Wed, May 4, 2022 at 1:59 AM Martin Liška  wrote:
>
> Hello.
>
> I'm going to do merge from upstream.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I've 
> also tested
> on ppc64le-linux-gnu and verified the ABI.
>
> The only real change is a small change in
> gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c
> where we need --param=asan-use-after-return=0.
>
> I'm going to push the patches.

Hi,

I am checking in this patch to cherry-pick

f52e365092aa [sanitizer] Use newfstatat for x32

to restore x32 build.

-- 
H.J.
From ae90c2d0f9bcc30af98c730f91544efa01cb897c Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Wed, 4 May 2022 15:59:49 -0700
Subject: [PATCH] libsanitizer: cherry-pick commit f52e365092aa from upstream

cherry-pick:

f52e365092aa [sanitizer] Use newfstatat for x32
---
 libsanitizer/sanitizer_common/sanitizer_linux.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cpp b/libsanitizer/sanitizer_common/sanitizer_linux.cpp
index 8e144a4e9a0..e2c32d679ad 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_linux.cpp
@@ -343,7 +343,7 @@ uptr internal_stat(const char *path, void *buf) {
 #if SANITIZER_FREEBSD
   return internal_syscall(SYSCALL(fstatat), AT_FDCWD, (uptr)path, (uptr)buf, 0);
 #elif SANITIZER_LINUX
-#  if SANITIZER_WORDSIZE == 64
+#  if SANITIZER_WORDSIZE == 64 || SANITIZER_X32
   return internal_syscall(SYSCALL(newfstatat), AT_FDCWD, (uptr)path, (uptr)buf,
   0);
 #  else
@@ -366,7 +366,7 @@ uptr internal_lstat(const char *path, void *buf) {
   return internal_syscall(SYSCALL(fstatat), AT_FDCWD, (uptr)path, (uptr)buf,
   AT_SYMLINK_NOFOLLOW);
 #elif SANITIZER_LINUX
-#  if defined(_LP64)
+#  if defined(_LP64) || SANITIZER_X32
   return internal_syscall(SYSCALL(newfstatat), AT_FDCWD, (uptr)path, (uptr)buf,
   AT_SYMLINK_NOFOLLOW);
 #  else
-- 
2.35.1



Re: [PATCH] git-backport: support renamed .cc files in commit message.

2022-01-19 Thread Martin Liška

On 1/18/22 20:10, Harald Anlauf via Fortran wrote:

Am 17.01.22 um 22:26 schrieb Martin Liška:

On 1/12/22 16:54, Martin Liška wrote:


There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.


The patch has been installed as I've made the renaming now.

Cheers,
Martin



I just made a "git rebase" and had to manually fix the filenames
in the commit message.  Otherwise gcc-verify would complain.


Sure and I'm adding a new script that basically follows all the 'did you mean'
in gcc-verify and fixes that:

ERR: unchanged file mentioned in a ChangeLog (did you mean 
"contrib/gcc-git-customization.sh"?): "contrib/gcc2-git-customization.sh"
...



Would it make sense to have something that is clever enough for
rebase to do similar things as git-backport?


Yes, a new git alias 'gcc-fix-changelog' is going to be available with the 
patch.

Martin



Thanks,
Harald

From 4f502745c8e2562ae192181bf2585bad42414d45 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 19 Jan 2022 07:57:05 +0100
Subject: [PATCH] Come up with git-fix-changelog.py script.

contrib/ChangeLog:

	* git-backport.py: Use it.
	* git-fix-changelog.py: New file.
	* gcc-git-customization.sh: Add new alias git gcc-fix-changelog.
---
 contrib/gcc-git-customization.sh |  1 +
 contrib/git-backport.py  | 47 +---
 contrib/git-fix-changelog.py | 92 
 3 files changed, 95 insertions(+), 45 deletions(-)
 create mode 100755 contrib/git-fix-changelog.py

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index aca61b781ff..2eec17937af 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -27,6 +27,7 @@ git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream)
 
 git config alias.gcc-verify '!f() { "`git rev-parse --show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
 git config alias.gcc-backport '!f() { "`git rev-parse --show-toplevel`/contrib/git-backport.py" $@; } ; f'
+git config alias.gcc-fix-changelog '!f() { "`git rev-parse --show-toplevel`/contrib/git-fix-changelog.py" $@; } ; f'
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
 git config alias.gcc-commit-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/git-commit-mklog.py" "$@"; }; f'
 
diff --git a/contrib/git-backport.py b/contrib/git-backport.py
index 83189a2b5c7..fc369d97754 100755
--- a/contrib/git-backport.py
+++ b/contrib/git-backport.py
@@ -22,29 +22,9 @@
 import argparse
 import os
 import subprocess
-import tempfile
 
 script_folder = os.path.dirname(os.path.abspath(__file__))
-verify_script = os.path.join(script_folder,
- 'gcc-changelog/git_check_commit.py')
-
-
-def replace_file_in_changelog(lines, filename):
-if not filename.endswith('.cc'):
-return
-
-# consider all componenets of a path: gcc/ipa-icf.cc
-while filename:
-for i, line in enumerate(lines):
-if filename in line:
-line = line.replace(filename, filename[:-1])
-lines[i] = line
-return
-parts = filename.split('/')
-if len(parts) == 1:
-return
-filename = '/'.join(parts[1:])
-
+fixup_script = os.path.join(script_folder, 'git-fix-changelog.py')
 
 if __name__ == '__main__':
 parser = argparse.ArgumentParser(description='Backport a git revision.')
@@ -52,27 +32,4 @@ if __name__ == '__main__':
 args = parser.parse_args()
 
 subprocess.run('git cherry-pick -x %s' % args.revision, shell=True)
-
-# Update commit message if change for a .cc file was taken
-r = subprocess.run(f'{verify_script} HEAD', shell=True, encoding='utf8',
-   stdout=subprocess.PIPE, stderr=subprocess.PIPE)
-if r.returncode != 0:
-lines = r.stdout.splitlines()
-cmd = 'git show -s --format=%B'
-commit_message = subprocess.check_output(cmd, shell=True,
- encoding='utf8').strip()
-commit_message = commit_message.splitlines()
-
-todo = [line for line in lines if 'unchanged file mentioned' in line]
-for item in todo:
-filename = item.split()[-1].strip('"')
-replace_file_in_changelog(commit_message, filename)
-
-with tempfile.NamedTemporaryFile('w', encoding='utf8',
- delete=False) as w:
-w.write('\n'.join(commit_message))
-w.close()
-subprocess.check_output(f'git commit --amend -F {w.name}',
-shell=True, encoding='utf8')
-os.unlink(w.name)
-print(f'Commit message updated: {len(todo)} .cc file(s) changed.')
+

Re: [PATCH] git-backport: support renamed .cc files in commit message.

2022-01-18 Thread Harald Anlauf via Gcc-patches

Am 17.01.22 um 22:26 schrieb Martin Liška:

On 1/12/22 16:54, Martin Liška wrote:


There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.



The patch has been installed as I've made the renaming now.

Cheers,
Martin



I just made a "git rebase" and had to manually fix the filenames
in the commit message.  Otherwise gcc-verify would complain.

Would it make sense to have something that is clever enough for
rebase to do similar things as git-backport?

Thanks,
Harald


Re: [PATCH] git-backport: support renamed .cc files in commit message.

2022-01-17 Thread Martin Liška

On 1/12/22 16:54, Martin Liška wrote:


There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.


The patch has been installed as I've made the renaming now.

Cheers,
Martin


Re: [PATCH] git-backport: support renamed .cc files in commit message.

2022-01-14 Thread Martin Liška

On 1/14/22 08:44, Bernhard Reutner-Fischer wrote:

On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška  wrote:


+def replace_file_in_changelog(lines, filename):
+if not filename.endswith('.cc'):
+return
+
+# consider all componenets of a path: gcc/ipa-icf.cc
+while filename:
+for i, line in enumerate(lines):
+if filename in line:
+line = line.replace(filename, filename[:-1])
+lines[i] = line
+return
+parts = filename.split('/')
+if len(parts) == 1:
+return
+filename = '/'.join(parts[1:])
+


I think you mean os.sep instead of the hardcoded slash.
But i'd use os.path.split and os.path.join


Hello.

Well, these are all paths from a git commit message. And we require unix-style
of paths for all ChangeLog entries. So it should be correct.

Martin



thanks,




Re: [PATCH] git-backport: support renamed .cc files in commit message.

2022-01-13 Thread Bernhard Reutner-Fischer via Gcc-patches
On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška  wrote:

> +def replace_file_in_changelog(lines, filename):
> +if not filename.endswith('.cc'):
> +return
> +
> +# consider all componenets of a path: gcc/ipa-icf.cc
> +while filename:
> +for i, line in enumerate(lines):
> +if filename in line:
> +line = line.replace(filename, filename[:-1])
> +lines[i] = line
> +return
> +parts = filename.split('/')
> +if len(parts) == 1:
> +return
> +filename = '/'.join(parts[1:])
> +

I think you mean os.sep instead of the hardcoded slash.
But i'd use os.path.split and os.path.join

thanks,


[PATCH] git-backport: support renamed .cc files in commit message.

2022-01-12 Thread Martin Liška

Hi.

There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.

Example usage:

$ git show test
commit 8ed4b2cb9aa158c0ef418fd1ac66271664904604 (test)
Author: Martin Liska 
Date:   Wed Jan 12 16:08:13 2022 +0100

Fix file.

gcc/ChangeLog:

* ipa-icf.cc: Test me.

gcc/ada/ChangeLog:

* cal.c: aaa.

libcpp/ChangeLog:

* expr.cc: aaa.


$ git gcc-backport test
Auto-merging gcc/ada/cal.c
Auto-merging gcc/ipa-icf.c
Auto-merging libcpp/expr.c
[test2 ee40feb077e] Fix file.
 Date: Wed Jan 12 16:08:13 2022 +0100
 3 files changed, 3 insertions(+)
Commit message updated: 2 .cc file(s) changed.

$ git show test2
commit f59a1e736c1b68f07d83388a994df8d043e8aa6e (test2)
Author: Martin Liska 
Date:   Wed Jan 12 16:08:13 2022 +0100

Fix file.

gcc/ChangeLog:

* ipa-icf.c: Test me.

gcc/ada/ChangeLog:

* cal.c: aaa.

libcpp/ChangeLog:

* expr.c: aaa.

(cherry picked from commit 8ed4b2cb9aa158c0ef418fd1ac66271664904604)


MartinFrom 647a6dbaf8cde4ee07b95c4530a03f7774500914 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 12 Jan 2022 16:35:41 +0100
Subject: [PATCH] git-backport: support renamed .cc files in commit message.

The change can automatically update names for *.cc files that
are part of a backport.

contrib/ChangeLog:

	* git-backport.py: Support renaming of .cc files.
---
 contrib/git-backport.py | 50 +
 1 file changed, 50 insertions(+)

diff --git a/contrib/git-backport.py b/contrib/git-backport.py
index 2b8e4686719..627bbd9ee66 100755
--- a/contrib/git-backport.py
+++ b/contrib/git-backport.py
@@ -20,7 +20,32 @@
 # Boston, MA 02110-1301, USA.
 
 import argparse
+import os
 import subprocess
+import sys
+import tempfile
+
+script_folder = os.path.dirname(os.path.abspath(__file__))
+verify_script = os.path.join(script_folder,
+ 'gcc-changelog/git_check_commit.py')
+
+
+def replace_file_in_changelog(lines, filename):
+if not filename.endswith('.cc'):
+return
+
+# consider all componenets of a path: gcc/ipa-icf.cc
+while filename:
+for i, line in enumerate(lines):
+if filename in line:
+line = line.replace(filename, filename[:-1])
+lines[i] = line
+return
+parts = filename.split('/')
+if len(parts) == 1:
+return
+filename = '/'.join(parts[1:])
+
 
 if __name__ == '__main__':
 parser = argparse.ArgumentParser(description='Backport a git revision and '
@@ -63,3 +88,28 @@ if __name__ == '__main__':
 subprocess.check_output(cmd, shell=True)
 else:
 print('Please resolve all remaining file conflicts.')
+sys.exit(1)
+
+# Update commit message if change for a .cc file was taken
+r = subprocess.run(f'{verify_script} HEAD', shell=True, encoding='utf8',
+   stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+if r.returncode != 0:
+lines = r.stdout.splitlines()
+cmd = 'git show -s --format=%B'
+commit_message = subprocess.check_output(cmd, shell=True,
+ encoding='utf8').strip()
+commit_message = commit_message.splitlines()
+
+todo = [line for line in lines if 'unchanged file mentioned' in line]
+for item in todo:
+filename = item.split()[-1].strip('"')
+replace_file_in_changelog(commit_message, filename)
+
+with tempfile.NamedTemporaryFile('w', encoding='utf8',
+ delete=False) as w:
+w.write('\n'.join(commit_message))
+w.close()
+subprocess.check_output(f'git commit --amend -F {w.name}',
+shell=True, encoding='utf8')
+os.unlink(w.name)
+print(f'Commit message updated: {len(todo)} .cc file(s) changed.')
-- 
2.34.1



Re: [GCC-11] [PATCH] libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

2022-01-11 Thread H.J. Lu via Gcc-patches
On Mon, Jan 3, 2022 at 6:06 AM Richard Biener
 wrote:
>
> On Fri, Dec 17, 2021 at 11:45 PM H.J. Lu via Gcc-patches
>  wrote:
> >
> > OK for release branches?
>
> OK - I assume the size is not leaked as ABI detail?

No, it is not.  I am checking it into GCC 11 and will backport
it to GCC 10/9 branches later.

> >
> > H.J.
> > ---
> > Cherry-pick from LLVM release/13.x branch:
> >
> > commit d96358a2819399a2abb60ad3b26444ab7b4409cf
> > Author: Michał Górny 
> > Date:   Mon Dec 13 22:28:26 2021 +0100
> >
> > [compiler-rt] Increase kDlsymAllocPoolSize to fix test failures
> >
> > Increase kDlsymAllocPoolSize on the release branch as discussed on bug
> > 51620, as an alternative to backporting
> > cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
> > The minimum size is 8192, as needed for the following test to pass:
> >
> >   AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp
> >
> > Fixes #51620
> >
> > PR sanitizer/102911
> > * asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
> > 8192 on Linux.
> > ---
> >  libsanitizer/asan/asan_malloc_linux.cpp | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libsanitizer/asan/asan_malloc_linux.cpp 
> > b/libsanitizer/asan/asan_malloc_linux.cpp
> > index 9c3f0a5338e..7a5776b29ed 100644
> > --- a/libsanitizer/asan/asan_malloc_linux.cpp
> > +++ b/libsanitizer/asan/asan_malloc_linux.cpp
> > @@ -31,7 +31,7 @@ using namespace __asan;
> >
> >  static uptr allocated_for_dlsym;
> >  static uptr last_dlsym_alloc_size_in_words;
> > -static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 1024;
> > +static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 8192;
> >  static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
> >
> >  static inline bool IsInDlsymAllocPool(const void *ptr) {
> > --
> > 2.33.1
> >

Thanks.

-- 
H.J.


Re: [GCC-11] [PATCH] libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

2022-01-03 Thread Richard Biener via Gcc-patches
On Fri, Dec 17, 2021 at 11:45 PM H.J. Lu via Gcc-patches
 wrote:
>
> OK for release branches?

OK - I assume the size is not leaked as ABI detail?

>
> H.J.
> ---
> Cherry-pick from LLVM release/13.x branch:
>
> commit d96358a2819399a2abb60ad3b26444ab7b4409cf
> Author: Michał Górny 
> Date:   Mon Dec 13 22:28:26 2021 +0100
>
> [compiler-rt] Increase kDlsymAllocPoolSize to fix test failures
>
> Increase kDlsymAllocPoolSize on the release branch as discussed on bug
> 51620, as an alternative to backporting
> cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
> The minimum size is 8192, as needed for the following test to pass:
>
>   AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp
>
> Fixes #51620
>
> PR sanitizer/102911
> * asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
> 8192 on Linux.
> ---
>  libsanitizer/asan/asan_malloc_linux.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libsanitizer/asan/asan_malloc_linux.cpp 
> b/libsanitizer/asan/asan_malloc_linux.cpp
> index 9c3f0a5338e..7a5776b29ed 100644
> --- a/libsanitizer/asan/asan_malloc_linux.cpp
> +++ b/libsanitizer/asan/asan_malloc_linux.cpp
> @@ -31,7 +31,7 @@ using namespace __asan;
>
>  static uptr allocated_for_dlsym;
>  static uptr last_dlsym_alloc_size_in_words;
> -static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 1024;
> +static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 8192;
>  static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
>
>  static inline bool IsInDlsymAllocPool(const void *ptr) {
> --
> 2.33.1
>


[GCC-11] [PATCH] libsanitizer: Cherry-pick LLVM release/13.x commit d96358a28193

2021-12-17 Thread H.J. Lu via Gcc-patches
OK for release branches?


H.J.
---
Cherry-pick from LLVM release/13.x branch:

commit d96358a2819399a2abb60ad3b26444ab7b4409cf
Author: Michał Górny 
Date:   Mon Dec 13 22:28:26 2021 +0100

[compiler-rt] Increase kDlsymAllocPoolSize to fix test failures

Increase kDlsymAllocPoolSize on the release branch as discussed on bug
51620, as an alternative to backporting
cb0e14ce6dcdd614a7207f4ce6fcf81a164471ab and its dependencies.
The minimum size is 8192, as needed for the following test to pass:

  AddressSanitizer-i386-linux :: TestCases/Linux/long-object-path.cpp

Fixes #51620

PR sanitizer/102911
* asan/asan_malloc_linux.cpp (kDlsymAllocPoolSize): Set it to
8192 on Linux.
---
 libsanitizer/asan/asan_malloc_linux.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libsanitizer/asan/asan_malloc_linux.cpp 
b/libsanitizer/asan/asan_malloc_linux.cpp
index 9c3f0a5338e..7a5776b29ed 100644
--- a/libsanitizer/asan/asan_malloc_linux.cpp
+++ b/libsanitizer/asan/asan_malloc_linux.cpp
@@ -31,7 +31,7 @@ using namespace __asan;
 
 static uptr allocated_for_dlsym;
 static uptr last_dlsym_alloc_size_in_words;
-static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 1024;
+static const uptr kDlsymAllocPoolSize = SANITIZER_RTEMS ? 4096 : 8192;
 static uptr alloc_memory_for_dlsym[kDlsymAllocPoolSize];
 
 static inline bool IsInDlsymAllocPool(const void *ptr) {
-- 
2.33.1



[commit][master+OG11] amdgcn: Fix ICE generating CFI [PR103396]

2021-11-25 Thread Andrew Stubbs

If committed this patch to fix the amdgcn ICE reported in PR103396.

The problem was that it was mis-counting the number of registers to save 
when the link register was only clobbered implicitly by calls. The issue 
is easily fixed by adjusting the condition to match elsewhere in the 
same function.


Committed to master and backported to devel/omp/gcc-11. It should affect 
GCC 11.


Andrewamdgcn: Fix ICE generating CFI [PR103396]

gcc/ChangeLog:

PR target/103396
* config/gcn/gcn.c (move_callee_saved_registers): Ensure that the
number of spilled registers is counted correctly.

diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 75a9c576694..2bde88afc32 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -2785,7 +2785,7 @@ move_callee_saved_registers (rtx sp, machine_function 
*offsets,
int start = (regno == VGPR_REGNO (7) ? 64 : 0);
int count = MIN (saved_scalars - start, 64);
int add_lr = (regno == VGPR_REGNO (6)
- && df_regs_ever_live_p (LINK_REGNUM));
+ && offsets->lr_needs_saving);
int lrdest = -1;
rtvec seq = rtvec_alloc (count + add_lr);
 


[COMMITTED] Revert the avoid threading circular paths commit.

2021-10-21 Thread Aldy Hernandez via Gcc-patches
I've tested this patch on the wrong tree, and picked up the test changes
in a pending patch, without which this patch is no longer obvious.
Plus, it causes a regression in an invalid test I've recommended we remove.

I'm reverting this patch until the dependencies are reviewed.

Sorry for the noise.

gcc/ChangeLog:

* tree-ssa-threadbackward.c
(back_threader::maybe_register_path): Remove circular paths check.
---
 gcc/tree-ssa-threadbackward.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 38913b06717..d94e3b962db 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -140,10 +140,6 @@ back_threader::maybe_register_path ()
 
   if (taken_edge && taken_edge != UNREACHABLE_EDGE)
 {
-  // Avoid circular paths.
-  if (m_visited_bbs.contains (taken_edge->dest))
-   return UNREACHABLE_EDGE;
-
   bool irreducible = false;
   bool profitable
= m_profit.profitable_path_p (m_path, m_name, taken_edge, );
-- 
2.31.1



[COMMIT] openmp: Mark declare variant directive as supported in Fortran

2021-10-14 Thread Kwok Cheung Yeung

Hello

As declare variant is now supported in the Fortran FE, I have removed 
the 'Only C and C++' for the declare variant entry in the list of OpenMP 
5.0 features supported. Committed as obvious.


Thanks

KwokFrom 2c4666fb0686a8f5a55821f1527351dc71c018b4 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Thu, 14 Oct 2021 09:29:13 -0700
Subject: [PATCH] openmp: Mark declare variant directive in documentation as
 supported in Fortran

2021-10-14  Kwok Cheung Yeung  

libgomp/
* libgomp.texi (OpenMP 5.0): Update entry for declare variant
directive.
---
 libgomp/libgomp.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index bdd7e3ac442..af25e9df250 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -182,7 +182,7 @@ The OpenMP 4.5 specification is fully supported.
 @item Iterators @tab Y @tab
 @item @code{metadirective} directive @tab N @tab
 @item @code{declare variant} directive
-  @tab P @tab Only C and C++, simd traits not handled correctly
+  @tab P @tab simd traits not handled correctly
 @item @emph{target-offload-var} ICV and @code{OMP_TARGET_OFFLOAD}
   env variable @tab Y @tab
 @item Nested-parallel changes to @emph{max-active-levels-var} ICV @tab Y @tab
-- 
2.30.0.335.ge636282



[OG11] My OG11 commits (testsuite + pre-mainline-review commit) / merge GCC 11 into branch, cherry picks from mainline

2021-10-14 Thread Tobias Burnus

OG11 = devel/omp/gcc-11, a branch with some OpenMP/OpenACC/offload
patches which are not yet on mainline.


* In case someone is interested, the following are my new OG11-only commits:

2021-10-14  e0fa99e57af  gomp/target-device-ancestor-*.f90: Fix testcase of OG11
OG11 moved the 'sorry' for 'omp requires reverse_offload' to libgomp,
thus, a dg-error (sorry) needs to be removed for OG11.

2021-10-13  bacbb11722e  Fortran: Fix Bind(C) Array-Descriptor Conversion
As announced, I applied it to OG11 while waiting for upstream review
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581575.htm

2021-10-12  02acf208907  gfortran.dg/gomp/defaultmap-2.f90: Use dg-message not 
-dg-note
This one changes dg-note to dg-message as the former is new in GCC 12

2021-09-20  43bef50a0d7  Revert "GCC11 - Fortran: combined directives - 
order(concurrent) not on distribute"
Reverted GCC11-only commit to avoid merge conflict with a GCC 12 cherry 
pick.


* OG11-only changes by others since my last email,
2021-06-15, "[OG11] Merge GCC 11 into branch, cherry picks from mainline"
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572786.html


  2021-08-04  64855d67f0b  libgomp amdgcn: Fix issues with dynamic OpenMP 
thread scaling
  2021-08-19  4e34710679a  openacc: fix ICE for non-decl expression in 
non-contiguous array base-pointer
  2021-09-20  07a380a8a02  openmp: Support in_reduction for Fortran
Submitted to mainline but pending fixes for the review comments
  2021-09-24  fa64a05fd08  OpenMP: Fix target device ancestor tests according 
to reverse_offload.
This one is the same as my commit above, but for C/C++ while mine now fixed 
Fortran
  2021-10-12  31a41536408  [og11] nvptx: Revert "[nvptx] Expand OpenACC child 
function arguments to use CUDA params space"
Reverts a OG11-only patch

Tobias

PS: In the following, all OG11 commits since my 2021-06-15 email
(= commit 012c780b19d).  Namely, the commits listed above plus only
mainline cherry picks + GCC 11 branch merge commit - thus, a rather
boring list.

2021-10-14  e0fa99e57af  gomp/target-device-ancestor-*.f90: Fix testcase of OG11
2021-10-13  408b402b69e  Merge remote-tracking branch 'origin/releases/gcc-11' 
into devel/omp/gcc-11
2021-10-13  bacbb11722e  Fortran: Fix Bind(C) Array-Descriptor Conversion
2021-10-13  8f25491c47f  Fortran: dump-parse-tree.c fixes for OpenMP
2021-10-12  31a41536408  [og11] nvptx: Revert "[nvptx] Expand OpenACC child function 
arguments to use CUDA params space"
2021-10-12  6cf56637cc7  Fortran version of libgomp.c-c++-common/icv-{3,4}.c
2021-10-12  595deb6b894  Fortran: Various CLASS + assumed-rank fixed [PR102541]
2021-10-12  377a7aaeb9d  openmp: Avoid calling clear_type_padding_in_mask in 
the common case where there can't be any padding
2021-10-12  6c89ed889a9  openmp: Add documentation for omp_{get_max, 
set_num}_threads and omp_{s, g}et_teams_thread_limit
2021-10-12  5374b802d4d  openmp: Fix up warnings on libgomp.info build
2021-10-12  040ad3cba6e  openmp: Add testsuite coverage for 
omp_{get_max,set_num}_threads and omp_{s,g}et_teams_thread_limit
2021-10-12  9597dac4abb  libgomp: alloc* test fixes [PR102628, PR102668]
2021-10-12  02acf208907  gfortran.dg/gomp/defaultmap-2.f90: Use dg-message not 
-dg-note
2021-10-11  2904c0b1d12  libgomp: Add tests for omp_atv_serialized and 
deprecate omp_atv_sequential.
2021-10-11  0ef55294705  Merge remote-tracking branch 'origin/releases/gcc-11' 
into devel/omp/gcc-11
2021-10-11  6665382c0ef  openmp: Add omp_set_num_teams, omp_get_max_teams, 
omp_[gs]et_teams_thread_limit
2021-10-09  5fff163e7ce  openmp: Add support for OpenMP 5.1 
structured-block-sequences
2021-10-08  10c13cdb019  Fortran: Add diagnostic for F2018:C839 (TS29113:C535c)
2021-10-08  88364f77fb6  Fortran: Avoid var initialization in interfaces 
[PR54753]
2021-10-08  cb639f7bf2e  openmp: Fix up declare target handling for vars with 
DECL_LOCAL_DECL_ALIAS [PR102640]
2021-10-06  ce1aec0cfaa  Merge remote-tracking branch 'origin/releases/gcc-11' 
into devel/omp/gcc-11
2021-10-06  01538070277  openmp: Optimize for OpenMP atomics 
2x__builtin_clear_padding+__builtin_memcmp if possible
2021-10-06  eb9c91e22df  gfortran.dg/gomp/pr43711.f90: Change dg-* for 
XFAIL->PASS
2021-10-04  9c003c9c010  Fortran: Avoid var initialization in interfaces 
[PR54753]
2021-10-02  0772686ae55  Add libgomp.fortran/order-reproducible-*.f90
2021-10-01  42a09d9e814  Add/update libgomp.fortran/alloc-*.f90
2021-10-01  4d49018b5e8  openmp: Differentiate between order(concurrent) and 
order(reproducible:concurrent)
2021-10-01  1972da66540  openmp: Avoid PLT relocations for omp_* symbols in 
libgomp
2021-10-01  f160648fb48  openmp: Add alloc_align attribute to 
omp_aligned_*alloc and testcase for omp_realloc
2021-09-30  1eb2dc0062e  Fortran: Fix same_type_as
2021-09-30  56cd6d8bde1  libgomp.fortran/alloc-*.f90: Add missing 
dg-prune-output
2021-09-30  695f503117a  openmp: Ad

Re: [PATCH 0/2] libsanitizer: Merge with upstream commit fdf4c035225d

2021-10-09 Thread Gerald Pfeifer
On Thu, 7 Oct 2021, H.J. Lu wrote:
>> Thus breaking bootstrap on FreeBSD:
>>
>> GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:370:36:
>>  error: 'MD5_CTX' was not declared in this scope
>   370 | const unsigned MD5_CTX_sz = sizeof(MD5_CTX);
>>   |^~~
>> GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:371:36:
>>  error:
>> 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
> compiler-rt sync brought in
> 
> commit 18a7ebda99044473fdbce6376993714ff54e6690
> Author: David Carlier 
> Date:   Wed Oct 6 06:01:50 2021 +0100
> 
> [Sanitizers] intercept md5 and sha* apis on FreeBSD.
> 
> Reviewed By: vitalybuka
> 
> Differential Revision: https://reviews.llvm.org/D110989
> 
> diff --git 
> a/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp
>  b/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp
> index bfe3eea464d..64535805e40 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp
> +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp
> @@ -69,6 +69,11 @@
>  #include 
>  #include 
>  #include 
> +#include 

Yep, and here is the problem: In the case of Clang this uses FreeBSD's 
.

In the case of GCC apparently this uses our own, bare-bone md5.h - 
include/md5.h.

Boom. Regression. Bootstrap failure on every platfor and version of
FreeBSD. (FreeBSD 11.x is also broken by this patch, in a different 
way, alas went end of life a week ago.)

I now filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 and
sadly don't have an idea how to tackle this.

Gerald


Re: [PATCH 0/2] libsanitizer: Merge with upstream commit fdf4c035225d

2021-10-07 Thread H.J. Lu via Gcc-patches
On Thu, Oct 7, 2021 at 2:41 PM Gerald Pfeifer  wrote:
>
> On Wed, 6 Oct 2021, H.J. Lu via Gcc-patches wrote:
> > I am checking in these patches to merge with upstream commit:
>
> Thus breaking bootstrap on FreeBSD:
>
> GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:370:36:
>  error: 'MD5_CTX' was not declared in this scope
>   370 | const unsigned MD5_CTX_sz = sizeof(MD5_CTX);
>   |^~~
> GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:371:36:
>  error:
> 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope; did you mean
> 'SHA256_DIGEST_STRING_LENGTH'?
>   371 | const unsigned MD5_return_length = MD5_DIGEST_STRING_LENGTH;
>   |^~~~
>   |SHA256_DIGEST_STRING_LENGTH
>
> I stared the the sources for minutes and FreeBSD include files and could
> not find what was wrong.

compiler-rt sync brought in

commit 18a7ebda99044473fdbce6376993714ff54e6690
Author: David Carlier 
Date:   Wed Oct 6 06:01:50 2021 +0100

[Sanitizers] intercept md5 and sha* apis on FreeBSD.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D110989

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp
 b/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp
index bfe3eea464d..64535805e40 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp
@@ -69,6 +69,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -361,6 +366,22 @@ const int si_SEGV_MAPERR = SEGV_MAPERR;
 const int si_SEGV_ACCERR = SEGV_ACCERR;
 const int unvis_valid = UNVIS_VALID;
 const int unvis_validpush = UNVIS_VALIDPUSH;
+
+const unsigned MD5_CTX_sz = sizeof(MD5_CTX);
+const unsigned MD5_return_length = MD5_DIGEST_STRING_LENGTH;
+
+#define SHA2_CONST(LEN)  \
+  const unsigned SHA##LEN##_CTX_sz = sizeof(SHA##LEN##_CTX); \
+  const unsigned SHA##LEN##_return_length = SHA##LEN##_DIGEST_STRING_LENGTH; \
+  const unsigned SHA##LEN##_block_length = SHA##LEN##_BLOCK_LENGTH;  \
+  const unsigned SHA##LEN##_digest_length = SHA##LEN##_DIGEST_LENGTH
+
+SHA2_CONST(224);
+SHA2_CONST(256);
+SHA2_CONST(384);
+SHA2_CONST(512);
+
+#undef SHA2_CONST
 }  // namespace __sanitizer

Does compiler-rt compile on FreeBSD?  If not, please file a compiler-rt bug.
If yes, why doesn't it work in GCC?

> Then I realized: GCC has its own include/md5 which misses some of these!
>
>
> Looking how old md5 is (and deprecated) I cannot help wonder whether you
> merged something that wasn't new, but intentionally left out originally?
>
> Or include paths are broken.
>
>
> Gerald
>
>
> PS: At this point I am counting about *seven* distinct bootstrap
> breakages on my nightly testers in the last six weeks or so. :-(



-- 
H.J.


Re: [PATCH 0/2] libsanitizer: Merge with upstream commit fdf4c035225d

2021-10-07 Thread Gerald Pfeifer
On Wed, 6 Oct 2021, H.J. Lu via Gcc-patches wrote:
> I am checking in these patches to merge with upstream commit:

Thus breaking bootstrap on FreeBSD:

GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:370:36:
 error: 'MD5_CTX' was not declared in this scope
  370 | const unsigned MD5_CTX_sz = sizeof(MD5_CTX);
  |^~~
GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:371:36:
 error: 
'MD5_DIGEST_STRING_LENGTH' was not declared in this scope; did you mean 
'SHA256_DIGEST_STRING_LENGTH'?
  371 | const unsigned MD5_return_length = MD5_DIGEST_STRING_LENGTH;
  |^~~~
  |SHA256_DIGEST_STRING_LENGTH

I stared the the sources for minutes and FreeBSD include files and could
not find what was wrong.

Then I realized: GCC has its own include/md5 which misses some of these!


Looking how old md5 is (and deprecated) I cannot help wonder whether you
merged something that wasn't new, but intentionally left out originally?

Or include paths are broken.


Gerald


PS: At this point I am counting about *seven* distinct bootstrap 
breakages on my nightly testers in the last six weeks or so. :-(


[PATCH 0/2] libsanitizer: Merge with upstream commit fdf4c035225d

2021-10-06 Thread H.J. Lu via Gcc-patches
I am checking in these patches to merge with upstream commit:

commit fdf4c035225de52f596899931b1f6100e5e3e928
Author: H.J. Lu 
Date:   Fri Sep 10 06:24:36 2021 -0700

[sanitizer] Support Intel CET

1. Include  in sanitizer_common/sanitizer_asm.h to mark Intel CET
support when Intel CET is enabled.
2. Add _CET_ENDBR to function entries in assembly codes so that ENDBR
instruction will be generated when Intel CET is enabled.

Reviewed By: dvyukov

Differential Revision: https://reviews.llvm.org/D85

H.J. Lu (2):
  libsanitizer: Merge with upstream
  libsanitizer: Apply local patches

 libsanitizer/MERGE|  2 +-
 libsanitizer/asan/asan_allocator.cpp  | 15 -
 libsanitizer/asan/asan_allocator.h|  2 -
 libsanitizer/asan/asan_debugging.cpp  |  5 +-
 libsanitizer/asan/asan_stats.cpp  |  4 +-
 libsanitizer/hwasan/hwasan.cpp|  4 +-
 libsanitizer/hwasan/hwasan_setjmp_x86_64.S|  2 +
 libsanitizer/lsan/lsan_common.cpp | 56 -
 libsanitizer/lsan/lsan_common.h   |  3 +
 libsanitizer/sanitizer_common/sanitizer_asm.h |  4 ++
 .../sanitizer_chained_origin_depot.cpp| 11 ++--
 .../sanitizer_chained_origin_depot.h  |  9 +--
 ...tizer_common_interceptors_vfork_i386.inc.S |  1 +
 ...zer_common_interceptors_vfork_x86_64.inc.S |  1 +
 .../sanitizer_common_libcdep.cpp  | 20 +++---
 .../sanitizer_common/sanitizer_hash.h | 24 +++
 .../sanitizer_platform_interceptors.h |  4 +-
 .../sanitizer_platform_limits_freebsd.cpp | 21 +++
 .../sanitizer_platform_limits_freebsd.h   | 16 +
 .../sanitizer_common/sanitizer_stackdepot.cpp | 49 ---
 .../sanitizer_common/sanitizer_stackdepot.h   | 10 +--
 .../sanitizer_stackdepotbase.h|  9 +--
 libsanitizer/tsan/tsan_interceptors.h |  6 +-
 libsanitizer/tsan/tsan_interceptors_posix.cpp | 13 ++--
 libsanitizer/tsan/tsan_interface.cpp  |  5 +-
 libsanitizer/tsan/tsan_platform_linux.cpp | 18 +++---
 libsanitizer/tsan/tsan_platform_mac.cpp   | 62 ++-
 libsanitizer/tsan/tsan_rtl.cpp|  8 +--
 libsanitizer/tsan/tsan_rtl.h  |  9 +--
 libsanitizer/tsan/tsan_rtl_amd64.S|  6 ++
 30 files changed, 227 insertions(+), 172 deletions(-)

-- 
2.31.1



[PATCH 0/4] libsanitizer: Merge with upstream commit 1c2e5fd66ea

2021-10-01 Thread H.J. Lu via Gcc-patches
Merge with upstream commit:

commit 1c2e5fd66ea27d0c51360ba4e22099124a915562
Author: peter klausler 
Date:   Wed Sep 15 08:28:48 2021 -0700

[flang] Enforce constraint: defined ass't in WHERE must be elemental

A defined assignment subroutine invoked in the context of a WHERE
statement or construct must necessarily be elemental (C1032).

Differential Revision: https://reviews.llvm.org/D109932

H.J. Lu (4):
  libsanitizer: Merge with upstream
  libsanitizer: Apply local patches
  libsanitizer: Bump asan/tsan versions
  Update c-c++-common/tsan/atomic_stack.c

 .../c-c++-common/tsan/atomic_stack.c  |3 +-
 libsanitizer/MERGE|2 +-
 libsanitizer/asan/asan_fuchsia.cpp|   35 +-
 libsanitizer/asan/asan_globals.cpp|   14 +-
 libsanitizer/asan/asan_interceptors.cpp   |   18 +-
 libsanitizer/asan/asan_interceptors.h |   45 +-
 libsanitizer/asan/asan_report.cpp |   10 +-
 libsanitizer/asan/asan_rtl.cpp|   18 +-
 libsanitizer/asan/asan_stats.cpp  |   10 +-
 libsanitizer/asan/asan_thread.cpp |4 +-
 libsanitizer/asan/libtool-version |2 +-
 libsanitizer/hwasan/Makefile.am   |3 +-
 libsanitizer/hwasan/Makefile.in   |   12 +-
 libsanitizer/hwasan/hwasan.cpp|3 +-
 libsanitizer/hwasan/hwasan.h  |   25 +-
 .../hwasan/hwasan_allocation_functions.cpp|   24 +
 libsanitizer/hwasan/hwasan_allocator.cpp  |   58 +-
 libsanitizer/hwasan/hwasan_dynamic_shadow.cpp |9 +
 libsanitizer/hwasan/hwasan_fuchsia.cpp|   23 +
 libsanitizer/hwasan/hwasan_interceptors.cpp   |   70 +-
 .../hwasan/hwasan_interface_internal.h|   48 -
 libsanitizer/hwasan/hwasan_linux.cpp  |  147 +-
 libsanitizer/hwasan/hwasan_report.cpp |   82 +-
 ...wasan_setjmp.S => hwasan_setjmp_aarch64.S} |   21 +-
 libsanitizer/hwasan/hwasan_setjmp_x86_64.S|   80 +
 libsanitizer/hwasan/hwasan_thread.cpp |2 +-
 libsanitizer/hwasan/hwasan_type_test.cpp  |2 +-
 .../include/sanitizer/asan_interface.h|2 +-
 .../include/sanitizer/common_interface_defs.h |2 +-
 .../include/sanitizer/dfsan_interface.h   |3 +-
 .../include/sanitizer/linux_syscall_hooks.h   | 2120 +
 .../include/sanitizer/tsan_interface.h|3 +
 .../interception/interception_win.cpp |   48 +-
 libsanitizer/lsan/lsan_allocator.h|2 +-
 libsanitizer/lsan/lsan_common.cpp |   12 +-
 .../sanitizer_common/sancov_flags.inc |2 +-
 .../sanitizer_common/sanitizer_addrhashmap.h  |2 +-
 .../sanitizer_allocator_primary64.h   |   14 +-
 .../sanitizer_allocator_size_class_map.h  |8 +-
 libsanitizer/sanitizer_common/sanitizer_asm.h |4 +-
 .../sanitizer_atomic_clang_mips.h |2 +-
 .../sanitizer_common/sanitizer_common.h   |   20 +-
 .../sanitizer_common_interceptors.inc |  652 ++---
 .../sanitizer_common_interceptors_format.inc  |   10 +-
 ...izer_common_interceptors_netbsd_compat.inc |4 +-
 .../sanitizer_common_nolibc.cpp   |1 +
 .../sanitizer_common_syscalls.inc | 1559 +++-
 .../sanitizer_coverage_fuchsia.cpp|8 +-
 .../sanitizer_coverage_libcdep_new.cpp|   65 +-
 .../sanitizer_common/sanitizer_file.cpp   |   15 +
 .../sanitizer_common/sanitizer_file.h |2 +
 .../sanitizer_common/sanitizer_flag_parser.h  |2 +-
 .../sanitizer_common/sanitizer_flags.inc  |4 +
 .../sanitizer_common/sanitizer_fuchsia.cpp|   41 -
 .../sanitizer_interceptors_ioctl_netbsd.inc   |2 +-
 .../sanitizer_interface_internal.h|7 +-
 .../sanitizer_internal_defs.h |   46 +-
 .../sanitizer_common/sanitizer_libc.cpp   |   12 +
 .../sanitizer_common/sanitizer_libc.h |5 +-
 .../sanitizer_common/sanitizer_libignore.cpp  |   33 +-
 .../sanitizer_common/sanitizer_libignore.h|   37 +-
 .../sanitizer_common/sanitizer_linux.cpp  |   83 +-
 .../sanitizer_local_address_space_view.h  |2 +-
 .../sanitizer_common/sanitizer_mac.cpp|   29 +-
 .../sanitizer_common/sanitizer_mutex.cpp  |  186 ++
 .../sanitizer_common/sanitizer_mutex.h|  325 +--
 .../sanitizer_common/sanitizer_platform.h |   25 +-
 .../sanitizer_platform_interceptors.h |   27 +-
 .../sanitizer_platform_limits_freebsd.cpp |4 +
 .../sanitizer_platform_limits_freebsd.h   |  164 +-
 .../sanitizer_platform_limits_linux.cpp   |   56 +-
 .../sanitizer_platform_limits_netbsd.cpp  |1 +
 .../sanitizer_platform_limits_netbsd.h|1 +
 .../sanitizer_platform_limits_posix.cpp   |   25 +-
 .../sanitizer_platform_limits_posix.h |   30 +-
 .../sanitizer_platform_limits_solaris.cpp |1 +
 .../sanitizer_platform_limits_solaris.h   |  

[PATCH][pushed] gcc-changelog: check git commit email address

2021-09-15 Thread Martin Liška

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Check commit email.
* gcc-changelog/test_email.py: Add new test.
* gcc-changelog/test_patches.txt: Likewise.
---
 contrib/gcc-changelog/git_commit.py| 10 ++
 contrib/gcc-changelog/test_email.py|  5 +
 contrib/gcc-changelog/test_patches.txt | 25 +
 3 files changed, 40 insertions(+)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index d1646bdc0cd..03736140fd0 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -326,6 +326,8 @@ class GitCommit:
 if not self.info:
 return
 
+self.check_commit_email()

+
 # Extract PR numbers form the subject line
 # Match either [PR] / (PR) or PR component/
 if self.info.lines and not self.revert_commit:
@@ -803,3 +805,11 @@ class GitCommit:
 print('Errors:')
 for error in self.errors:
 print(error)
+
+def check_commit_email(self):
+# Parse 'Martin Liska  '
+email = self.info.author.split(' ')[-1].strip('<>')
+
+# Verify that all characters are ASCII
+if len(email) != len(email.encode()):
+self.errors.append(Error(f'non-ASCII characters in git commit 
email address ({email})'))
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index 319e065ca55..dae7c27c707 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -440,3 +440,8 @@ class TestGccChangelog(unittest.TestCase):
 def test_copyright_years(self):
 email = self.from_patch_glob('copyright-years.patch')
 assert not email.errors
+
+def test_non_ascii_email(self):
+email = self.from_patch_glob('non-ascii-email.patch')
+assert (email.errors[0].message ==
+'non-ASCII characters in git commit email address 
(jbglaw@ług-owl.de)')
diff --git a/contrib/gcc-changelog/test_patches.txt 
b/contrib/gcc-changelog/test_patches.txt
index ba516274fc1..98a0d3f1ee0 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -3464,3 +3464,28 @@ index 6f67552d075..32478f070e8 100644
 +
 --
 2.25.1
+
+=== non-ascii-email.patch ===
+From f42e95a830ab48e59389065ce79a013a519646f1 Mon Sep 17 00:00:00 2001
+From: Jan-Benedict Glaw 
+Date: Mon, 13 Sep 2021 12:08:25 +0200
+Subject: [PATCH] Fix multi-statment macro
+
+INIT_CUMULATIVE_ARGS() expands to multiple statements, which will break right
+after an `if` statement. Wrap it into a block.
+
+gcc/ChangeLog:
+
+   * config/alpha/vms.h (INIT_CUMULATIVE_ARGS): Wrap multi-statment
+   define into a block.
+---
+ gcc/config/alpha/vms.h | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/gcc/config/alpha/vms.h b/gcc/config/alpha/vms.h
+index 2a9917cde62..0033b0004b3 100644
+--- a/gcc/config/alpha/vms.h
 b/gcc/config/alpha/vms.h
+@@ -0,0 +1,1 @@
++
+--
--
2.33.0



Re: [PATCH] commit-mklog: Add --co argument.

2021-08-18 Thread Martin Liška

On 8/17/21 3:34 PM, Martin Liška wrote:

On 8/17/21 3:09 PM, Martin Liška wrote:

On 8/17/21 2:59 PM, Martin Liška wrote:

with --trailer='Signed-off-by=Mona Lisa Octocat '.


This should be of course:
--trailer='Co-Authored-By=Mona Lisa Octocat '


Update version where mklog.py skips Co-Authored-By ignoring case.

Martin


I've just pushed that to master.

Martin


Re: [PATCH] commit-mklog: Add --co argument.

2021-08-17 Thread Martin Liška

On 8/17/21 3:09 PM, Martin Liška wrote:

On 8/17/21 2:59 PM, Martin Liška wrote:

with --trailer='Signed-off-by=Mona Lisa Octocat '.


This should be of course:
--trailer='Co-Authored-By=Mona Lisa Octocat '


Update version where mklog.py skips Co-Authored-By ignoring case.

Martin
>From 68797b65eedabeb0712588409933cb69809c5fbc Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 17 Aug 2021 14:57:40 +0200
Subject: [PATCH] commit-mklog: Add --co argument.

The argument can be used for addition of Co-Authored-By lines
with --trailer='Co-Authored-By=Mona Lisa Octocat '.

contrib/ChangeLog:

	* gcc-git-customization.sh: Wrap $@ in quotes.
	* git-commit-mklog.py: Add new argument --co.
	* mklog.py: Skip the Co-Authored-By lines.
---
 contrib/gcc-git-customization.sh | 2 +-
 contrib/git-commit-mklog.py  | 6 ++
 contrib/mklog.py | 9 -
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 6f8f23deebf..aca61b781ff 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -28,7 +28,7 @@ git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream)
 git config alias.gcc-verify '!f() { "`git rev-parse --show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
 git config alias.gcc-backport '!f() { "`git rev-parse --show-toplevel`/contrib/git-backport.py" $@; } ; f'
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
-git config alias.gcc-commit-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/git-commit-mklog.py" $@; }; f'
+git config alias.gcc-commit-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/git-commit-mklog.py" "$@"; }; f'
 
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
diff --git a/contrib/git-commit-mklog.py b/contrib/git-commit-mklog.py
index 9c59fb97809..eda3fc4a892 100755
--- a/contrib/git-commit-mklog.py
+++ b/contrib/git-commit-mklog.py
@@ -37,6 +37,8 @@ if __name__ == '__main__':
 help='Add the specified PRs (comma separated)')
 parser.add_argument('-p', '--fill-up-bug-titles', action='store_true',
 help='Download title of mentioned PRs')
+parser.add_argument('--co',
+help='Add Co-Authored-By trailer (comma separated)')
 args, unknown_args = parser.parse_known_args()
 
 myenv['GCC_FORCE_MKLOG'] = '1'
@@ -49,5 +51,9 @@ if __name__ == '__main__':
 if mklog_args:
 myenv['GCC_MKLOG_ARGS'] = ' '.join(mklog_args)
 
+if args.co:
+for author in args.co.split(','):
+unknown_args.append(f'--trailer "Co-Authored-By: {author}"')
+
 commit_args = ' '.join(unknown_args)
 subprocess.run(f'git commit {commit_args}', shell=True, env=myenv)
diff --git a/contrib/mklog.py b/contrib/mklog.py
index d2aea85c7cc..d362be5ab10 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -40,6 +40,7 @@ from unidiff import PatchSet
 
 LINE_LIMIT = 100
 TAB_WIDTH = 8
+CO_AUTHORED_BY_PREFIX = 'co-authored-by: '
 
 pr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PPR [a-z+-]+\/[0-9]+)')
 prnum_regex = re.compile(r'PR (?P[a-z+-]+)/(?P[0-9]+)')
@@ -317,6 +318,12 @@ def update_copyright(data):
 f.write(content)
 
 
+def skip_line_in_changelog(line):
+if line.lower().startswith(CO_AUTHORED_BY_PREFIX) or line.startswith('#'):
+return False
+return True
+
+
 if __name__ == '__main__':
 parser = argparse.ArgumentParser(description=help_message)
 parser.add_argument('input', nargs='?',
@@ -350,7 +357,7 @@ if __name__ == '__main__':
 args.fill_up_bug_titles, args.pr_numbers)
 if args.changelog:
 lines = open(args.changelog).read().split('\n')
-start = list(takewhile(lambda l: not l.startswith('#'), lines))
+start = list(takewhile(skip_line_in_changelog, lines))
 end = lines[len(start):]
 with open(args.changelog, 'w') as f:
 if not start or not start[0]:
-- 
2.32.0



Re: [PATCH] commit-mklog: Add --co argument.

2021-08-17 Thread Martin Liška

On 8/17/21 2:59 PM, Martin Liška wrote:

with --trailer='Signed-off-by=Mona Lisa Octocat '.


This should be of course:
--trailer='Co-Authored-By=Mona Lisa Octocat '


[PATCH] commit-mklog: Add --co argument.

2021-08-17 Thread Martin Liška

The argument can be used for addition of Co-Authored-By lines
with --trailer='Signed-off-by=Mona Lisa Octocat '.

Thoughts?
Thanks,
Martin

contrib/ChangeLog:

* gcc-git-customization.sh: Wrap $@ in quotes.
* git-commit-mklog.py: Add new argument --co.
* mklog.py: Skip the Co-Authored-By lines.
---
 contrib/gcc-git-customization.sh | 2 +-
 contrib/git-commit-mklog.py  | 6 ++
 contrib/mklog.py | 8 +++-
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 6f8f23deebf..aca61b781ff 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -28,7 +28,7 @@ git config alias.gcc-undescr \!"f() { o=\$(git config --get 
gcc-config.upstream)
 git config alias.gcc-verify '!f() { "`git rev-parse 
--show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
 git config alias.gcc-backport '!f() { "`git rev-parse 
--show-toplevel`/contrib/git-backport.py" $@; } ; f'
 git config alias.gcc-mklog '!f() { "`git rev-parse 
--show-toplevel`/contrib/mklog.py" $@; } ; f'
-git config alias.gcc-commit-mklog '!f() { "`git rev-parse 
--show-toplevel`/contrib/git-commit-mklog.py" $@; }; f'
+git config alias.gcc-commit-mklog '!f() { "`git rev-parse 
--show-toplevel`/contrib/git-commit-mklog.py" "$@"; }; f'
 
 # Make diff on MD files use "(define" as a function marker.

 # Use this in conjunction with a .gitattributes file containing
diff --git a/contrib/git-commit-mklog.py b/contrib/git-commit-mklog.py
index 9c59fb97809..eda3fc4a892 100755
--- a/contrib/git-commit-mklog.py
+++ b/contrib/git-commit-mklog.py
@@ -37,6 +37,8 @@ if __name__ == '__main__':
 help='Add the specified PRs (comma separated)')
 parser.add_argument('-p', '--fill-up-bug-titles', action='store_true',
 help='Download title of mentioned PRs')
+parser.add_argument('--co',
+help='Add Co-Authored-By trailer (comma separated)')
 args, unknown_args = parser.parse_known_args()
 
 myenv['GCC_FORCE_MKLOG'] = '1'

@@ -49,5 +51,9 @@ if __name__ == '__main__':
 if mklog_args:
 myenv['GCC_MKLOG_ARGS'] = ' '.join(mklog_args)
 
+if args.co:

+for author in args.co.split(','):
+unknown_args.append(f'--trailer "Co-Authored-By: {author}"')
+
 commit_args = ' '.join(unknown_args)
 subprocess.run(f'git commit {commit_args}', shell=True, env=myenv)
diff --git a/contrib/mklog.py b/contrib/mklog.py
index d2aea85c7cc..8430f65a879 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -317,6 +317,12 @@ def update_copyright(data):
 f.write(content)
 
 
+def skip_line_in_changelog(line):

+if line.startswith('Co-Authored-By:') or line.startswith('#'):
+return False
+return True
+
+
 if __name__ == '__main__':
 parser = argparse.ArgumentParser(description=help_message)
 parser.add_argument('input', nargs='?',
@@ -350,7 +356,7 @@ if __name__ == '__main__':
 args.fill_up_bug_titles, args.pr_numbers)
 if args.changelog:
 lines = open(args.changelog).read().split('\n')
-start = list(takewhile(lambda l: not l.startswith('#'), lines))
+start = list(takewhile(skip_line_in_changelog, lines))
 end = lines[len(start):]
 with open(args.changelog, 'w') as f:
 if not start or not start[0]:
--
2.32.0



Re: Commit: Update libiberty sources

2021-07-05 Thread Nick Clifton via Gcc-patches

Hi H.J.


My patch is needed to build binutils with LTO.  I submitted a patch for GCC:

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574405.html


Very well.  I have reappplied your patch to the mainline and 2.37 branch 
sources.

Cheers
  Nick




Re: Commit: Update libiberty sources

2021-07-04 Thread H.J. Lu via Gcc-patches
On Sun, Jul 4, 2021 at 5:56 AM Alan Modra  wrote:
>
> On Sat, Jul 03, 2021 at 01:56:22PM +0100, Nick Clifton via Binutils wrote:
> > Hi Guys,
> >
> >   I am applying the attached file to synchronize our libiberty sources
> >   with gcc.
>
> This lost commit 50ad1254d503, "GCC: Pass --plugin to AR and RANLIB"
> by the look of it.  HJ, should this have been applied to gcc?
>

My patch is needed to build binutils with LTO.  I submitted a patch for GCC:

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574405.html

-- 
H.J.


Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper

2021-06-23 Thread Martin Liška

On 6/22/21 8:40 PM, Jason Merrill wrote:

On 6/22/21 3:30 AM, Martin Liška wrote:

Hello.

There's a patch candidate that comes up with a wrapper for 'git commit-mklog' 
alias.
Using my patch, one can do:

$ git commit-mklog -a -b 12345,

Thoughts?


Looks good to me.


Cool, I've just pushed that (and started using it). Plus I've added support for 
-p argument
as noted by Tobias.




Can one do that without the wrapper script and passing data through env. 
variable?


The hook seems like the way to adjust the commit message, and we can't affect 
its command line arguments, so we're left with environment variables or a file 
somewhere for communicating to it.


Yes, that's what I though.

Martin



Jason





Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper

2021-06-22 Thread Jason Merrill via Gcc-patches

On 6/22/21 3:30 AM, Martin Liška wrote:

Hello.

There's a patch candidate that comes up with a wrapper for 'git 
commit-mklog' alias.

Using my patch, one can do:

$ git commit-mklog -a -b 12345,

Thoughts?


Looks good to me.

Can one do that without the wrapper script and passing data through env. 
variable?


The hook seems like the way to adjust the commit message, and we can't 
affect its command line arguments, so we're left with environment 
variables or a file somewhere for communicating to it.


Jason



Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper

2021-06-22 Thread Martin Liška

On 6/22/21 10:23 AM, Tobias Burnus wrote:

Hello,

On 22.06.21 09:30, Martin Liška wrote:

There's a patch candidate that comes up with a wrapper for 'git
commit-mklog' alias.
Using my patch, one can do:
$ git commit-mklog -a -b 12345,
Thoughts?


What about '-p' – to fetch the data from GCC Bugzilla?


Sure, that needs to be supported as well.


I do note that
'git commit ' supports '-p, --patch' which may or may not be an issue.


People likely do not use it with commit-mklog alias.

Martin



Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf




Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper

2021-06-22 Thread Tobias Burnus

Hello,

On 22.06.21 09:30, Martin Liška wrote:

There's a patch candidate that comes up with a wrapper for 'git
commit-mklog' alias.
Using my patch, one can do:
$ git commit-mklog -a -b 12345,
Thoughts?


What about '-p' – to fetch the data from GCC Bugzilla? I do note that
'git commit ' supports '-p, --patch' which may or may not be an issue.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf


[RFC][PATCH] contrib: add git-commit-mklog wrapper

2021-06-22 Thread Martin Liška

Hello.

There's a patch candidate that comes up with a wrapper for 'git commit-mklog' 
alias.
Using my patch, one can do:

$ git commit-mklog -a -b 12345,

Thoughts?
Can one do that without the wrapper script and passing data through env. 
variable?

Martin
>From 6b63718e2836c1a5a63e476ea981ba65084ba867 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 22 Jun 2021 09:19:45 +0200
Subject: [PATCH] contrib: add git-commit-mklog wrapper

contrib/ChangeLog:

	* gcc-git-customization.sh: Use the new wrapper.
	* git-commit-mklog.py: New file.
	* prepare-commit-msg: Support GCC_MKLOG_ARGS.
---
 contrib/gcc-git-customization.sh |  2 +-
 contrib/git-commit-mklog.py  | 44 
 contrib/prepare-commit-msg   |  2 +-
 3 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100755 contrib/git-commit-mklog.py

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index e7e66623786..6f8f23deebf 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -28,7 +28,7 @@ git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream)
 git config alias.gcc-verify '!f() { "`git rev-parse --show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
 git config alias.gcc-backport '!f() { "`git rev-parse --show-toplevel`/contrib/git-backport.py" $@; } ; f'
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
-git config alias.gcc-commit-mklog '!f() { GCC_FORCE_MKLOG=1 git commit "$@"; }; f'
+git config alias.gcc-commit-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/git-commit-mklog.py" $@; }; f'
 
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
diff --git a/contrib/git-commit-mklog.py b/contrib/git-commit-mklog.py
new file mode 100755
index 000..f1ef0dfa86b
--- /dev/null
+++ b/contrib/git-commit-mklog.py
@@ -0,0 +1,44 @@
+#!/usr/bin/env python3
+
+# 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 COPYING.  If not, write to
+# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+#
+# The script is wrapper for git commit-mklog alias where it parses
+# -b/--pr-numbers argument and passes it via environment variable
+# to mklog.py script.
+
+import argparse
+import os
+import subprocess
+
+if __name__ == '__main__':
+children_args = []
+myenv = os.environ.copy()
+
+parser = argparse.ArgumentParser(description='git-commit-mklog wrapped')
+parser.add_argument('-b', '--pr-numbers', action='store',
+type=lambda arg: arg.split(','), nargs='?',
+help='Add the specified PRs (comma separated)')
+args, unknown_args = parser.parse_known_args()
+
+myenv['GCC_FORCE_MKLOG'] = '1'
+if args.pr_numbers:
+myenv['GCC_MKLOG_ARGS'] = f'-b {",".join(args.pr_numbers)}'
+commit_args = ' '.join(unknown_args)
+subprocess.run(f'git commit {commit_args}', shell=True, env=myenv)
diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
index 969847df6f4..5da878458cd 100755
--- a/contrib/prepare-commit-msg
+++ b/contrib/prepare-commit-msg
@@ -78,4 +78,4 @@ else
 tee="cat"
 fi
 
-git $cmd | $tee | git gcc-mklog -c "$COMMIT_MSG_FILE"
+git $cmd | $tee | git gcc-mklog $GCC_MKLOG_ARGS -c "$COMMIT_MSG_FILE"
-- 
2.32.0



Re: [Patch, v2] contrib/mklog.py: Improve PR handling (was: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog)

2021-06-21 Thread Tobias Burnus

Now committed as r12-1700-gedf0c3ffb59d75c11e05bc722432dc554e275c72 / as
attached.

(We had some follow-up discussion on IRC.)

On 21.06.21 14:53, Martin Liška wrote:

+# PR number in the file name
+fname = os.path.basename(file.path)


This is a dead code.


+ fname = os.path.splitext(fname)[0]
+m = pr_filename_regex.search(fname)

(Meant was the 'splitext' line - it is dead code as the re.search globs
all digits after 'pr' and then stops, ignoring the rest, including file
extensions. – I first thought it referred to the basename line, which
confused me.)

+ parser.add_argument('-b', '--pr-numbers', action='append',
+help='Add the specified PRs (comma
separated)')


Do we really want to support '-b 1 -b 2' and also -b '1,2' formats?
Seems to me quite
complicated.

[...]
I would start with -b 1,2,3,4 syntax. It will be likely easier for git
alias integration.


Done so.

I note that argparse permits '-d dir1 -d dir2 -b bug1 -b bug2' which
then only keeps the dir2 as directory and bug2 as bug without printing
an error (or warning) for ignoring dir1 and bug1.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf
commit edf0c3ffb59d75c11e05bc722432dc554e275c72
Author: Tobias Burnus 
Date:   Mon Jun 21 15:17:22 2021 +0200

contrib/mklog.py: Improve PR handling

Co-authored-by: Martin Sebor 

contrib/ChangeLog:

* mklog.py (bugzilla_url): Fetch also component.
(pr_filename_regex): New.
(get_pr_titles): Update PR string with correct format and component.
(generate_changelog): Take additional PRs; extract PR from the
filename.
(__main__): Add -b/--pr-numbers argument.
* test_mklog.py (EXPECTED4): Update to expect a PR for the new file.
---
 contrib/mklog.py  | 38 +-
 contrib/test_mklog.py |  3 +++
 2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index 1f59055e723..0b434f67971 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -42,6 +42,7 @@ pr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PPR [a-z+-]+\/[0-9]+)')
 prnum_regex = re.compile(r'PR (?P[a-z+-]+)/(?P[0-9]+)')
 dr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PDR [0-9]+)')
 dg_regex = re.compile(r'{\s+dg-(error|warning)')
+pr_filename_regex = re.compile(r'(^|[\W_])[Pp][Rr](?P\d{4,})')
 identifier_regex = re.compile(r'^([a-zA-Z0-9_#].*)')
 comment_regex = re.compile(r'^\/\*')
 struct_regex = re.compile(r'^(class|struct|union|enum)\s+'
@@ -52,7 +53,7 @@ fn_regex = re.compile(r'([a-zA-Z_][^()\s]*)\s*\([^*]')
 template_and_param_regex = re.compile(r'<[^<>]*>')
 md_def_regex = re.compile(r'\(define.*\s+"(.*)"')
 bugzilla_url = 'https://gcc.gnu.org/bugzilla/rest.cgi/bug?id=%s;' \
-   'include_fields=summary'
+   'include_fields=summary,component'
 
 function_extensions = {'.c', '.cpp', '.C', '.cc', '.h', '.inc', '.def', '.md'}
 
@@ -118,20 +119,23 @@ def sort_changelog_files(changed_file):
 
 
 def get_pr_titles(prs):
-output = ''
-for pr in prs:
+output = []
+for idx, pr in enumerate(prs):
 pr_id = pr.split('/')[-1]
 r = requests.get(bugzilla_url % pr_id)
 bugs = r.json()['bugs']
 if len(bugs) == 1:
-output += '%s - %s\n' % (pr, bugs[0]['summary'])
-print(output)
+prs[idx] = 'PR %s/%s' % (bugs[0]['component'], pr_id)
+out = '%s - %s\n' % (prs[idx], bugs[0]['summary'])
+if out not in output:
+output.append(out)
 if output:
-output += '\n'
-return output
+output.append('')
+return '\n'.join(output)
 
 
-def generate_changelog(data, no_functions=False, fill_pr_titles=False):
+def generate_changelog(data, no_functions=False, fill_pr_titles=False,
+   additional_prs=None):
 changelogs = {}
 changelog_list = []
 prs = []
@@ -139,6 +143,8 @@ def generate_changelog(data, no_functions=False, fill_pr_titles=False):
 diff = PatchSet(data)
 global firstpr
 
+if additional_prs:
+prs = [pr for pr in additional_prs if pr not in prs]
 for file in diff:
 # skip files that can't be parsed
 if file.path == '/dev/null':
@@ -154,21 +160,32 @@ def generate_changelog(data, no_functions=False, fill_pr_titles=False):
 # Only search first ten lines as later lines may
 # contains commented code which a note that it
 # has not been tested due to a certain PR or DR.
+this_file_prs = []
 for line in list(file)[0][0:10]:
 m = pr_regex.search(line.value)
 if m:
 pr = m.group('pr')
 if pr not in prs:
 

Re: [Patch, v2] contrib/mklog.py: Improve PR handling (was: Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog)

2021-06-21 Thread Martin Liška

On 6/21/21 10:37 AM, Tobias Burnus wrote:

On 21.06.21 10:09, Martin Liška wrote:


$ pytest test_mklog.py
FAILED test_mklog.py::TestMklog::test_sorting - AssertionError: assert
'\n\tPR 50209...New test.\n\n' == 'gcc/ChangeLo...New test.\n\n'

Aha, missed that there is indeed a testsuite - nice!

$ flake8 mklog.py
mklog.py:187:23: Q000 Remove bad quotes

I have now filled:
https://bugs.launchpad.net/ubuntu/+source/python-pytest-flake8/+bug/1933075


+    # PR number in the file name
+    fname = os.path.basename(file.path)


This is a dead code.


+ fname = os.path.splitext(fname)[0]
+    m = pr_filename_regex.search(fname)

It does not look like dead code to me.


Hello.

The code is weird as os.path.basename returns:

In [5]: os.path.basename('/tmp/a/b/c.txt')
Out[5]: 'c.txt'

why do you need os.path.splitext(fname) call?



+ parser.add_argument('-b', '--pr-numbers', action='append',
+    help='Add the specified PRs (comma separated)')


Do we really want to support '-b 1 -b 2' and also -b '1,2' formats?
Seems to me quite
complicated.


I don't have a strong opinion. I started with '-b 123,245', believing
that the syntax is fine. But then I realized that without '-p'
specifying multiple '-b' looks better by having multiple '-b' if 'PR
/'  (needed for -p as the string is than taken as is). Thus,
I ended up supporting either variant.


I would start with -b 1,2,3,4 syntax. It will be likely easier for git alias 
integration.

Martin



But I also happily drop the ',' support.

Change: One quote change, one test_mklog update.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf




  1   2   3   4   5   >