On 03/12/2019 00:56, Segher Boessenkool wrote:
On Mon, Dec 02, 2019 at 08:37:14PM +, Joseph Myers wrote:
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
Thanks for the list. As far as I can see all of those are no longer
useful, so they could be jut deleted from the SVN repo (if everyone
els
On 03/12/2019 00:47, Segher Boessenkool wrote:
On Mon, Dec 02, 2019 at 08:24:47PM +, Joseph Myers wrote:
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
Sure; I'm just saying rewriting old commit messages in such a style that
they keep standing out from new ones is a bit of a weird choice.
On 03/12/2019 09:44, Richard Earnshaw (lists) wrote:
On 03/12/2019 00:47, Segher Boessenkool wrote:
On Mon, Dec 02, 2019 at 08:24:47PM +, Joseph Myers wrote:
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
Sure; I'm just saying rewriting old commit messages in such a style
that
they keep s
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
> On Fri, Nov 29, 2019 at 10:31:22PM +, Joseph Myers wrote:
> > On Fri, 29 Nov 2019, Segher Boessenkool wrote:
> > > Please post the full names of all the tags you want to delete?
> >
> > Here is a list of 645 tags proposed for removal, in the var
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
develo
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
On 03/12/2019 13:26, Joseph Myers wrote:
On Mon, 2 Dec 2019, Segher Boessenkool wrote:
On Fri, Nov 29, 2019 at 10:31:22PM +, Joseph Myers wrote:
On Fri, 29 Nov 2019, Segher Boessenkool wrote:
Please post the full names of all the tags you want to delete?
Here is a list of 645 tags propo
On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
> On 03/12/2019 00:56, Segher Boessenkool wrote:
> >That sounds simpler than it is... After using this for a while you'll
> >get names that you want to delete, but that name *already* is in
> >/refs/deleted. So what will yo
On 03/12/2019 18:56, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
>> On 03/12/2019 00:56, Segher Boessenkool wrote:
>>> That sounds simpler than it is... After using this for a while you'll
>>> get names that you want to delete, but that nam
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 n
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
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 foun
Hello GCC community,
Designated initializers can be used in arrays to initialize by index:
int a[6] = { [4] = 29, [2] = 15 }
and by range:
int a[6] = { [2 ... 4] = 5 }
but it seems there's no syntax to initialize all the "others" of the elements,
i.e those not
specified by any initial
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> > I can work on a script to do such rearrangements of tags and branches in
> > the repository. My inclination is that such rearrangements of tag and
> > branch names are probably done in a separate postprocessing script rather
> > than as part
13 matches
Mail list logo