On 08/21/2015 07:54 PM, David Malcolm wrote:
Here's an actual check-in session for a patch John Carr recently
Can this really be described as an actual check-in session when we're
changing the contents? :)
Jason
On 08/21/2015 06:44 PM, Mikhail Maltsev wrote:
On 08/20/2015 11:09 PM, Jason Merrill wrote:
Absolutely, a non-fast-forward push is anathema for anything other people might
be working on. The git repository already prohibits this; people that want to
push-rebase-push their own branches need to
On Thu, 2015-08-20 at 18:37 -0400, Jason Merrill wrote:
> On 08/20/2015 06:32 PM, Segher Boessenkool wrote:
> > On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
> >> If we're going to migrate to git (I hope so), can we also please
> >> *slightly* revise the policy on commit messages,
On 08/20/2015 11:09 PM, Jason Merrill wrote:
>
> Absolutely, a non-fast-forward push is anathema for anything other people
> might
> be working on. The git repository already prohibits this; people that want to
> push-rebase-push their own branches need to delete the branch before pushing
> aga
Jason Merrill writes:
> On 08/21/2015 03:21 PM, Andreas Schwab wrote:
>> Jason Merrill writes:
>>
>>> Hmm, it occurs to me that a squash commit (or series of commits) followed
>>> by a merge -s ours could have the advantages of both approaches: the
>>> patches land on trunk in a sensible order,
On Fri, 21 Aug 2015, Jason Merrill wrote:
> We should also talk about a policy for when we delete branches; there are a
> bunch of ancient feature and testing branches in SVN that I think are no
> longer interesting.
My view is don't delete (except for leaving user / company branches up to
those
One other thing to watch out for in the conversion:
* Where trunk got accidentally deleted and recreated as a copy of the
trunk version before the deletion (recreations r130805, r184997), make
sure this doesn't get represented as deletion followed by recreation of
all files on trunk. (It shoul
On 08/21/2015 04:10 PM, Joseph Myers wrote:
On Fri, 21 Aug 2015, Jason Merrill wrote:
On 08/21/2015 10:38 AM, Andreas Schwab wrote:
Jason Merrill writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
Can we limit the namespace one can create branches in? Like force all
branches created by $
On Fri, 21 Aug 2015, Jason Merrill wrote:
> On 08/21/2015 10:38 AM, Andreas Schwab wrote:
> > Jason Merrill writes:
> > > On 08/21/2015 04:26 AM, Richard Biener wrote:
> > > > Can we limit the namespace one can create branches in? Like force all
> > > > branches created by $user to be in namespa
On 08/21/2015 03:21 PM, Andreas Schwab wrote:
Jason Merrill writes:
Hmm, it occurs to me that a squash commit (or series of commits) followed
by a merge -s ours could have the advantages of both approaches: the
patches land on trunk in a sensible order, but the history is available.
That wou
Jason Merrill writes:
> Hmm, it occurs to me that a squash commit (or series of commits) followed
> by a merge -s ours could have the advantages of both approaches: the
> patches land on trunk in a sensible order, but the history is available.
That would be worse, since changes are duplicated.
On 08/21/2015 02:28 PM, Andreas Schwab wrote:
Jason Merrill writes:
I would expect feature branches to merge from trunk when needed during
development. When merging the feature into trunk the developer can just
use git merge --squash and then decide whether to commit it in one hunk or
several
Jason Merrill writes:
> I had been thinking of "namespace" as a subdirectory of refs/heads.
If Richard wants something not pulled by default, then he must have
thought of something outside of refs/heads.
> But now I see that there is something called "namespace" in git.
> Where did you see that
Jason Merrill writes:
> I would expect feature branches to merge from trunk when needed during
> development. When merging the feature into trunk the developer can just
> use git merge --squash and then decide whether to commit it in one hunk or
> several.
This will of course lose the history o
On 08/21/2015 10:38 AM, Andreas Schwab wrote:
Jason Merrill writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
Can we limit the namespace one can create branches in? Like force all
branches created by $user to be in namespace $user?
git will create new namespaces for its own purpose in t
On 08/21/2015 11:30 AM, Ramana Radhakrishnan wrote:
My query was whether allowing for rebase (rewriting history) in
published feature branches was a decision to be left to the branch
maintainers or was this going to be a repository wide restriction. It
also seems odd to me that trunk follows a (m
On 08/21/2015 11:26 AM, Joseph Myers wrote:
On Fri, 21 Aug 2015, H.J. Lu wrote:
Can we enforce that "git bisect" must work on official branches?
I think a good principle independent of moving to git is that commits
should be bisectable. In particular, if a patch series is committed as
separa
It's nice that GCC has included a constructor attribute, but it
doesn't work in complex scenarios.
I was considering tinkering with adding a 'initializer' and '?exiter'
or maybe 'deinitializer'? (not sure what to name the other side) But
on to the primary...
__attribute((initializer(priority)))
"H.J. Lu" writes:
> On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab wrote:
>> "H.J. Lu" writes:
>>
>>> "git bisect good"/"git bisect bad" land my tree not on trunk when
>>> they are used on commits from wide-int branch merge.
>>
>> Yes, that is bisect working as designed.
>
> But this doesn't h
On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab wrote:
> "H.J. Lu" writes:
>
>> "git bisect good"/"git bisect bad" land my tree not on trunk when
>> they are used on commits from wide-int branch merge.
>
> Yes, that is bisect working as designed.
But this doesn't help me bisect GCC trunk.
--
H
"H.J. Lu" writes:
> "git bisect good"/"git bisect bad" land my tree not on trunk when
> they are used on commits from wide-int branch merge.
Yes, that is bisect working as designed.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214
On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner wrote:
> On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
>> Ramana Radhakrishnan writes:
>>
>> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
>> > wrote:
>> >> Teams following a different model could use a separate repo shared by
>> >
On Fri, Aug 21, 2015 at 8:39 AM, Andreas Schwab wrote:
> "H.J. Lu" writes:
>
>> up to date by "git merge origin/master". I never tried "git bisect"
>> on it since I know that commits on that branch aren't consecutive.
>
> bisect works with any kind of repository.
>
>> Also "git bisect" doesn't wo
"H.J. Lu" writes:
> up to date by "git merge origin/master". I never tried "git bisect"
> on it since I know that commits on that branch aren't consecutive.
bisect works with any kind of repository.
> Also "git bisect" doesn't work on gcc trunk in GCC git mirror
> for commits around wide-int br
On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner wrote:
> On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
>> Ramana Radhakrishnan writes:
>>
>> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
>> > wrote:
>> >> Teams following a different model could use a separate repo shared by
>> >
On Fri, 21 Aug 2015, H.J. Lu wrote:
> Can we enforce that "git bisect" must work on official branches?
I think a good principle independent of moving to git is that commits
should be bisectable. In particular, if a patch series is committed as
separate commits, each commit should be intended t
On 08/20/2015 02:09 PM, Jason Merrill wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are associated with the compiler
binaries
On Fri, Aug 21, 2015 at 7:33 AM, Andreas Schwab wrote:
> "H.J. Lu" writes:
>
>> One very frustrating thing for me is "git bisect" doesn't always
>> work. I think cherry-pick is OK, but probably not rebase nor merge.
>>
>> Can we enforce that "git bisect" must work on official branches?
>
> bisec
On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
> Ramana Radhakrishnan writes:
>
> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
> > wrote:
> >> Teams following a different model could use a separate repo shared by
> >> those developers, not the gcc.gnu.org one. It's much easier
On Fri, Aug 21, 2015 at 6:59 AM, Markus Trippelsdorf
wrote:
>
> BTW while I have your attention: Why are you constantly creating
> (rebasing) and deleting branches? Why not simply use a local git tree
> for this purpose?
I want to share my branches with people who have no access to my
local git r
Jason Merrill writes:
> On 08/21/2015 04:26 AM, Richard Biener wrote:
>> On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill wrote:
ISTM that within that namespace, folks ought to have the freedom to use
whatever works for them. If folks want to create a transient branch,
push-rebase
On Fri, Aug 21, 2015 at 3:09 PM, Andreas Schwab wrote:
> Ramana Radhakrishnan writes:
>
>> On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
>> wrote:
>>> Teams following a different model could use a separate repo shared by
>>> those developers, not the gcc.gnu.org one. It's much easier to do
"H.J. Lu" writes:
> One very frustrating thing for me is "git bisect" doesn't always
> work. I think cherry-pick is OK, but probably not rebase nor merge.
>
> Can we enforce that "git bisect" must work on official branches?
bisect works fine with merges.
Andreas.
--
Andreas Schwab, sch...@li
On 08/21/2015 09:47 AM, H.J. Lu wrote:
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
wrote:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward push is anathema for anything other people
migh
Ramana Radhakrishnan writes:
> On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
> wrote:
>> Teams following a different model could use a separate repo shared by
>> those developers, not the gcc.gnu.org one. It's much easier to do that
>> with git.
>
> Yes you are right they sure can, but one
On 08/21/2015 04:26 AM, Richard Biener wrote:
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill wrote:
ISTM that within that namespace, folks ought to have the freedom to use
whatever works for them. If folks want to create a transient branch,
push-rebase-push on that branch, then later remove i
On 2015.08.21 at 06:47 -0700, H.J. Lu wrote:
> On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
> wrote:
> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
> > wrote:
> >> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
>
> Absolutely, a non-fast-forward push is anathem
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
wrote:
> On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
> wrote:
>> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward push is anathema for anything other people
might be working on. The
On Fri, Aug 21, 2015 at 1:41 PM, Swati Rathi wrote:
> On 2015-08-21 16:16, Richard Biener wrote:
>>
>> On Fri, Aug 21, 2015 at 12:44 PM, Uday P. Khedker
>> wrote:
>>>
>>>
>>>
>>> On 08/19/2015 04:44 PM, Andrew Pinski wrote:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker
wro
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely wrote:
> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
>>>
>>> Absolutely, a non-fast-forward push is anathema for anything other people
>>> might be working on. The git repository already prohibits this; people that
>>> want to push-reb
Richard Biener writes:
> Btw, I've done this once now and it kind of works. You need to write your
> tests in a way to support gits limited way of searching (the past has to be
> always good, the future bad) - I've tried to find a change that was _fixing_
> a problem, something that doesn't seem
On 21 August 2015 at 12:25, Richard Biener wrote:
> On Fri, Aug 21, 2015 at 12:52 PM, Jonathan Wakely
> wrote:
>> On 21 August 2015 at 09:26, Richard Biener wrote:
>>>
>>> Btw, I've done this once now and it kind of works. You need to write your
>>> tests in a way to support gits limited way of
On Wed, Aug 19, 2015 at 11:02:14PM -0700, David Wohlferd wrote:
> >>how about replacing the existing
> >>text ("It does not make sense to use this feature with a non-static
> >>local variable since such variables do not have assembler names.") with
> >>"Do not use this feature with a non-static loc
On 2015-08-21 16:16, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:44 PM, Uday P. Khedker
wrote:
On 08/19/2015 04:44 PM, Andrew Pinski wrote:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker
wrote:
Why is this different? Why is __comp_ctor not invoked in each
case?
This looks like
On Fri, Aug 21, 2015 at 12:52 PM, Jonathan Wakely wrote:
> On 21 August 2015 at 09:26, Richard Biener wrote:
>>
>> Btw, I've done this once now and it kind of works. You need to write your
>> tests in a way to support gits limited way of searching (the past has to be
>> always good, the future ba
On 21 August 2015 at 09:26, Richard Biener wrote:
>
> Btw, I've done this once now and it kind of works. You need to write your
> tests in a way to support gits limited way of searching (the past has to be
> always good, the future bad) - I've tried to find a change that was _fixing_
> a problem,
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
>>
>> Absolutely, a non-fast-forward push is anathema for anything other people
>> might be working on. The git repository already prohibits this; people that
>> want to push-rebase-push their own branches need to delete the branch before
>>
On Fri, Aug 21, 2015 at 12:44 PM, Uday P. Khedker wrote:
>
>
> On 08/19/2015 04:44 PM, Andrew Pinski wrote:
>>
>> On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker
>> wrote:
>>
>>> Why is this different? Why is __comp_ctor not invoked in each case?
>>
>> This looks like the function has been inlin
>
> Absolutely, a non-fast-forward push is anathema for anything other people
> might be working on. The git repository already prohibits this; people that
> want to push-rebase-push their own branches need to delete the branch before
> pushing again.
On the FSF trunk and the main release branche
On 08/19/2015 04:44 PM, Andrew Pinski wrote:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker wrote:
Why is this different? Why is __comp_ctor not invoked in each case?
This looks like the function has been inlined as it is short.
Thanks, this is a useful lead. Setting -fno-inline seems
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Friday, August 21, 2015 2:03 PM
To: Ajit Kumar Agarwal
Cc: Jeff Law; GCC Patches; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta;
Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [RFC]: Vectorization
Hi,
On Thu, Aug 20, 2015 at 05:32:26PM -0500, Segher Boessenkool wrote:
> On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
> > If we're going to migrate to git (I hope so), can we also please
> > *slightly* revise the policy on commit messages, to add meaningful
> > titles to commits
Hi,
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
> On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote:
> > I hear that at Cauldron people were generally supportive of switching
> > over to git as the primary GCC repository, and talked about me being
> > involved in that tra
On Fri, Aug 21, 2015 at 7:18 AM, Ajit Kumar Agarwal
wrote:
> All:
>
> I have done the vectorization cost changes as given below. I have considered
> only the cost associated with the inner instead of outside.
> The consideration of inside scalar and vector cost is done as the inner cost
> are th
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill wrote:
> On 08/20/2015 02:23 PM, Jeff Law wrote:
>>
>> I suspect Jakub will strongly want to see some kind commit hook to
>> associate something similar to an SVN id to each git commit to support
>> his workflow where the SVN ids are associated with
55 matches
Mail list logo
