Your request is being processed
Hello You can get the last payment in your personal account. You need to manage it instantly or it will be removed. Click HERE To Acknowledge Your Payment Info Is Correct. Registered email: g...@gnu.org User ID: TB0MSXDVVC Enjoy & please let me know if all is well. Thank you! Allen E Marketer 202 Lower High Street Watford WD17 2EH United Kingdom You received this email because you are registered with Q Marketer. Unsubscribe here blue jean shake
Re: GCC Git hooks
Hello everyone, On Sat, Sep 14, 2019 at 04:53:17PM -0400, Jason Merrill wrote: > At Cauldron this weekend Joel offered to adjust his git hooks > (https://github.com/brobecke/git-hooks), which are already used by gdb > and glibc, to meet GCC's needs. Separately, Joseph volunteered to > deal with converting the gcc-www repository to git and dealing with > those hooks. > > I expect that Joel's hooks should work fine for gcc-www with minimal > changes, but that the main GCC repository will need more work for > bugzilla integration. > > The GCC SVN hooks initially look like pretty vanilla SVN hooks using > svnmailer (http://opensource.perlig.de/svnmailer/); the customized > part of the svnmailer.conf is just > > [libstdcxx] > for_paths = .*(libstdc..-v3)/.* > to_addr = libstdc++-...@gcc.gnu.org > > [java] > for_paths = .*(boehm-gc|fastjar|gcjx|gcc/java|libffi|libjava|zlib)/.* > to_addr = java-...@gcc.gnu.org > > [gccdefault] > to_addr = gcc-...@gcc.gnu.org > bugzilla_to_addr = gcc-bugzi...@gcc.gnu.org > > Pretty short...but the last line relies on Daniel's custom > bugzilla/svnmailer integration (attached below), and it looks like > Joel's hooks don't have anything comparable. Any thoughts about > adjusting Daniel's bugzilla.py vs. pulling in something like > http://www.theoldmonk.net/gitzilla/ ? Looking at the configuration file, I believe the git-hooks should have most, if not all, of the features that would be needed for the GCC repository. In particular, there is already a way to relay commits to third-party tools via calling of a script; GDB uses that to interface with their Bugzilla database. But before I say more I should point to the documentation which, for historical reasons, is available on the GDB wiki rather than the git-hooks GitHub repository. I will fix that, but in the meantime: https://sourceware.org/gdb/wiki/GitHooksUsersGuide I'm attaching a file called project.config, which shows the current configuration for the GDB repository, as it is might be a good starting point for GCC's configuration. Of interest: * We can see that "hooks.mailinglist" is pointing to a script. The purpose of that script is to determine, based on which files changed, which mailinglists should the commit email be sent to. * There is a hooks.style_checker line. Currently, GDB points to a script which does nothing. If GCC has some scripts they want to be run to validate the contents of a file, this is where this can be done. There is no mechanism, really, to say "don't run the style_checker", but it's easy to just pass a null style_checker as done by GDB. * For bugzilla integration, GDB uses the hooks.file-commit-cmd file. I'm attaching the email-to-bugzilla script, although I don't know how useful it will be for GCC. It predates the git-hooks and I just re-used it as is when we switched over to the git-hooks. Given that, it seems like the git-hooks might be ready to support all the needs of the GCC repository? We would need to: - write a script that determines the list of recipients based on the list of files being changed; that should be a trivial adaptation of the script used on the GDB side; - Adapt the script filing the commit with bugzilla - create a refs/meta/config "branch", and add the project.config file with the git-hooks configuration. I can definitely help with the configuration setup phase in whatever capacity you'd like. I would recommend people take a look at the list of options currently available to see what kind of initial configuration we might want to start with. -- Joel [hooks] from-domain = sourceware.org mailinglist = /git/binutils-gdb.git/hooks-bin/email_to.py # We do not want to force a maximum line length in commit # revision logs, as they get in the way of copy-pasting # debugging session, error messages, logs, etc. max-rh-line-length = 0 # Reject merge commits on a certain number of branches: # - on master: We request that people rebase their changes #before pushing instead (merge commits tend to confuse #git newcommers). # - on GDB release branches: There is a high risk that a merge #commit is a merge from master into the branch, which would #bring a lot more than what the user probably meant to push. #Request that the user cherry-pick his changes. reject-merge-commits = refs/heads/master,refs/heads/gdb-.* # The style checker, applied to the contents of each file being # modified. style-checker = /git/binutils-gdb.git/hooks-bin/style_checker # The URL where we can inspect the commit, inserted in the commit # notification email, and also copy sent to the file-commit-cmd. commit-url = "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=%(rev)s" # Do not send emails for the following branches (un
Re: GCC Git hooks
Hi Gerald, On Mon, Sep 16, 2019 at 12:15:57AM +0800, Gerald Pfeifer wrote: > On Sun, 15 Sep 2019, Joseph Myers wrote: > > Apart from general review of the test conversion / conversion and hook > > scripts, which everyone can do, I think the main thing would be to advise > > on what needs to happen to avoid breaking the www.gnu.org copy of the site > > and your HTML validation system for commits. > > I reached out to the GNU webmasters for the former. > > On the latter, let's just flip the switch whenever you're ready, and I'll > see to adjust my script within a day or two and manually perform checks > until that's done. (If you can create a sample e-mail notification for > me, I'll use that to start looking into it.) You mean the email notification sent by the hooks when a commit gets pushed? If yes, here is an example: https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00041.html -- Joel
Multi-Threading GCC Compiler Internal Data
Greetings Richard, I don't know if it's currently possible but whats the best way to either so about or use a tool to expose shared state at both the GIMPLE and RTL level. This would allow us to figure out much better what algorthims or data structures to choose to allow this to scale much better than the current prototype. Thanks, Nick
Re: [EXT] Re: Questions about initialization data during LTO
On 9/14/19 8:39 AM, Martin Liška wrote: On 9/13/19 3:01 PM, Gary Oblock wrote: So, back to my questions, any ideas about how to get initialization information? This is going to be a very powerful optimization for code with structures of arrays and I just need a little help getting around a few obstacles in my path. Sure. So I would point you to the IPA ICF pass, which makes merging of variables in WPA phase of LTO. Let's take a look at: ipa-icf.c:1839 (sem_variable::equals) where we do: if (DECL_INITIAL (decl) == error_mark_node && in_lto_p) dyn_cast (node)->get_constructor (); That's the way how load DECL_INITIAL of variables. Does it help you? Martin So Martin, let me get this straight, all of the initialization information can be fetched here? I ask this because I was under the impression that some of it was deleted and could not be recovered. The worst case scenario for my optimization (making it illegal) is if the user specified an initialization and the initialization disappeared without leaving a trace in the IR that it ever existed. Many thanks, Gary
Re: GCC Git hooks
On Mon, 16 Sep 2019, Gerald Pfeifer wrote: > On the latter, let's just flip the switch whenever you're ready, and I'll > see to adjust my script within a day or two and manually perform checks > until that's done. (If you can create a sample e-mail notification for > me, I'll use that to start looking into it.) The email notifications are the part most likely to change substantially at various points after the initial git conversion. The post-receive hook I sent uses post-receive-email as something easy to set up, but I fully expect we might end up using the AdaCore hooks for the wwwdocs repository as well as for the GCC sources, with some suitable configuration that is mostly the same between the repositories. I don't recommend using the emails to extract any metadata about the commits because the formatting of that information is likely to change. Rather, I suggest using the emails only as a signal that something has been pushed to the repository. You can then e.g. use "git rev-parse HEAD" before and after updating the local checkout to see what the old and new HEAD commits were, and "git diff --name-only" to list the modified, new or removed files (as in the posted hook). If you want to extract information about individual new commits (e.g. authors) then "git rev-list $old_HEAD..$new_HEAD" can be used to list the new commits present in $new_HEAD but not in $old_HEAD. -- Joseph S. Myers jos...@codesourcery.com
Re: [EXT] Re: Questions about initialization data during LTO
On 9/16/19 8:28 PM, Gary Oblock wrote: So Martin, let me get this straight, all of the initialization information can be fetched here? Yes. I ask this because I was under the impression that some of it was deleted and could not be recovered. No, that should not happen. Martin The worst case scenario for my optimization (making it illegal) is if the user specified an initialization and the initialization disappeared without leaving a trace in the IR that it ever existed.
Re: Multi-Threading GCC Compiler Internal Data
On Mon, 16 Sep 2019, Nicholas Krause wrote: > Greetings Richard, > > I don't know if it's currently possible but whats the best way to either so > about or > > use a tool to expose shared state at both the GIMPLE and RTL level. This > would > > allow us to figure out much better what algorthims or data structures to > choose > > to allow this to scale much better than the current prototype. You are mixing independent issues. Shared state needs to be identified and protected for correctness reasons. In some cases changing the data structure to be protected can make it cheaper to do so. The scaling of the current prototype is limited by the fraction of the compilation we parallelize as well as the granularity. Going forward the most useful things are a) reducing the amount of state that ends up being shared when we paralellize, b) increase the fraction of the compilation we paralellize by tackling RTL optimizations and the early GIMPLE pipeline The prototype showed that paralellization is beneficial and that it can be done with a reasonable amount of work. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 247165 (AG München)
