Re: Fixing gcc git logs
On Thu, Jan 2, 2020 at 4:00 AM Jerry wrote: > > In the following git log entry, I made a typo on the PR number in the > libgfortran ChangeLog file. I noticed this right after the git commit, > while editing the git log. > > So I quit the edit without saving and git reported that the commit was > aborted. > > Then I edited the my local ChangeLog file, did git add . and git commit > again. In this case the git log edit started as usual and I recopied > the correct text into my editor (VI) and saved it. The commit proceeded > as I expected. Then I did the git svn dcommit > > Well the git log ended up like this. How to fix? How to avoid? > > The 90274 should have been 90374. The actual committed files are OK. Not sure what you did wrong. I guess to fix it you need to make a separate commit and push that. In general, before you push your changes to some public tree, you can engage in various forms of history rewriting. For instance, if you forgot something or realized you made a mistake in your latest commit, you can fix the error, and then do a "git commit --amend" which instead of creating a new commit will add your changes to your previous commit. Another option is the interactive rebase (git rebase -i). That allows you to e.g. "squash" commits, that is, combine two or more commits into one. -- Janne Blomqvist
Re: Fixing gcc git logs
On 02/01/2020 02:00, Jerry wrote: > In the following git log entry, I made a typo on the PR number in the > libgfortran ChangeLog file. I noticed this right after the git commit, > while editing the git log. > > So I quit the edit without saving and git reported that the commit was > aborted. > > Then I edited the my local ChangeLog file, did git add . and git commit > again. In this case the git log edit started as usual and I recopied > the correct text into my editor (VI) and saved it. The commit proceeded > as I expected. Then I did the git svn dcommit > > Well the git log ended up like this. How to fix? How to avoid? > > The 90274 should have been 90374. The actual committed files are OK. > If you've not pushed the commit you have two options. If it's the head revision, you can use git commit --amend If it's earlier in your local history, you can use git rebase -i and then use (I think) 'reword' to reword the commit log for that commit. If you've pushed the branch to a public tree then it might be too late, depending on the push policy for branches (in gcc trunk we will not permit rewriting history in that way because it breaks other users trying to pull). Some more private branches might permit such rewriting of history. R. > Regards, > > Jerry > > commit 86e1d9f75bae096922664755d037f2a9d85e2a24 (HEAD -> trunk, > svn/trunk, origin/trunk, origin/master) > Author: jvdelisle > Date: Thu Jan 2 00:57:31 2020 + > > PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors. > > PR libfortran/90274 > * io/format.c (parse_format_list): Implement the E0 exponent > width to provide smallest possible width for exponent fields. > Refactor code for correct parsing and better readability of the > code. > * io/io.h (write_real_w0): Change interface to pass in pointer > to fnode. > * io/transfer.c: Update all calls to write_real_w0 to use the > new interface. > * io/write.c ((write_real_w0): Use the new interface with fnode > to access both the decimal precision and exponent widths > used in > build_float_string. > * io/write_float.def (build_float_string): Use the passed in > exponent width to calculate the used width in the case of E0. > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@279828 > 138bc75d-0d04-0410-961f-82ee72b054a4
Re: Proposal for the transition timetable for the move to GIT
On 02/01/2020 02:58, Alexandre Oliva wrote: > On Dec 30, 2019, "Richard Earnshaw (lists)" wrote: > >> Right, (and wrong). You have to understand how the release branches and >> tags are represented in CVS to understand why the SVN conversion is done >> this way. > > I'm curious and ignorant, is the convoluted representation that Maxim > described what SVN normally uses for tree copies, that any conversion > tool from SVN to GIT thus ought to be able to figure out, or is it just > an unusual artifact of the conversion from CVS to SVN, that we'd like to > fix in the conversion from SVN to GIT with some specialized recovery for > such errors in repos poorly converted from CVS? > > Thanks in advance for cluing me in, > I think it mostly comes from cvs2svn. You probably could manufacture something similar directly in SVN, but you'd have to try very hard to create such brain damage. Some thing like svn cp ^/trunk ^/branches/foo svn rm -f ^/branches/foo/fred.c svn cp ^/branches/bar/fred ^/branches/foo/fred.c ... svn ci Which would create a copy of trunk in foo with a copy of fred.c from the bar branch etc. Normal SVN copies to a branch use a simple node copy of the top-level directory, which is why branching in SVN is cheap (essentially O(1) in time). R.
Re: Fixing gcc git logs
On 1/2/20 11:49 AM, Richard Earnshaw wrote: On 02/01/2020 02:00, Jerry wrote: In the following git log entry, I made a typo on the PR number in the libgfortran ChangeLog file. I noticed this right after the git commit, while editing the git log. ... If you've pushed the branch to a public tree then it might be too late, depending on the push policy for branches (in gcc trunk we will not permit rewriting history in that way because it breaks other users trying to pull). Some more private branches might permit such rewriting of history. I am glad you explained it. Previously, the only reaction I got from git-cognoscenti was "Don't do that - it will ruin history for everybody!". Thanks ! Might 2020 be the year of git for GCC. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Frontend access to target-related options
On 1/1/20 4:31 AM, The Other wrote: Hi, I'm currently working on a Rust frontend for GCC. Rust has some language-level conditional compilation features based on the presence or lack of features in the target architecture (e.g. SSE, AVX, a static C runtime) as well as the target CPU architecture itself, target OS, and various other target-related information (such as pointer width and endianness). As such, the frontend parser requires this target-related option information to be available to it. I was wondering if there was an architecture-neutral way of accessing this data (if it is even stored). I've looked into options.h but I cannot figure out how to use it in an architecture-neutral way. Um, AVX and such are arch-specific. It sounds like you need some kind of (new?) langhook that targets can register? nathan -- Nathan Sidwell
Re: Fixing gcc git logs
On Thu, 2 Jan 2020 at 02:00, Jerry wrote: > > In the following git log entry, I made a typo on the PR number in the > libgfortran ChangeLog file. I noticed this right after the git commit, > while editing the git log. > > So I quit the edit without saving and git reported that the commit was > aborted. > > Then I edited the my local ChangeLog file, did git add . and git commit > again. In this case the git log edit started as usual and I recopied > the correct text into my editor (VI) and saved it. The commit proceeded > as I expected. Then I did the git svn dcommit N.B. before doing the 'git svn dcommit' you can always do 'git show' to see the most recent commit, to double-check it looks fine before doing the svn dcommit. That's your last chance to fix something. > Well the git log ended up like this. How to fix? How to avoid? I'm not sure what you're asking. How to avoid what? It looks like you just didn't paste the correct text into the editor. Git isn't going to revert to an older version of the git log text, which was never actually used. Maybe your clipboard had the old (bad) text still, and that's what you pasted. This looks like user error, not a Git problem. > The 90274 should have been 90374. The actual committed files are OK. > > Regards, > > Jerry > > commit 86e1d9f75bae096922664755d037f2a9d85e2a24 (HEAD -> trunk, > svn/trunk, origin/trunk, origin/master) This means the commit is already on svn/trunk, so you can't fix it now. That would alter the history of trunk, which we don't allow. > Author: jvdelisle > Date: Thu Jan 2 00:57:31 2020 + > > PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors. The good news is that the summary line above has the right number, which is probably what matters most in Git-land, as the summaries will be viewed often.
Information on Loop Blocking
One of the engineers here at Marvel was experimenting, at the user level, with GCC in a failed attempt to get loop blocking to do loop blocking. Here's basically his question. Exactly how does loop blocking work in GCC? I know this must involve the polyhedral optimization code so an explanation might get a little ugly but he's very bright fellow and can cope with it. Thank, Gary Oblock
Re: Information on Loop Blocking
On January 3, 2020 2:04:20 AM GMT+01:00, Gary Oblock wrote: >One of the engineers here at Marvel was experimenting, at the user >level, with GCC in a failed attempt >to get loop blocking to do loop blocking. Here's basically his >question. > > Exactly how does loop blocking work in GCC? > >I know this must involve the polyhedral optimization code so an >explanation might get a little ugly >but he's very bright fellow and can cope with it. Loop blocking is only done from polyhedral optimizations and it is done always with a fixed block size (there's a param) when dependence analysis allows it. Richard. >Thank, > >Gary Oblock
