[RFC][PATCH] contrib: add git-commit-mklog wrapper
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: Hongtao Liu as x86 vectorization maintainer
On Mon, Jun 21, 2021 at 02:49:56AM +, Liu, Hongtao via Gcc wrote: > >-Original Message- > >From: Jason Merrill > >Sent: Monday, June 21, 2021 10:07 AM > >To: Liu, Hongtao > >Cc: gcc Mailing List ; Marek Polacek > >Subject: Hongtao Liu as x86 vectorization maintainer > > > >I am pleased to announce that the GCC Steering Committee has appointed > >Hongtao Liu as maintainer of the i386 vector extensions in GCC. > > > >Hongtao, please update your listing in the MAINTAINERS file. > > Updated, thanks. Congrats. You should also remove your Write After Approval entry, otherwise Running .../gcc/testsuite/gcc.src/maintainers.exp ... Redundant in write approval: Hongtao Liu FAIL: maintainers-verify.sh test fails. Jakub
Re: Hongtao Liu as x86 vectorization maintainer
On Tue, Jun 22, 2021 at 3:58 PM Jakub Jelinek via Gcc wrote: > > On Mon, Jun 21, 2021 at 02:49:56AM +, Liu, Hongtao via Gcc wrote: > > >-Original Message- > > >From: Jason Merrill > > >Sent: Monday, June 21, 2021 10:07 AM > > >To: Liu, Hongtao > > >Cc: gcc Mailing List ; Marek Polacek > > >Subject: Hongtao Liu as x86 vectorization maintainer > > > > > >I am pleased to announce that the GCC Steering Committee has appointed > > >Hongtao Liu as maintainer of the i386 vector extensions in GCC. > > > > > >Hongtao, please update your listing in the MAINTAINERS file. > > > > Updated, thanks. > > Congrats. > > You should also remove your Write After Approval entry, otherwise > Running .../gcc/testsuite/gcc.src/maintainers.exp ... > Redundant in write approval: Hongtao Liu > FAIL: maintainers-verify.sh > test fails. > Thanks for reminding, updated. > Jakub > -- BR, Hongtao
Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper
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
Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper
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: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
On Mon, Jun 21, 2021 at 7:36 AM Michael Matz wrote: > > Hello, > > On Thu, 17 Jun 2021, H.J. Lu via Gcc wrote: > > > > > • Disallow copy relocation against definition with the STV_PROTECTED > > > > visibility in the shared library with the marker. > > > > > > If this is for GNU ld x86 only, I'm fine with it:) > > > > > > gold and ld.lld just emit an error unconditionally. I think non-x86 > > > GNU ld ports which never support "copy relocations on protected data > > > symbols" may want to make the diagnostic unconditional as well. > > > Well, while (Michael Matz and ) I think compatibility check for "copy > > > relocations on protected data symbols" is over-engineering (and > > > Alan/Cary think it was a mistake), if you still want to add it, it is > > > fine for me... > > > For Clang, I hope we will not emit such a property, because Clang > > > never supports the "copy relocations on protected data symbols" > > > scheme. > > > > The issue is that libfoo.so used in link-time can be different from > > libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time > > has the default visibility. But foobar in libfoo.so at run-time can be > > protected. ld.so should detect such cases which can lead to run-time > > failures. > > Yes, but I think we can _unconditionally_ give an error in this case, even > without a marker. I view restricting visiblity of a symbol in furture Unconditionally issuing an error can be an option, but mandatory. Otherwise working binary today will fail to run tomorrow. > versions of shared libraries to be an ABI change, hence it has to be > something that either requires a soname bump or at the very least symbol To support existing binaries, we need a soname bump. > versioning with the old version staying on default visibility. Symbol versioning doesn't work here since both symbols are at the same address. > Compare the situation to one where the old libfoo.so provided a symbol > bar, and the new one doesn't (sort of very restricted visiblity). ld.so > will unconditionally give an error. I don't see this situation materially > different from bar's visibility be changed from default to protected. > > > > I think this can be unconditional, because the "pointer equality for > > > STV_PROTECTED function address in -shared" case hasn't been working > > > for GNU ld for at least 20 years... Many ports don't even produce a > > > dynamic relocation. > > > > True. But see above. You may not care about such use cases. But I > > believe that ld.so should not knowingly and silently allow such run-time > > failure to happen. > > Agreed, but giving an error message unconditionally wouldn't be silent. > > > Ciao, > Michael. -- H.J.
Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
Hello, On Tue, 22 Jun 2021, H.J. Lu wrote: > > > The issue is that libfoo.so used in link-time can be different from > > > libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time > > > has the default visibility. But foobar in libfoo.so at run-time can be > > > protected. ld.so should detect such cases which can lead to run-time > > > failures. > > > > Yes, but I think we can _unconditionally_ give an error in this case, even > > without a marker. I view restricting visiblity of a symbol in furture > > Unconditionally issuing an error can be an option, but mandatory. > Otherwise working binary today will fail to run tomorrow. Like a binary that's working today will fail tomorrow if the updated shared lib simply removes a symbol from it's export without proper versioning. I don't see a material difference. > > versions of shared libraries to be an ABI change, hence it has to be > > something that either requires a soname bump or at the very least symbol > > To support existing binaries, we need a soname bump. > > > versioning with the old version staying on default visibility. > > Symbol versioning doesn't work here since both symbols are at > the same address. I don't see why the address should matter. My point was that in the end the exported symbol table for such shared lib (where foobar was changed from default to protected visiblity) should have 1: 12345 42 FUNC GLOBAL DEFAULT 1 foobar@Old 2: 12345 42 FUNC GLOBAL PROTECTED 1 foobar@@New This might require new GAS directives and compiler attributes (or might be expressible already). References from within the shared library would need to continue going via the default visiblity symbol, so that it supports old binaries containing copy relocs, which just again points out that it's a bad idea to restrict visibility after the fact. AFAICS your scheme also doesn't support old binaries with newly protected symbols in newer shared libs, so an (unconditional) error in such situation seems appropriate. IOW: which scenario do you want to not error on when you want to make the error conditional? Ciao, Michael.
Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper
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: Progress update on extending static analyser to support c++'s virtual function
On Mon, 2021-06-21 at 14:22 +0530, Ankur Saini wrote:
> so I have a good news and a bad news
>
> good news is that I was successfully able to split the calls at every
> call-site during the creation of super-graph.
>
> I did it by simply adding an 'else’ statement where analyser handles
> splitting of snodes, so that it can still handle the known calls (
> one with a cgraph_edge ) and also split the calls at the unknown call
> sites for analyzer to later speculate the source of the call with
> more information from regional models.
>
> something like this :-
>
> in `ana::supergraph::supergraph(ana::logger*)` in supergraph.cc <
> http://supergraph.cc/>
>
> 185 if (cgraph_edge *edge = supergraph_call_edge (fun, stmt))
> 186 {
> 187 m_cgraph_edge_to_caller_prev_node.put(edge,
> node_for_stmts);
> 188 node_for_stmts = add_node (fun, bb, as_a
> (stmt), NULL);
> 189 m_cgraph_edge_to_caller_next_node.put (edge,
> node_for_stmts);
> 190 }
> 191 else
> 192 {
> 193 gcall *call = dyn_cast (stmt);
> 194 if (call)
> 195 node_for_stmts = add_node (fun, bb, as_a
> (stmt), NULL);
> 196 }
>
> after building I could see analyzer creating snodes for returning
> calls from the function it was not before for various examples.
>
Great. Have you made any progress on creating eedges/enodes for such
calls?
> —
>
> now the bad news.
>
> I accidentally overwrote the file containing my ssh key to
> gcc.gnu.org regarding the
> same ?
If you've overwritten the private key, then there's no way to get it
back (if I understand things correctly). You should create a new one
and contact overseers.
Dave
Re: Semantics of OBJ_TYPE_REF
Hi, On Fri, Jun 18 2021, Erick Ochoa via Gcc wrote: > Hi, > > I am having some trouble understanding the semantics of OBJ_TYPE_REF. > I understand that it is made of three operands: > > 1. OBJ_TYPE_REF_EXPR: An expression that evaluates the value to use. > 2. OBJ_TYPE_REF_OBJECT: Is the object on whose behalf the lookup is > being performed > 3. OBJ_TYPE_REF_TOKEN: An integer index to the virtual method table. > > The language here is very general and makes it hard for me to understand. Is > > 1. OBJ_TYPE_REF_EXPR: The virtual function well, it is never the actual function as in a FUNCTION_DECL, it is always a pointer to an unknown function. > 2. OBJ_TYPE_REF_OBJECT: The "this" object > > ? > > Why is the index needed if it looks like the virtual function is > already pointed to by the first operand? As I wrote above, the first operand is just a pointer. Sometimes other optimizations can figure out where it leads but often not (or not early enough for inlining). In some situations we can get at the actual DECL (and subsequently have a direct call) using type based devirtualization and for that we use the other two arguments of OBJ_TYPE_REF. See the big leading comment in ipa-devirt.c. > I am reading Hubicka's post > on devirtualization and Part II > (https://hubicka.blogspot.com/2014/01/devirtualization-in-c-part-2-low-level.html) > seems to agree with me on the example below. There is also no mention > of OBJ_TYPE_REF on part II, but there is on part III. I believe the gimple quoted there has been simplified to make it easier for the reader, since it does not describe the type-based devirtualization but how other optimizations can together deduce the call target, and so OBJ_TYPE_REF has been omitted not to confuse anyone. If you dump the IL for th example yourself, you will see OBJ_TYPE_REF in the earliest dumps and you will see that it disappears as soon as the call becomes direct. Hope this helps, Martin
