Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On 1/11/22 16:48, Toon Moene wrote: On 1/11/22 13:56, Martin Liška wrote: Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu and I've built all cross compilers. Does this also rename .c files in the fortran and libgfortran directories ? Hello. Yes, it does the first one. I would recommend to send this message to the fortran@gcc.gnu.org list too, then. Not everyone reads the gcc and gcc-patches lists ... CCing the list now. Thanks, Martin Kind regards,
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On 1/11/22 16:56, Jakub Jelinek wrote: While e.g. libcpp or gcc are in C++. Which means I should rename .c files under libcpp, right? Is there any other folder from gcc/ and libcpp/ that would need that as well? Martin
Re: [PATCH] Mass rename of C++ .c files to .cc suffix
On 1/11/22 17:16, Jakub Jelinek wrote: On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote: On 1/11/22 16:56, Jakub Jelinek wrote: While e.g. libcpp or gcc are in C++. Which means I should rename .c files under libcpp, right? Is there any other folder from gcc/ and libcpp/ that would need that as well? From the directories that use .c files for C++, I think that is all. c++tools/, libcody/, libitm/, libsanitizer/, libstdc++-v3/ already use .cc or .cpp. All right, I've included libcpp folder in the renaming effort. Please take a look at V2 of the series here: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/cc-renaming Now I filled up complete ChangeLog entries and I'm asking for a patchset approval. Cheers, Martin Jakub
[PATCH] git-backport: support renamed .cc files in commit message.
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: [PATCH] git-backport: support renamed .cc files in commit message.
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.
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.
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))
-
[PATCH][pushed] fortran: remove 2 dead links [PR106636]
PR fortran/106636
gcc/fortran/ChangeLog:
* gfortran.texi: Remove 2 dead links.
---
gcc/fortran/gfortran.texi | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 59d673bfc03..25410e6088d 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -455,9 +455,7 @@ version 2.6, @uref{https://www.openacc.org/}). See
The Fortran 95 standard specifies in Part 2 (ISO/IEC 1539-2:2000)
varying length character strings. While GNU Fortran currently does not
support such strings directly, there exist two Fortran implementations
-for them, which work with GNU Fortran. They can be found at
-@uref{https://www.fortran.com/@/iso_varying_string.f95} and at
-@uref{ftp://ftp.nag.co.uk/@/sc22wg5/@/ISO_VARYING_STRING/}.
+for them, which work with GNU Fortran.
Deferred-length character strings of Fortran 2003 supports part of
the features of @code{ISO_VARYING_STRING} and should be considered as
--
2.37.3
Re: [PATCH][pushed] fortran: remove 2 dead links [PR106636]
On 9/20/22 14:17, Tobias Burnus wrote:
> Hi Martin,
>
> On 20.09.22 14:02, Martin Liška wrote:
>> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
>> @@ -455,9 +455,7 @@ version 2.6, @uref{https://www.openacc.org/}). See
>> The Fortran 95 standard specifies in Part 2 (ISO/IEC 1539-2:2000)
>> varying length character strings. While GNU Fortran currently does not
>> support such strings directly, there exist two Fortran implementations
>> -for them, which work with GNU Fortran. They can be found at
>> -@uref{https://www.fortran.com/@/iso_varying_string.f95} and at
>> -@uref{ftp://ftp.nag.co.uk/@/sc22wg5/@/ISO_VARYING_STRING/}.
>> +for them, which work with GNU Fortran.
>
> Instead of removing the links, can we rather replace it by an updated link?
>
> Richard Townsend has implemented the fortran.com version; webarchive
> show that was the 1.3-F version that is still available from his own
> homepage at:
>
> http://user.astro.wisc.edu/~townsend/static.php?ref=iso-varying-string
> (BTW: I now also added Richard's website to web.archive.org.)
>
> I don't think most users need this module, but still if it is mentioned,
> I does not harm to have the link available.
Thanks for the archeological work you did.
Sure, what about the suggested patch?
Martin
>
> 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
From 64376d0f450b03e2bdaad486aaa5df8141b2dde1 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 20 Sep 2022 14:23:29 +0200
Subject: [PATCH] fortran: add link to ISO_VARYING_STRING module [PR106636]
PR fortran/106636
gcc/fortran/ChangeLog:
* gfortran.texi: Add back link to ISO_VARYING_STRING.
---
gcc/fortran/gfortran.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 25410e6088d..4ab67700362 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -455,7 +455,8 @@ version 2.6, @uref{https://www.openacc.org/}). See
The Fortran 95 standard specifies in Part 2 (ISO/IEC 1539-2:2000)
varying length character strings. While GNU Fortran currently does not
support such strings directly, there exist two Fortran implementations
-for them, which work with GNU Fortran.
+for them, which work with GNU Fortran. One can be found at
+@uref{http://user.astro.wisc.edu/~townsend/static.php?ref=iso-varying-string}.
Deferred-length character strings of Fortran 2003 supports part of
the features of @code{ISO_VARYING_STRING} and should be considered as
--
2.37.3
Re: [PATCH RESEND 0/1] RFC: P1689R5 support
On 10/18/22 14:22, Ben Boeckel wrote: > On Thu, Oct 13, 2022 at 13:08:46 -0400, David Malcolm wrote: >> On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote: >>> David Malcolm would probably know best about JSON wrangling. >> >> Unfortunately our JSON output doesn't make any guarantees about the >> ordering of keys within an object, so the precise textual output >> changes from run to run. I've coped with that in my test cases by >> limiting myself to simple regexes of fragments of the JSON output. >> >> Martin Liska [CCed] went much further in >> 4e275dccfc2467b3fe39012a3dd2a80bac257dd0 by adding a run-gcov-pytest >> DejaGnu directive, allowing for test cases for gcov to be written in >> Python, which can thus test much more interesting assertions about the >> generated JSON. > > Ok, if Python is acceptable, I'll use its stdlib to do "fancy" things. > Part of this is because I want to assert that unnecessary fields don't > exist and that sounds…unlikely to be possible in any maintainable way > (assuming it is possible) with regexen. `jq` could help immensely, but > that is probably a bridge too far :) . Yes, please use Python if you have a more complicated output verification. Examples I introduced: ./gcc/testsuite/g++.dg/gcov/test-pr98273.py ./gcc/testsuite/g++.dg/gcov/test-gcov-17.py Martin > > Thanks, > > --Ben
Re: GCC 13.0.0 Status Report (2022-11-14), Stage 3 in effect now
On 11/14/22 18:21, Xi Ruoyao wrote: > Hi Martin, > Hello. > Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd > like to cherry pick some commits from LLVM [to fix some stupid errors > I've made in LoongArch libasan :(]. I'm sorry but I was really busy with the porting of the documentation to Sphinx. Anyway, yes, we should make one one libsanitizer merge, but RM should likely approve it: Richi, Jakub, do you support it? Thanks, Martin > > On Mon, 2022-11-14 at 13:21 +, Richard Biener via Gcc-patches wrote: >> Status >> == >> >> The GCC development branch which will become GCC 13 is now in >> bugfixing mode (Stage 3) until the end of Jan 15th. >> >> As usual the first weeks of Stage 3 are used to feature patches >> posted late during Stage 1. At some point unreviewed features >> need to be postponed for the next Stage 1. >> >> >> Quality Data >> >> >> Priority # Change from last report >> --- --- >> P1 33 >> P2 473 >> P3 113 + 29 >> P4 253 + 6 >> P5 25 >> --- --- >> Total P1-P3 619 + 29 >> Total 897 + 35 >> >> >> Previous Report >> === >> >> https://gcc.gnu.org/pipermail/gcc/2022-October/239690.html >
Re: GCC 13.0.0 Status Report (2022-11-14), Stage 3 in effect now
On 11/15/22 11:07, Jakub Jelinek wrote:
> On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote:
>>> Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
>>> like to cherry pick some commits from LLVM [to fix some stupid errors
>>> I've made in LoongArch libasan :(].
>>
>> I'm sorry but I was really busy with the porting of the documentation to
>> Sphinx.
>>
>> Anyway, yes, we should make one one libsanitizer merge, but RM should likely
>> approve it: Richi, Jakub, do you support it?
>
> Could you please prepare a patch, so that we can see how much actually
> changed and decide based on that whether to go for a merge or cherry-picking
> one or more commits?
Sure, there it is. There's a minor change in output format that I address in
0003 patch.
Apart from that, I was able to run all tests on x86_64-linux-gnu.
Patch statistics:
46 files changed, 524 insertions(+), 252 deletions(-)
I'm running build on ppc64le and if you're fine, I'm going to finish
a proper libsanitizer testing procedure.
Martin
> I think last merge was done by you at the end of August, so we have
> 2.5 months of changes to potentially merge.
>
> Jakub
>
From b9da933ec8860e0c217e2f6fc08f08687d40725f Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 15 Nov 2022 12:02:36 +0100
Subject: [PATCH 3/3] asan: update expected format based on ASAN
gcc/testsuite/ChangeLog:
* c-c++-common/asan/global-overflow-1.c: Update
expected format.
* c-c++-common/asan/heap-overflow-1.c: Likewise.
* c-c++-common/asan/strlen-overflow-1.c: Likewise.
* c-c++-common/asan/strncpy-overflow-1.c: Likewise.
* c-c++-common/hwasan/heap-overflow.c: Likewise.
* g++.dg/asan/asan_mem_test.cc: Likewise.
* g++.dg/asan/asan_oob_test.cc: Likewise.
* g++.dg/asan/asan_str_test.cc: Likewise.
* g++.dg/asan/asan_test.cc: Likewise.
* g++.dg/asan/large-func-test-1.C: Likewise.
---
.../c-c++-common/asan/global-overflow-1.c | 2 +-
.../c-c++-common/asan/heap-overflow-1.c | 2 +-
.../c-c++-common/asan/strlen-overflow-1.c | 2 +-
.../c-c++-common/asan/strncpy-overflow-1.c| 2 +-
.../c-c++-common/hwasan/heap-overflow.c | 2 +-
gcc/testsuite/g++.dg/asan/asan_mem_test.cc| 20 +--
gcc/testsuite/g++.dg/asan/asan_oob_test.cc| 12 +++
gcc/testsuite/g++.dg/asan/asan_str_test.cc| 4 +--
gcc/testsuite/g++.dg/asan/asan_test.cc| 36 +--
gcc/testsuite/g++.dg/asan/large-func-test-1.C | 2 +-
10 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/asan/global-overflow-1.c b/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
index ec412231be0..b97801da2b7 100644
--- a/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
@@ -25,5 +25,5 @@ int main() {
/* { dg-skip-if "inaccurate debug info" { mips*-*-* } { "*" } { "-O0" } } */
/* { dg-output "READ of size 1 at 0x\[0-9a-f\]+ thread T0.*(\n|\r\n|\r)" } */
/* { dg-output "#0 0x\[0-9a-f\]+ +(in _*main (\[^\n\r]*global-overflow-1.c:20|\[^\n\r]*:0|\[^\n\r]*\\+0x\[0-9a-z\]*)|\[(\])\[^\n\r]*(\n|\r\n|\r).*" } */
-/* { dg-output "0x\[0-9a-f\]+ is located 0 bytes to the right of global variable" } */
+/* { dg-output "0x\[0-9a-f\]+ is located 0 bytes after global variable" } */
/* { dg-output ".*YYY\[^\n\r]* of size 10\[^\n\r]*(\n|\r\n|\r)" } */
diff --git a/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c b/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c
index 7ef048e636f..7d8744852ae 100644
--- a/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c
@@ -25,7 +25,7 @@ int main(int argc, char **argv) {
/* { dg-output "READ of size 1 at 0x\[0-9a-f\]+ thread T0.*(\n|\r\n|\r)" } */
/* { dg-output "#0 0x\[0-9a-f\]+ +(in _*main (\[^\n\r]*heap-overflow-1.c:21|\[^\n\r]*:0|\[^\n\r]*\\+0x\[0-9a-z\]*)|\[(\]).*(\n|\r\n|\r)" } */
-/* { dg-output "\[^\n\r]*0x\[0-9a-f\]+ is located 0 bytes to the right of 10-byte region\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*0x\[0-9a-f\]+ is located 0 bytes after 10-byte region\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*allocated by thread T0 here:\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "#0 0x\[0-9a-f\]+ +(in _*(interceptor_|wrap_|)malloc|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "#1 0x\[0-9a-f\]+ +(in _*main (\[^\n\r]*heap-overflow-1.c:19|\[^\n\r]*:0|\[^\n\r]*\\+0x\[0-9a-z\]*)|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
diff --git a/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c b/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c
index 86a79fd5d06..34c20c8ed50 100644
--- a/gcc/testsuite/c-c++-common/asan/strlen-overflow-1.c
+++ b/gc
libsanitizer: sync from master
Hi. I've just pushed libsanitizer update that was tested on x86_64-linux and ppc64le-linux systems. Moreover, I run bootstrap on x86_64-linux and checked ABI difference with abidiff. Pushed as r13-4068-g3037f11fb86eda. Cheers, Martin
Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)
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: libsanitizer: sync from master
On 11/15/22 16:47, Martin Liška wrote: > Hi. > > I've just pushed libsanitizer update that was tested on x86_64-linux and > ppc64le-linux systems. > Moreover, I run bootstrap on x86_64-linux and checked ABI difference with > abidiff. Hello. And I've done the same now and merged upstream version 3185e47b5a8444e9fd. Martin > > Pushed as r13-4068-g3037f11fb86eda. > > Cheers, > Martin
Re: libsanitizer: sync from master
On 4/26/23 21:23, H.J. Lu wrote: > On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote: >> >> On 11/15/22 16:47, Martin Liška wrote: >>> Hi. >>> >>> I've just pushed libsanitizer update that was tested on x86_64-linux and >>> ppc64le-linux systems. >>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with >>> abidiff. >> >> Hello. >> >> And I've done the same now and merged upstream version 3185e47b5a8444e9fd. > > It caused the bootstrap failure: > > https://gcc.gnu.org/pipermail/gcc-regression/2023-April/077674.html Can you see what's the build error in the build log? I can't see it from the sent link? Martin > >> Martin >> >>> >>> Pushed as r13-4068-g3037f11fb86eda. >>> >>> Cheers, >>> Martin >> > >
Re: libsanitizer: sync from master
On 4/26/23 20:31, Florian Weimer wrote: > * Martin Liška: > >> On 11/15/22 16:47, Martin Liška wrote: >>> Hi. >>> >>> I've just pushed libsanitizer update that was tested on x86_64-linux and >>> ppc64le-linux systems. >>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with >>> abidiff. >> >> Hello. >> >> And I've done the same now and merged upstream version 3185e47b5a8444e9fd. > > So … we have the issue that involves interceptors outside of libc.so.6, > namely crypt, crypt_r, and I posted an upstream patch for this: > > sanitizers: Disable crypt, crypt_r interceptors for glibc > <https://reviews.llvm.org/D144073> > > Can we just apply this downstream for now? It blocks various folks from > using the sanitizers in their projects. Hello. Your upstream revision has been already accepted, so please apply it and I'm going to do one more merge from upstream in the following days. Does it work for you? Cheers, Martin > > Thanks, > Florian >
Re: libsanitizer: sync from master
On 4/28/23 11:23, Florian Weimer wrote: > * Martin Liška: > >> On 4/26/23 20:31, Florian Weimer wrote: >>> * Martin Liška: >>> >>>> On 11/15/22 16:47, Martin Liška wrote: >>>>> Hi. >>>>> >>>>> I've just pushed libsanitizer update that was tested on x86_64-linux and >>>>> ppc64le-linux systems. >>>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with >>>>> abidiff. >>>> >>>> Hello. >>>> >>>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd. >>> >>> So … we have the issue that involves interceptors outside of libc.so.6, >>> namely crypt, crypt_r, and I posted an upstream patch for this: >>> >>> sanitizers: Disable crypt, crypt_r interceptors for glibc >>> <https://reviews.llvm.org/D144073> >>> >>> Can we just apply this downstream for now? It blocks various folks from >>> using the sanitizers in their projects. >> >> Hello. >> >> Your upstream revision has been already accepted, so please apply it >> and I'm going to do one more merge from upstream in the following >> days. Does it work for you? > > It's moving in a different direction now: <https://reviews.llvm.org/D149403> > > But that's okay for me as well. > > Thanks, > Florian > Hello. I've just pushed merged libsanitizer that contains both crypt-related changes and x32 fix from H.J. Cheers, Martin
[PATCH] docs: Remove empty table column.
A column with empty values seems suspicious.
Ready to be installed?
Thanks,
Martin
gcc/fortran/ChangeLog:
* intrinsic.texi: The table has first column empty and it makes
trouble when processing makeinfo --xml output.
---
gcc/fortran/intrinsic.texi | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 73baa34104e..c74a7f56c60 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -4764,15 +4764,15 @@ Unavailable time and date parameters return blanks.
@var{VALUES} is @code{INTENT(OUT)} and provides the following:
-@multitable @columnfractions .15 .30 .40
-@item @tab @code{VALUE(1)}: @tab The year
-@item @tab @code{VALUE(2)}: @tab The month
-@item @tab @code{VALUE(3)}: @tab The day of the month
-@item @tab @code{VALUE(4)}: @tab Time difference with UTC in minutes
-@item @tab @code{VALUE(5)}: @tab The hour of the day
-@item @tab @code{VALUE(6)}: @tab The minutes of the hour
-@item @tab @code{VALUE(7)}: @tab The seconds of the minute
-@item @tab @code{VALUE(8)}: @tab The milliseconds of the second
+@multitable @columnfractions .15 .70
+@item @code{VALUE(1)}: @tab The year
+@item @code{VALUE(2)}: @tab The month
+@item @code{VALUE(3)}: @tab The day of the month
+@item @code{VALUE(4)}: @tab Time difference with UTC in minutes
+@item @code{VALUE(5)}: @tab The hour of the day
+@item @code{VALUE(6)}: @tab The minutes of the hour
+@item @code{VALUE(7)}: @tab The seconds of the minute
+@item @code{VALUE(8)}: @tab The milliseconds of the second
@end multitable
@item @emph{Standard}:
--
2.31.1
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
On 5/22/21 1:39 PM, Andre Vehreschild via Gcc-patches wrote: Hi Steve and Jerry, thanks for the ok'ing. Committed as https://gcc.gnu.org/g:26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c and https://gcc.gnu.org/g:c4771b3438a8cd9afcef1762957b763f8df3fa6e (for the missing changelog entries). Hello. About the missing changelog entries. The will be added automatically by Daily bump. You can check it with: ./contrib/gcc-changelog/git_check_commit.py 26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c -p What's missing for you so that you pushed c4771b3438a8cd9afcef1762957b763f8df3fa6e? Thanks, Martin - Andre On Fri, 21 May 2021 19:38:00 -0700 Jerry D wrote: yes, please commit On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote: On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: Ping, ping! Please find attached a rebased version of the patch for the RANDOM_INIT issue with coarray Fortran. Nothing changed to the previous version, just rebased to current master. Regtested fine on x86_64-linux/f33. Ok for trunk? I think you've down your due diligence with 2 pings. I would commit. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
On 5/23/21 1:59 PM, Andre Vehreschild wrote: Hi Martin, thanks for pointing that out. I haven't committed for quite some time now and could not find on the webpage how this works nowadays. I was thinking that the special gcc-git-command should have added the Changelog entries automagically and immediately. That they are added by a daily bump is new to me. Thanks for giving me more insight. Sure, I'm fully aware that occasional committers are not aware of that. So do I need to revert the commit c4771b3438a8cd9afcef1762957b763f8df3fa6e to fix the Changelogs or how do we proceed from here? I've just done that. Is there a webpage which describes the current state-of-art of committing to gcc for folks that do not follow every discussion on the mailing lists? It's documented here: https://gcc.gnu.org/codingconventions.html#ChangeLogs But it's far from a good location. I'm going to improve it. Cheers, Martin Thanks for your help, Andre On Sat, 22 May 2021 19:58:57 +0200 Martin Liška wrote: On 5/22/21 1:39 PM, Andre Vehreschild via Gcc-patches wrote: Hi Steve and Jerry, thanks for the ok'ing. Committed as https://gcc.gnu.org/g:26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c and https://gcc.gnu.org/g:c4771b3438a8cd9afcef1762957b763f8df3fa6e (for the missing changelog entries). Hello. About the missing changelog entries. The will be added automatically by Daily bump. You can check it with: ./contrib/gcc-changelog/git_check_commit.py 26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c -p What's missing for you so that you pushed c4771b3438a8cd9afcef1762957b763f8df3fa6e? Thanks, Martin - Andre On Fri, 21 May 2021 19:38:00 -0700 Jerry D wrote: yes, please commit On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote: On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: Ping, ping! Please find attached a rebased version of the patch for the RANDOM_INIT issue with coarray Fortran. Nothing changed to the previous version, just rebased to current master. Regtested fine on x86_64-linux/f33. Ok for trunk? I think you've down your due diligence with 2 pings. I would commit. -- Andre Vehreschild * Email: vehre ad gmx dot de
[PATCH][pushed] docs: add missing @headitem in Intrinsic Procedures
Pushed as obvious.
Martin
gcc/fortran/ChangeLog:
* intrinsic.texi: Add missing @headitem to tables with a header.
---
gcc/fortran/intrinsic.texi | 144 ++---
1 file changed, 72 insertions(+), 72 deletions(-)
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 260dbaae76b..8a92b862070 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -462,7 +462,7 @@ end program test_abs
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name@tab Argument@tab Return type @tab
Standard
+@headitem Name@tab Argument@tab Return type @tab
Standard
@item @code{ABS(A)} @tab @code{REAL(4) A}@tab @code{REAL(4)}@tab
Fortran 77 and later
@item @code{CABS(A)} @tab @code{COMPLEX(4) A} @tab @code{REAL(4)}@tab
Fortran 77 and later
@item @code{DABS(A)} @tab @code{REAL(8) A}@tab @code{REAL(8)}@tab
Fortran 77 and later
@@ -627,7 +627,7 @@ end program test_acos
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name@tab Argument @tab Return type @tab Standard
+@headitem Name@tab Argument @tab Return type @tab
Standard
@item @code{ACOS(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)} @tab Fortran
77 and later
@item @code{DACOS(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)} @tab Fortran
77 and later
@end multitable
@@ -686,7 +686,7 @@ end program test_acosd
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name@tab Argument @tab Return type @tab Standard
+@headitem Name@tab Argument @tab Return type @tab
Standard
@item @code{ACOSD(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)} @tab GNU
extension
@item @code{DACOSD(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)} @tab GNU
extension
@end multitable
@@ -742,7 +742,7 @@ END PROGRAM
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name @tab Argument @tab Return type @tab
Standard
+@headitem Name @tab Argument @tab Return type @tab
Standard
@item @code{DACOSH(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab GNU
extension
@end multitable
@@ -891,7 +891,7 @@ end program test_aimag
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name @tab Argument@tab Return type @tab
Standard
+@headitem Name @tab Argument@tab Return type
@tab Standard
@item @code{AIMAG(Z)}@tab @code{COMPLEX Z}@tab @code{REAL} @tab
Fortran 77 and later
@item @code{DIMAG(Z)}@tab @code{COMPLEX(8) Z} @tab @code{REAL(8)} @tab
GNU extension
@item @code{IMAG(Z)} @tab @code{COMPLEX Z}@tab @code{REAL} @tab
GNU extension
@@ -951,7 +951,7 @@ end program test_aint
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name @tab Argument @tab Return type @tab Standard
+@headitem Name @tab Argument @tab Return type @tab
Standard
@item @code{AINT(A)} @tab @code{REAL(4) A} @tab @code{REAL(4)} @tab Fortran
77 and later
@item @code{DINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)} @tab Fortran
77 and later
@end multitable
@@ -1231,7 +1231,7 @@ end program test_anint
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name@tab Argument @tab Return type @tab Standard
+@headitem Name@tab Argument @tab Return type @tab
Standard
@item @code{ANINT(A)} @tab @code{REAL(4) A} @tab @code{REAL(4)} @tab
Fortran 77 and later
@item @code{DNINT(A)} @tab @code{REAL(8) A} @tab @code{REAL(8)} @tab Fortran
77 and later
@end multitable
@@ -1347,7 +1347,7 @@ end program test_asin
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name@tab Argument @tab Return type @tab
Standard
+@headitem Name@tab Argument @tab Return type @tab
Standard
@item @code{ASIN(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)}@tab
Fortran 77 and later
@item @code{DASIN(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab
Fortran 77 and later
@end multitable
@@ -1406,7 +1406,7 @@ end program test_asind
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
-@item Name@tab Argument @tab Return type @tab
Standard
+@headitem Name@tab Argument @tab Return type @tab
Standard
@item @code{ASIND(X)} @tab @code{REAL(4) X} @tab @code{REAL(4)}@tab GNU
extension
@item @code{DASIND(X)} @tab @code{REAL(8) X} @tab @code{REAL(8)}@tab GNU
extension
@end multitable
@@ -1462,7 +1462,7 @@ END PROGRAM
@item @emph{Specif
Re: [Patch ]Fortran/OpenMP: Extend defaultmap clause for OpenMP 5 [PR92568]
Hello.
I noticed the patch causes the following clang warnings:
gcc/fortran/dump-parse-tree.c:1786:11: warning: comparison of different
enumeration types in switch statement ('enum gfc_omp_defaultmap' and
'gfc_omp_defaultmap_category') [-Wenum-compare-switch]
gcc/fortran/dump-parse-tree.c:1787:11: warning: comparison of different
enumeration types in switch statement ('enum gfc_omp_defaultmap' and
'gfc_omp_defaultmap_category') [-Wenum-compare-switch]
gcc/fortran/dump-parse-tree.c:1788:11: warning: comparison of different
enumeration types in switch statement ('enum gfc_omp_defaultmap' and
'gfc_omp_defaultmap_category') [-Wenum-compare-switch]
gcc/fortran/dump-parse-tree.c:1789:11: warning: comparison of different
enumeration types in switch statement ('enum gfc_omp_defaultmap' and
'gfc_omp_defaultmap_category') [-Wenum-compare-switch]
Can you please take a look?
Martin
Help with PR102460
Hello. Can please anybody help me with a Fotran issue, where 'ENTRY' keyword causes having a function which ends on a smaller line number than it starts: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460#c7 Thanks, Martin
Re: [PATCH 0/5] Fortran manual updates
On 11/2/21 00:56, Sandra Loosemore wrote: I'll wait a couple days before committing these patches, in case anybody wants to give some feedback, especially on technical issues. Hello. Appreciate the work you did, but the patchset will cause quite some conflicts in the prepared Sphinx migration patch I've sent to the mailing list :/ Anyway, I will rebase my patches. For the future, are you planning doing similar documentation reorganization for a manual? Based on discussion with Gerald, I hope we can finish the transition before the end of this year. Thank you, Martin
Re: [PATCH 0/5] Fortran manual updates
On 11/2/21 15:48, Sandra Loosemore wrote: On 11/2/21 2:51 AM, Martin Liška wrote: On 11/2/21 00:56, Sandra Loosemore wrote: I'll wait a couple days before committing these patches, in case anybody wants to give some feedback, especially on technical issues. Hello. Appreciate the work you did, but the patchset will cause quite some conflicts in the prepared Sphinx migration patch I've sent to the mailing list :/ Anyway, I will rebase my patches. For the future, are you planning doing similar documentation reorganization for a manual? Based on discussion with Gerald, I hope we can finish the transition before the end of this year. My understanding was that, if this conversion is indeed going to happen, it's going to be automated by scripts? Exactly, but the conversion needs some manual post-processing that I've already done. I hadn't seen any discussion of it on the list for months and thought the whole idea was on hold or scrapped, since it hasn't happened yet. There was almost no response, so that's why I contacted Gerald about help. In any case it does not seem reasonable to freeze the current Texinfo docs for months while waiting for it to happen, especially as we are heading into the end of the release cycle and people are finishing up changes and new features they need to document. Sure, I can easily rebase normal changes, but you are suggesting a complete redesign/renaming. It's going to take me some time, but I'll rebase my patches. Thanks for understanding, Martin -Sandra
Re: [PATCH 0/5] Fortran manual updates
On 11/2/21 16:56, Sandra Loosemore wrote: On 11/2/21 9:20 AM, Martin Liška wrote: On 11/2/21 15:48, Sandra Loosemore wrote: On 11/2/21 2:51 AM, Martin Liška wrote: On 11/2/21 00:56, Sandra Loosemore wrote: I'll wait a couple days before committing these patches, in case anybody wants to give some feedback, especially on technical issues. Hello. Appreciate the work you did, but the patchset will cause quite some conflicts in the prepared Sphinx migration patch I've sent to the mailing list :/ Anyway, I will rebase my patches. For the future, are you planning doing similar documentation reorganization for a manual? Based on discussion with Gerald, I hope we can finish the transition before the end of this year. My understanding was that, if this conversion is indeed going to happen, it's going to be automated by scripts? Exactly, but the conversion needs some manual post-processing that I've already done. I hadn't seen any discussion of it on the list for months and thought the whole idea was on hold or scrapped, since it hasn't happened yet. There was almost no response, so that's why I contacted Gerald about help. I have to admit that I was buried in technical work at the time of the previous discussion (in fact, the Fortran things I am now trying to document), and didn't have time to look at the proposed changes in any detail. I have wondered, though, why it's necessary to do this change if people don't like the way Texinfo formats output, can't we fix Texinfo? That's a reasonable question. Well, I believe the technical dept (feature set) of Texinfo (compared to more modern tools) is significant and I don't want to spend my time hacking a HTML, Javascipt and so on. Moreover, Sphinx is massively used: https://www.sphinx-doc.org/en/master/examples.html and the tool is actively developed. Or hack it to translate the sources to something like DocBook instead, and then adopt that as our source format? I can write documentation in any markup format, but it seems to me that structured XML-based formats are a lot more amenable to scripted manipulation than either Texinfo or restructured text. If the rest of the community is set on Sphinx, I'm fine with that, but I kind of don't see the point, myself. :-S We think with David that DocBook is too complicated and a markup is a better choice (from that perspective, Texinfo is fine). In any case it does not seem reasonable to freeze the current Texinfo docs for months while waiting for it to happen, especially as we are heading into the end of the release cycle and people are finishing up changes and new features they need to document. Sure, I can easily rebase normal changes, but you are suggesting a complete redesign/renaming. It's going to take me some time, but I'll rebase my patches. Well, what I've done is hardly a "complete" redesign/renaming of the Fortran manual -- I've barely scratched the surface on it. My main goal was just to update the bit-rotten standards conformance sections, which were unfortunately spread among multiple places in the document. I did consolidate those few sections, but I did not make any big-picture changes to the organization of the manual, and I have not even reviewed any other parts of it for accuracy or relevance. I'd been thinking about making a pass to do some copy-editing things, like making sure all chapter/section titles use consistent title case capitalization, but I will hold off on that if it's going to cause problems. I see, thanks for doing that. Martin -Sandra
[PATCH] Remove dead Fortran function.
Hello.
The function was introduced in 2009 in
g:cf2b3c22a2cbd7f50db530ca9d2b14c70ba0359d
and has never been used since that.
Ready to be installed?
Thanks,
Martin
gcc/fortran/ChangeLog:
* symbol.c (gfc_get_ultimate_derived_super_type): Remove.
---
gcc/fortran/symbol.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 8c9a1d00ce0..173c36f51bc 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -5106,23 +5106,6 @@ gfc_get_derived_super_type (gfc_symbol* derived)
}
-/* Get the ultimate super-type of a given derived type. */
-
-static gfc_symbol*
-gfc_get_ultimate_derived_super_type (gfc_symbol* derived)
-{
- if (!derived->attr.extension)
-return NULL;
-
- derived = gfc_get_derived_super_type (derived);
-
- if (derived->attr.extension)
-return gfc_get_ultimate_derived_super_type (derived);
- else
-return derived;
-}
-
-
/* Check if a derived type t2 is an extension of (or equal to) a type t1. */
bool
--
2.33.1
Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
On 12/13/21 12:18, Manfred Schwarb via Fortran wrote: could you commit it for me? I do not have commit access. I can definitely do that, but please attach the patches as output of git format-patch so that git am can be directly used. Cheers, Martin
Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
On 12/14/21 01:22, Manfred Schwarb wrote: Am 13.12.21 um 13:29 schrieb Martin Liška: On 12/13/21 12:18, Manfred Schwarb via Fortran wrote: could you commit it for me? I do not have commit access. I can definitely do that, but please attach the patches as output of git format-patch so that git am can be directly used. Thanks. I do not have much experience with git, and I developed the patch the old-fashioned way. I tried "git format-patch", but this simply returned nothing. Sorry, I gave up for now. Never mind, I wrote a commit message title and pushed that as: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44aa890d8fb4afa843cf6cb7452fd5d6f3dd61fe https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f1215db08126fbd2d69d971d65611508cf83b4ae Thanks for patches, Martin Cheers, Manfred Cheers, Martin
