Re: Branch and tag deletions
On 03/12/2019 22:43, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 08:10:37PM +, Richard Earnshaw (lists) wrote:
On 03/12/2019 18:56, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
But we could make an "old-svn" hierarchy or similar that just has
everything svn has now (and will never change, so it will never cause
conflicts).
Well that's true of /any/ renaming scheme for dead branches.
No, it is not. If you have a simple "deleted" hierarchy, to which you
add things, you will get conflicts. If you have one just for things
imported from SVN, it will never change (since SVN is set in stone after
the conversion), and there will not be conflicts.
But you've still got the ongoing branch death issue to deal with, and
that was my point. If you want to keep them, and you don't want them
polluting the working namespace, you have to do *some* renaming of them.
Sure, but how many of those will there be? This is a different scale
problem from that with the SVN branches and tags, which makes it a quite
different problem.
Over time, likely as many, if not more than for svn. In GIT branch
development is the norm for most developers. It's true that most of
those are private and get serialized before upstreaming (unless we move
to a different development model, but that's a different discussion),
but we will likely have at least as many public development branches in
git as we've ever had in SVN.
There's
nothing special about this one. On the other hand, there's nothing that
says that the renamed branch has to have exactly the same name as the
live one: it's a rename after all.
Renamed tags and branches are *useless*, we could just as well delete
them completely, if people can no longer find them.
They can be found, it's just that they don't appear in the standard list
since they aren't pulled by default from the upstream repository. It's
no different from the situation where if you clone from a clone, the
things in the local repository that are in refs/remotes are not pulled
into the secondary clone, unless you add an explicit fetch entry to your
remote's configuration, something like
[origin]
...
fetch = refs/deleted/*:refs/remotes/origin/deleted/*
No. If you rename a branch, you have to look at all thousands of branches
to see which one might be the one you wanted. Something with a similar
name hopefully?
I'm not saying things moved into some separate hierarchy. That is fine.
But that *will* give conflicts if you keep doing that on a live repo,
and then you *do* need real renames.
And you then cannot refer to things by name anymore. Which is the common
way we refer to anything.
The problem of naming can be pretty much solved by either putting the
year name in the branch when its created, so instead of 'fred' you
create 'fred_2020'. Now names are unique as long as you don't have two
in the same year; alternatively, you can add the date as part of the
renaming process as the branch dies - more likely then it would be the
year of closure. Either way, finding them is not hard later on, since
the prefix part is unchanged.
The other way to solve it is documentation. We have a web page which is
*supposed* to list all the development branches we have. When a branch
is renamed, the rename can be listed alongside the mark that the branch
is now dead.
d) releases should go into refs/{heads/tags}/releases (makes it clearer
to casual users of the repo that these are 'official')
What are releases? Release branches?
branches in the heads space, tags in the tags space.
Release branches and releases are a very different thing. A release
is some fixed source, like a tarball. A release branch is a branch, and
what code that is can (and will, and does) change.
Not that I have good suggestions how to make this less confusing. Well,
maybe we should keep calling it "gcc-9-branch" and "gcc-9_2_0-release"?
Branches are branches and appear in the heads name space, tags are tags
and appear in the tags name space. There's no way of confusing the two.
Plus, branches leave off the digits that aren't fixed during the life of
the branch. And if the branches are called releases/gcc-9 and the tags
releases/gcc-9.2 (no need for _ anymore, that's an anachronism from the
CVS days) then there's no ambiguity anyway.
To make it clear that these are "official" the release tags should be
signed with an "official" key, of course ;-)
Orthogonal to the git conversion, obviously they need signing; and
possibly we should restrict ability to move/rename branches in the
releases space to release managers to avoid accidents. I don't know if
that's feasible, but it's quite likely that it is.
It would be very inconvenient to not have the recent releases immediately
accessible, fwiw, but those could be just a copy. And then delete that
one after a branch is closed?
e) other general development branc
Re: [ C ] [ C++ ] Efficient Array Construction / Binary Payload Handling
On Sun, Dec 1, 2019 at 7:47 PM JeanHeyd Meneide wrote: > > Dear GCC Community, > > I have a bit of a question. I recently fixed up and deployed 2 > separate implementations of a paper I am working on for C and C++ > Standardization called #embed (found here - > https://thephd.github.io/vendor/future_cxx/papers/source/C%20-%20embed > ). > > I was trying to play with some of the semantics of implementing > this in GCC, beyond just doing plain expansion into an brace-init-list > of numbers. I noticed that that large payloads (firmware binary images > used in resets, lossless music data, generated config data, etc.) > takes quite a bit more memory and time to initialize and store in GCC; > Clang has much the same problem too, using ~2 GiB memory to handle a > 20 MiB array. > > My current working knowledge is that it takes a very long time to > parse, verify, and create a VECTOR_CST to use for array > initialization. I am wondering if it might be a good idea for > optimization purposes to introduce a new way of representing a blob of > binary data. > > I was able to get extremely fast speeds in a test implementation > by making a special builtin called __builtin_array with keyword tag > RID_BUILTIN_ARRAY. The preprocessor directive would expand to > __builtin_array and one of its arguments was a string literal encoded > as base64 representing the original resource's binary data (so it > could survive re-preprocessing the file untouched). I would decode the > string literal and then build a static array of tree type STRING_CST > with the actual data. > > It worked, but this approach required removing some type checks > in digest_init just to be able to fake-up a proper initialization from > a string literal. It also could not initialize data beyond `unsigned > char`, as that is what I had pinned the array representation to upon > creation of the STRING_CST. Using a STRING_CST is an iteresting idea and probably works well for most data. > I am new to this, and not really a compiler developer, so I was > wonder if anyone had any tips, tricks, or other places I should look > to learn something about better ways to do this or faster ways to > handle what is essentially large binary payloads! I appreciate any > feedback or thoughts tremendously. I think most constraints come from designated initializer processing and handling of symbolic constants that eventually generate relocations. I've once played with patches in this area, noting that we "waste" one INTEGER_CST counting the element number for each actual data element. For contiguous elements this could be elided. Note we also have "special" CONSTRUCTOR fields like RANGE_EXPR for repetitive data. Since the large initializers are usually in static initializers tied to variables another option is to replace the DECL_INITIAL CONSTRUCTOR tree node with a new BINARY_BLOB tree node containing a pointer to target encoded (compressed) data. Then the fastest alternative is to do as GCC did way back in the past, emit the initializer to final assembly immediately and not store it in memory (works only when designated initializer processing isn't needed). That removes the possibility of eliding the initializer by constant folding or dead code removal of course. For the programmer I'd advise to use separate objects for such data, possibly compiling it with -O0. With -O0 we could default to emitting the data immediately then... Richard. > Sincerely Yours, > JeanHeyd Meneide
Re: Questions about IPA/clones and new LTO pass
Hello. I'm adding the author of IPA CP and LTO subsystem maintainer. Martin
Re: LTO : question about get_untransformed_body
CC'ing Honza and Martin.
Re: Branch and tag deletions
Joseph Myers : > Eric, can Richard and I get direct write access to the gcc-conversion > repository? Waiting for merge requests to be merged is getting in the way > of fast iteration on incremental improvements to the conversion machinery, > it should be possible to get multiple incremental improvements a day into > the repository. Sure. I only found one "Richard Earnshaw" and one "Joseph Myers" on Gitlab, so I have given both Developer access. I changed thw branch protection rules so Developers can push. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Branch and tag deletions
On Wed, 4 Dec 2019, Eric S. Raymond wrote: > Joseph Myers : > > Eric, can Richard and I get direct write access to the gcc-conversion > > repository? Waiting for merge requests to be merged is getting in the way > > of fast iteration on incremental improvements to the conversion machinery, > > it should be possible to get multiple incremental improvements a day into > > the repository. > > Sure. I only found one "Richard Earnshaw" and one "Joseph Myers" on Gitlab, > so I have given both Developer access. I changed thw branch protection rules > so > Developers can push. Thanks! I've now merged the outstanding merge requests. -- Joseph S. Myers jos...@codesourcery.com
Re: LTO : question about get_untransformed_body
On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa wrote: > > Hi, > > I am trying to use the function: `cgraph_node::get_untransformed_body` during > the wpa stage of a SIMPLE_IPA_PASS transformation. While the execute function I think SIMPLE_IPA_PASSes have no "WPA" stage but run at LTRANS time (WPA transform stage). So you might simply see that not all bodies are available in your LTRANS unit? > is running, I need to access the body of a function in order to iterate over > the gimple instructions in the first basic block. I have found that the > majority of the cgraph_node will return successfully. However, there are some > functions which consistently produce a segmentation fault following this > stacktrace: > > ``` > 0xbc2adb crash_signal > /home/eochoa/code/gcc/gcc/toplev.c:328 > 0xa54858 lto_get_decl_name_mapping(lto_file_decl_data*, char const*) > /home/eochoa/code/gcc/gcc/lto-section-in.c:367 > 0x7030e7 cgraph_node::get_untransformed_body() > /home/eochoa/code/gcc/gcc/cgraph.c:3516 > 0x150613f get_bb1_callees > /home/eochoa/code/gcc/gcc/ipa-initcall-cp.c:737 > 0x150613f reach_nodes_via_bb1_dfs > ``` > > Is there a way for `cgraph_node::get_untransformed_body` to succeed > consistently? (I.e. are there some preconditions that I need to make sure are > in place before calling cgraph_node::get_untransformed_body? > > I am using gcc version 10.0.0 20191127 (experimental) > > Thanks
Re: Branch and tag deletions
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote: > > Thanks. Do other people have comments on the list? > > > > I'm going to add one vendor tag that should be uncontroversial to the > > list. /tags/gcc-1766 is a misnamed Apple tag, and there is already a > > properly named copy with identical contents at /tags/apple/gcc-1766 so > > deleting /tags/gcc-1766 should be safe. > > > > I've looked through the list; I don't see anything that looks like it would be > especially controversial. I've deleted /tags/gcc-1766 as a misnamed and duplicate tag. I'll plan to delete the other 640 tags later today in the absence of objections. (It's actually 640 not 645 because 5 tags appear twice in the list as having names matching both "merge" and "branchpoint".) -- Joseph S. Myers jos...@codesourcery.com
http://www.netgull.com mirror broken
http://www.netgull.com has gcc snapshots and releases, but in the past few weeks only the diffs are there - none of the actual source tarballs are present. I am not sure how to get this message through to netball, but I figured you had a better chance than I. Thanks for GCC! Dan Allen Idaho Falls, ID
Re: LTO : question about get_untransformed_body
On 2019-12-04 7:52 a.m., Richard Biener wrote: > On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa > wrote: >> >> Hi, >> >> I am trying to use the function: `cgraph_node::get_untransformed_body` during >> the wpa stage of a SIMPLE_IPA_PASS transformation. While the execute function > > I think SIMPLE_IPA_PASSes have no "WPA" stage but run at LTRANS time > (WPA transform stage). So you might simply see that not all bodies are > available in your LTRANS unit? > This makes a lot of sense, and it is indeed documented in the GCC internals manual: A small inter-procedural pass (SIMPLE_IPA_PASS) is a pass that does everything at once and thus it can not be executed during WPA in WHOPR mode. It defines only the Execute stage and during this stage it accesses and modifies the function bodies. Such passes are useful for optimization at LGEN or LTRANS time and are used, for example, to implement early optimization before writing object files. I got confused because the dump_file for my pass includes the substring 'wpa'. Should I file a bug to change the name of the dumpfile to something more like `ltrans*`? Thanks for your help! >> is running, I need to access the body of a function in order to iterate over >> the gimple instructions in the first basic block. I have found that the >> majority of the cgraph_node will return successfully. However, there are some >> functions which consistently produce a segmentation fault following this >> stacktrace: >> >> ``` >> 0xbc2adb crash_signal >> /home/eochoa/code/gcc/gcc/toplev.c:328 >> 0xa54858 lto_get_decl_name_mapping(lto_file_decl_data*, char const*) >> /home/eochoa/code/gcc/gcc/lto-section-in.c:367 >> 0x7030e7 cgraph_node::get_untransformed_body() >> /home/eochoa/code/gcc/gcc/cgraph.c:3516 >> 0x150613f get_bb1_callees >> /home/eochoa/code/gcc/gcc/ipa-initcall-cp.c:737 >> 0x150613f reach_nodes_via_bb1_dfs >> ``` >> >> Is there a way for `cgraph_node::get_untransformed_body` to succeed >> consistently? (I.e. are there some preconditions that I need to make sure are >> in place before calling cgraph_node::get_untransformed_body? >> >> I am using gcc version 10.0.0 20191127 (experimental) >> >> Thanks
Re: Questions about IPA/clones and new LTO pass
Hi, this refers to https://gcc.gnu.org/ml/gcc/2019-11/msg00251.html On 2019-12-04 6:30 a.m., Martin Liška wrote: > Hello. > > I'm adding the author of IPA CP and LTO subsystem maintainer. > > Martin
Re: Branch and tag deletions
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> On 03/12/2019 15:05, Joseph Myers wrote:
> > On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> >
> > > a) Only live development branches get moved to the normal git namespace,
> > > but
> > > see d) & e) below
> >
> > Where do you suggest dead development branches should go? (We have
> > /branches/dead at present in SVN but hardly anything there; most dead
> > development branches are just in /branches.)
>
> Well, like 'deleted', we could move them out of the normally synced namespace;
> I don't have a strong preference, however, so what would you propose?
In my current script (adjust-refs in the gcc-conversion repository;
limited testing done based on a GCC repository conversion from last week,
running a fresh conversion now with vendor tags kept for more testing),
I'm using refs/dead/heads for any branch that's not identified as a
release branch (those go in refs/heads/releases), is not identified as
associated with a vendor (those go in refs/vendors//heads), and has
not received any commits since the start of December 2017. The
development branches that have received commits since then end up in
refs/heads/devel:
refs/heads/devel/c++-coroutines
refs/heads/devel/c++-modules
refs/heads/devel/c++-name-lookup
refs/heads/devel/gccgo
refs/heads/devel/gfortran-caf
refs/heads/devel/gimple-linterchange
refs/heads/devel/gomp-5_0-branch
refs/heads/devel/ira-select
refs/heads/devel/range-gen3
refs/heads/devel/ranger
refs/heads/devel/ssa-range
refs/heads/devel/unified-autovect
Given the limited number of such active development branches, I suspect
most people developing on branches are doing so on git-only branches in
the git mirror because they find git much more convenient for working with
branches.
I've also added a script add-git-svn-history to the gcc-conversion
repository, that runs a single git fetch command to make the version of
history from the old mirror available in refs/git-old/ and
refs/git-svn-old/ (at a cost of making the repository about 0.3 GB bigger
on the server). My expectation for active git-only development branches
is that the branch maintainer will rebase a copy of the branch onto the
cleanly converted history and then put that rebased copy in
refs/heads/devel/, rather than continuing development on the branch in
refs/git-old/ based on the old version of the history.
(Note for people doing such rebasing: if the branch has had merges to it,
it's possible that rebasing might go most smoothly if done in two stages:
first rebase on top of the most recent commit, in the git-svn history,
from which you've merged, to get rid of the merge commits from the
history, then rebase on top of the corresponding commit in the new cleanly
converted history. It's best to avoid commits from the git-svn version of
the history ending up in the ancestry of active branches based on the
clean conversion of the history.)
> > > d) releases should go into refs/{heads/tags}/releases (makes it clearer to
> > > casual users of the repo that these are 'official')
> >
> > Do you have a particular naming suggestion in there, e.g.
> > refs/heads/releases/9 and refs/tags/releases/9.1 (with the ".0" included
> > in tag names for old releases to avoid conflict with the branch name), or
> > with "gcc" or "branch" etc. in names as at present?
>
> I think I'd drop 'release' and use something like releases/gcc-9.1, then for
> the historical egcs releases egcs-.
My script also has some such tags g77-*, libf2c-* (it was necessary to
distinguish very similarly named tags such as g77-0_5_21 and g77_0_5_21,
where it appeared one tag contained gcc/f/ and the other contained
libf2c/), libgcj-*.
> For the branches, just gcc-9 - I don't see the point in having a redundant
> -branch on the name.
My script has a special case to use the name
refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because
there's also refs/tags/releases/gcc-2.95.2.1, and while technically git
allows you to have refs/heads/ and refs/tags/ both present,
it's a bad idea to do so because "git checkout releases/gcc-2.95.2.1"
would be confusing if you expected it to check out one of the tag and the
branch and git chose to check out the other. (Other such ambiguities are
dealt with by putting ".0" on the names of some tags.)
> > Some of the tags I did not propose deleting are tags for past prereleases
> > (we shouldn't need such tags for new -rc versions because a git commit id
> > suffices to identify them) and need an appropriate place in git, which
> > could also be in refs/tags/releases. Some are for releases or prereleases
> > of subprojects that had such releases on their own (e.g. g77, libgcj,
> > libstdc++). We need to establish where those would go in git. There are
> > also a few miscellaneous tags such as "start" and "first-egcs-checkin".
>
> We could have another space for rc's alphas, etc, refs/heads/rc would work as
> well as any
Re: Branch and tag deletions
On Wed, Dec 04, 2019 at 06:25:21PM +, Joseph Myers wrote: > In my current script (adjust-refs in the gcc-conversion repository; > limited testing done based on a GCC repository conversion from last week, > running a fresh conversion now with vendor tags kept for more testing), > I'm using refs/dead/heads for any branch that's not identified as a > release branch (those go in refs/heads/releases), is not identified as > associated with a vendor (those go in refs/vendors//heads), and has > not received any commits since the start of December 2017. The > development branches that have received commits since then end up in > refs/heads/devel: > > refs/heads/devel/c++-coroutines > refs/heads/devel/c++-modules > refs/heads/devel/c++-name-lookup > refs/heads/devel/gccgo > refs/heads/devel/gfortran-caf > refs/heads/devel/gimple-linterchange > refs/heads/devel/gomp-5_0-branch > refs/heads/devel/ira-select > refs/heads/devel/range-gen3 > refs/heads/devel/ranger > refs/heads/devel/ssa-range > refs/heads/devel/unified-autovect > > Given the limited number of such active development branches, I suspect > most people developing on branches are doing so on git-only branches in > the git mirror because they find git much more convenient for working with > branches. There are only 61 non-user branches on the git mirror, and that includes the release branches, so just 46 actually (and gccgo is in SVN as well): fsf/archer-expr-plugin fsf/asan fsf/avx2 fsf/cilkplus fsf/cilkplus-4_7-branch fsf/cilkplus-4_8-branch fsf/cilkplus-merge fsf/concepts-cxx2a fsf/constexpr fsf/cxx-conversion fsf/cxx-mem-model fsf/fortran-dev fsf/gc-improv fsf/gcc-4_0-branch fsf/gcc-4_1-branch fsf/gcc-4_2-branch fsf/gcc-4_3-branch fsf/gcc-4_4-branch fsf/gcc-4_5-branch fsf/gcc-4_6-branch fsf/gcc-4_7-branch fsf/gcc-4_8-branch fsf/gcc-4_9-branch fsf/gcc-5-branch fsf/gcc-6-branch fsf/gcc-7-branch fsf/gcc-8-branch fsf/gcc-9-branch fsf/gccgo fsf/gccpy fsf/gccrs fsf/gcn fsf/gimple-classes-v2-option-3 fsf/gimple-front-end fsf/gimplefe fsf/gomp-nvptx fsf/graphite fsf/hsa fsf/ifunc fsf/lw-ipo fsf/master fsf/melt-branch fsf/microblaze fsf/modules-ex fsf/openacc-gcc-7-branch fsf/openacc-gcc-8-branch fsf/openacc-gcc-9-branch fsf/pph fsf/profile-stdlib fsf/python fsf/reload-v2a fsf/split fsf/spu-4_5-branch fsf/sve fsf/transactional-memory fsf/trunk fsf/type-promotion-pass fsf/ubsan fsf/vect256 fsf/vtv fsf/x32 (fsf is my namespace for refs from the git mirror: [remote "fsf"] url = git://gcc.gnu.org/git/gcc.git fetch = +refs/heads/*:refs/remotes/fsf/* fetch = +refs/remotes/*:refs/remotes/svn/* prune = true ). (There are 183 user branches in the git mirror). > My expectation for active git-only development branches > is that the branch maintainer will rebase a copy of the branch onto the > cleanly converted history and then put that rebased copy in > refs/heads/devel/, rather than continuing development on the branch in > refs/git-old/ based on the old version of the history. We should make everything in git-old read-only. It is old, it is history, it should no longer change. > My script has a special case to use the name > refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because > there's also refs/tags/releases/gcc-2.95.2.1, and while technically git > allows you to have refs/heads/ and refs/tags/ both present, > it's a bad idea to do so because "git checkout releases/gcc-2.95.2.1" > would be confusing if you expected it to check out one of the tag and the > branch and git chose to check out the other. (Other such ambiguities are > dealt with by putting ".0" on the names of some tags.) And, as I said before, a release branch is a totally different animal from releases (release tags). We do this correctly now, let's keep it that way? Segher
Re: Branch and tag deletions
On Wed, 4 Dec 2019, Segher Boessenkool wrote: > > My script has a special case to use the name > > refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because > > there's also refs/tags/releases/gcc-2.95.2.1, and while technically git > > allows you to have refs/heads/ and refs/tags/ both present, > > it's a bad idea to do so because "git checkout releases/gcc-2.95.2.1" > > would be confusing if you expected it to check out one of the tag and the > > branch and git chose to check out the other. (Other such ambiguities are > > dealt with by putting ".0" on the names of some tags.) > > And, as I said before, a release branch is a totally different animal > from releases (release tags). We do this correctly now, let's keep it > that way? By convention, a branch in SVN lives in /branches and a branch in git lives in refs/heads/, whereas a tag in SVN lives in /tags and a tag in git lives in refs/tags/. This doesn't require any particular naming convention within those directories, but it's helpful to avoid actually having a branch and a tag with the same name. My script is implementing one possible naming convention suggested by Richard (and thus trying to make the names of release branches and tags a bit more consistent than they are at present). The avoidance of '.' in branch and tag names is, I'm pretty sure, a legacy of CVS restrictions on valid names for branches and tags. Those restrictions are not relevant to git or SVN; if picking any new convention it seems appropriate for the tag for GCC 10.1 to say "10.1" somewhere in its name rather than "10_1". -- Joseph S. Myers jos...@codesourcery.com
Re: PPC64 libmvec implementation of sincos
‐‐‐ Original Message ‐‐‐ On Wednesday, November 27, 2019 3:19 AM, Richard Biener wrote: ... > > Questions: > > > > 1. Should we aim to provide a vectorized version of __builtin_cexpi? If > > so, it would have > > to be a PPC64-only vector __builtin-cexpi, right? > > > > 2. Or should we require that vectorized sincos be available only when > > -fno-builtin-sincos flag > > is used in compilation? > > > > > > I don't think we need to fix both types of vectorization failures in order > > to obtain sincos > > vectorization. > > I think we should have a vectorized cexpi since that's having a sane > ABI. The complex > return type of cexpi makes it a little awkward for the vectorizer but > handling this should > be manageable. It's a bit difficult to expose complex types to the > vectorizer since > most cases are lowered early. > I'm trying to identify the source code which needs modification but I need help proceeding. I am comparing two compilations: The first is a simple file with a call to sin in a loop. Vectorization succeeds. The second is an almost identical file but with a call to sincos in the loop. Vectorization fails. In gdb, the earliest code location where the two compilations differ is in function number_of_iterations_exit_assumptions in file tree-ssa-loop-niter.c. Line op0 = gimple_cond_lhs (stmt); returns a tree which when analyzed in function instantiate_scev_r (in file tree-scalar-evolution.c) results in the first branch of the switch being taken for sincos. For sin, the 2nd branch of the switch is taken. How can I correlate stmt in the source line above to the relevant line in any dump among those created using debugging dump option -fdump-tree-all? Thanks. Bert.
Re: Branch and tag deletions
On Wed, Dec 04, 2019 at 08:37:17PM +, Joseph Myers wrote: > On Wed, 4 Dec 2019, Segher Boessenkool wrote: > > And, as I said before, a release branch is a totally different animal > > from releases (release tags). We do this correctly now, let's keep it > > that way? > > By convention, a branch in SVN lives in /branches and a branch in git > lives in refs/heads/, whereas a tag in SVN lives in /tags and a tag in git > lives in refs/tags/. This doesn't require any particular naming > convention within those directories, but it's helpful to avoid actually > having a branch and a tag with the same name. Yes, exactly. It's inconvenient and confusing in multiple ways to have the same names for branches and tags. > The avoidance of '.' in branch and tag names is, I'm pretty sure, a legacy > of CVS restrictions on valid names for branches and tags. Those > restrictions are not relevant to git or SVN; if picking any new convention > it seems appropriate for the tag for GCC 10.1 to say "10.1" somewhere in > its name rather than "10_1". Avoiding underscores is always welcome :-) Segher
Re: Branch and tag deletions
Here is a very preliminary list of refs after postprocessing by my script, to indicate what the ref layout would look like. We can easily change the script if we'd like some other layout. Note that some refs here will go away after deleting corresponding tags in SVN, while others are missing because of some reposurgeon bugs I'll now report. refs/dead/heads/BOEHM refs/dead/heads/C11 refs/dead/heads/C11-atomic refs/dead/heads/CLASSPATH refs/dead/heads/CYGNUS refs/dead/heads/FSF refs/dead/heads/FastFixinc refs/dead/heads/NET refs/dead/heads/Netlib_branch refs/dead/heads/SGI refs/dead/heads/addressing-modes refs/dead/heads/alias-export refs/dead/heads/alias-improvements refs/dead/heads/annotalysis refs/dead/heads/arc-20081210-branch refs/dead/heads/arc-4_4-20090909-branch refs/dead/heads/arc-4_4-branch refs/dead/heads/arc-milepost-branch refs/dead/heads/asan refs/dead/heads/ast-optimizer-branch refs/dead/heads/autovect-branch refs/dead/heads/avx2 refs/dead/heads/avx512 refs/dead/heads/avx512-vlbwdq refs/dead/heads/bnw-simple-branch refs/dead/heads/boehm refs/dead/heads/boehms-gc refs/dead/heads/bonzini-4_2-branch-pr32004-reverted refs/dead/heads/bounded-pointers-branch refs/dead/heads/c++-compat-branch refs/dead/heads/c++-concepts refs/dead/heads/c++-delayed-folding refs/dead/heads/c-4_5-branch refs/dead/heads/cell-4_3-branch refs/dead/heads/cell-4_4-branch refs/dead/heads/cfg-branch refs/dead/heads/cfo-branch refs/dead/heads/cilkplus refs/dead/heads/cilkplus-4_7-branch refs/dead/heads/cilkplus-4_8-branch refs/dead/heads/classpath-generics refs/dead/heads/clm-micromips refs/dead/heads/compile-server-branch refs/dead/heads/conceptgcc-branch refs/dead/heads/cond-optab refs/dead/heads/condate refs/dead/heads/condexec-branch refs/dead/heads/cp-parser-branch refs/dead/heads/cp-parser-branch-2 refs/dead/heads/cxx-conversion refs/dead/heads/cxx-lockfree refs/dead/heads/cxx-mem-model refs/dead/heads/cxx-reflection-branch refs/dead/heads/cxx0x-concepts-branch refs/dead/heads/cxx0x-lambdas-branch refs/dead/heads/cygming331 refs/dead/heads/cygming332 refs/dead/heads/cygnus refs/dead/heads/cygwin-improvements refs/dead/heads/cygwin-mingw-gcc-3_1-branch refs/dead/heads/cygwin-mingw-gcc-3_2-branch refs/dead/heads/cygwin-mingw-gcc-3_2_1-branch refs/dead/heads/cygwin-mingw-v2-branch refs/dead/heads/darwin-pic-rewrite refs/dead/heads/dataflow-branch refs/dead/heads/debuglocus refs/dead/heads/devo_gcc_testsuite refs/dead/heads/dfa-branch refs/dead/heads/dfp-branch refs/dead/heads/diagnostics-branch refs/dead/heads/dwarf4 refs/dead/heads/edge-vector-branch refs/dead/heads/egcs refs/dead/heads/egcs_gc_branch refs/dead/heads/endian-branch refs/dead/heads/escape-analysis refs/dead/heads/f_torture refs/dead/heads/faster-compiler-branch refs/dead/heads/fe-interface refs/dead/heads/ffixinc-branch refs/dead/heads/fixed-point refs/dead/heads/fixincl-branch refs/dead/heads/fortran-caf refs/dead/heads/fortran-dev refs/dead/heads/fortran-experiments refs/dead/heads/function-specific-branch refs/dead/heads/g77-0_6-branch refs/dead/heads/g77-net-runtime refs/dead/heads/g77_0_0_21_970811 refs/dead/heads/gc-improv refs/dead/heads/gcc-3_3-e500-branch refs/dead/heads/gcc-3_4-basic-improvements-branch refs/dead/heads/gcc-3_4-e500-branch refs/dead/heads/gcc-3_5-integration-branch refs/dead/heads/gcc-4_4-plugins refs/dead/heads/gcc-in-cxx refs/dead/heads/gcc-pre-vn refs/dead/heads/gcc3 refs/dead/heads/gcj-abi-2-dev-branch refs/dead/heads/gcj-eclipse refs/dead/heads/gcj-eclipse-jmx refs/dead/heads/gcj/gcj-abi-experimental-branch refs/dead/heads/gcj/gcj-abi-stabilization-branch refs/dead/heads/gcj/gcj-deletion-branch refs/dead/heads/gcj/gcj-eabi-branch refs/dead/heads/gcj/gcj-tls-experimental-branch refs/dead/heads/gcjx-branch refs/dead/heads/gimple-atomic refs/dead/heads/gimple-back-end refs/dead/heads/gimple-front-end refs/dead/heads/gimple-tuples-branch refs/dead/heads/glibc-2_0_x refs/dead/heads/gnu-win32-b20-branch refs/dead/heads/gomp-20050608-branch refs/dead/heads/gomp-3_0-branch refs/dead/heads/gomp-3_1-branch refs/dead/heads/gomp-4_0-branch refs/dead/heads/gomp-4_1-branch refs/dead/heads/gomp-4_5-branch refs/dead/heads/graphite refs/dead/heads/gupc refs/dead/heads/gupc-5-branch refs/dead/heads/gupc-6-branch refs/dead/heads/hammer-3_3-branch refs/dead/heads/hot-cold-branch refs/dead/heads/hsa refs/dead/heads/ia64-fp-model-branch refs/dead/heads/ia64-improvements refs/dead/heads/ici-20091108-branch refs/dead/heads/ifunc refs/dead/heads/immuse-rewrite-branch refs/dead/heads/improved-aliasing-branch refs/dead/heads/incremental-compiler refs/dead/heads/insn-select refs/dead/heads/ipa-branch refs/dead/heads/ira refs/dead/heads/ira-improv refs/dead/heads/itanium-sched-branch refs/dead/heads/java-gui-20050128-branch refs/dead/heads/java-gui-branch refs/dead/heads/killloop-branch refs/dead/heads/libada-branch refs/dead/heads/libada-gnattools-branch refs/dead/heads/libbid refs/dead/heads/libgcc-toplevel refs/dead/heads/libobjc-branch refs/dead
Re: Commit messages and the move to git
On 02/12/2019 10:54, Richard Earnshaw (lists) wrote: > On 19/11/2019 14:56, Jason Merrill wrote: >> On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) < >> richard.earns...@arm.com> wrote: >> >>> On 18/11/2019 20:53, Jason Merrill wrote: On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > On Mon, Nov 18, 2019 at 07:21:22PM +, Richard Earnshaw (lists) >>> wrote: >> On 18/11/2019 18:53, Segher Boessenkool wrote: >>> PR target/92140: clang vs gcc optimizing with adc/sbb >>> PR fortran/91926: assumed rank optional >>> PR tree-optimization/91532: [SVE] Redundant predicated store in > gcc.target/aarch64/fmla_2.c >>> PR tree-optimization/92161: ICE in >>> vect_get_vec_def_for_stmt_copy, at > tree-vect-stmts.c:1687 >>> PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction, > at tree-vect-loop.c:4252 >>> PR c++/92015: internal compiler error: in >>> cxx_eval_array_reference, at > cp/constexpr.c:2568 >>> PR tree-optimization/92173: ICE in optab_for_tree_code, at > optabs-tree.c:81 >>> PR tree-optimization/92173: ICE in optab_for_tree_code, at > optabs-tree.c:81 >>> PR fortran/92174: runtime error: index 15 out of bounds for type > 'gfc_expr *[15] >>> >>> Most of these aren't helpful at all, and none of these are good >>> commit >>> summaries. The PR92173 one actually has identical commit messages >>> btw, >>> huh. Ah, the second one (r277288) has the wrong changelog, but >>> in the >>> actual changelog file as well, not something any tool could fix >>> up (or >>> have we reached the singularity?) >> >> Identical commits are normally from where the same commit is made to >> multiple branches. It's not uncommon to see this when bugs are >> fixed. > > This is an actual mistake. The commits are not identical at all, just > the commit messages are (and the changelog entries, too). Not > something > that happens to ften, but of course I hit it in the first random > thing I > pick :-) > >> Ultimately the question here is whether something like the above is >>> more >> or less useful than what we have today, which is summary lines of the > form: >> >> > > I already said I would prefer things like > Patch related to PR323 > as the patch subject lines. No one argues that the current state of > affairs is good. I argue that replacing this with often wrong and > irrelevant information isn't the best we can do. > How about using the first line that isn't a ChangeLog date/author line, without trying to rewrite/augment it? Jason >>> >>> It would certainly be another way of doing it. Sometimes it would >>> produce almost the same as an unadulterated PR; sometimes it would >>> produce something more meaningful and sometimes it would be pretty >>> useless. It probably would hit more cases than my current script in >>> that it wouldn't require the commit to mention a PR in it. >>> >>> The main problem is that the first line is often incomplete, and much of >>> it is also wasted with elements like the full path to a file that is >>> quite deep in the tree. Lets take a quick example (the first I found in >>> the dump I have). >>> >>> 1998-12-17 Vladimir N. Makarov >>> * config/i60/i960.md (extendqihi2): Fix typo (usage ',' >>> instead of >>> ';'). >>> 1998-12-17 Michael Tiemann >>> * i960.md (extend*, zero_extend*): Don't generate rtl that >>> looks >>> like (subreg:SI (reg:SI N) 0), because it's wrong, and it hides >>> optimizations from the combiner. >>> >>> Firstly, this example misses a blank line between the author and the >>> change message itself, which makes distinguishing between this and the >>> multiple authors case harder. Secondly, the entry really spans two >>> lines and cutting it off at the end of the first line would be, well a >>> bit odd. We could try to piece things together more, by combining lines >>> until we find a sentence end ( \.$ or \.\s\s ), and we could also strip >>> off more of the path components to just leave the name of the file >>> committed. For example, >>> >>> i960.md (extendqihi2): Fix typo (usage ',' instead of ';'). >>> >>> That might work better, but obviously it's harder to handle and thus >>> more likely to create erroneous summaries. >>> >> >> Yep. I don't think we need to worry about getting optimal one-line >> summaries for ancient commits; something reasonably unique should be >> plenty. >> > > Attached is the latest version of my script. I used (very nearly) this > to produce a conversion over the weekend and I've uploaded that here: > > https://gitlab.com/rearnsha/gcc-trial-20191130 > > Note, that I might blow this away at any time. IT IS NOT A FINAL > CONVERSION. > > Some other things to note: > -
