Re: Moving to git

[Richard Biener]

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 the compiler
>> binaries he keeps around for very fast bisection.  I think when we
>> talked about it last year, he just needs an increasing # for each
>> commit, presumably starting with whatever the last SVN ID is when we
>> make the change.
>
>
> Jakub: How about using git bisect instead, and identify the compiler
> binaries with the git commit sha1?

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 to be supported.  Heh.  Well,
just "fixed" the test script.

>>> It would be good to have a more explicit policy on branch/tag creation,
>>> rebasing, and deletion in the git world where branches are lighter
>>> weight and so more transient.
>>
>> Presumably for branch/tag creation the primary concern is the namespace?
>>   I think if we define a namespace folks can safely use without getting
>> in the way of the release managers we get most of what we need.
>>
>> 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 it, I tend to think,
>> why not let them.
>
>
> Makes sense.

Well, I think that all public branches should follow the trunk model - if only
to make merging a dev branch to trunk possible without introducing messy
history.

>> Do we want a namespace for branches which are perhaps not as transient
>> in nature, ie longer term projects, projects on-ice or works-in-progress
>> that we don't want to lose?
>
>
> Currently such branches are at the top level, but I think it would make
> sense to categorize them more, including moving many existing branches into
> subdirectories indicating that they were either merged or abandoned.  We
> might want to delete some old branches entirely.

Can we limit the namespace one can create branches in?  Like force all
branches created by $user to be in namespace $user?  And make those
not automatically pulled?

So require some super-powers to create a toplevel branch?

>> As far as the trunk and release branches, are there any best practices
>> out there that we can draw from?  Obviously doing things like
>> push-rebase-push is bad.  Presumably there's others.
>
>
> 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.
>
> There are many opinions about best practices, but I don't think any of them
> are enough better than what we already do to justify a change.
>
> 'git help workflow' describes how development of git itself works: they have
> "maint", "master" and "next" branches that would roughly correspond to our
> latest release branch, trunk, and next-stage-1-trunk.  Having a "next"
> branch could be useful, but I think we deliberately don't have one currently
> in order to focus people on release preparation during stage 3 rather than
> it always being stage 1 somewhere.

Yep.  I'd like to keep that "feature" (even though it doesn't really work).

> One interesting thing that they do is to keep earlier branches merged into
> later branches, so 4.9 into 5, 5 into trunk, trunk into next.  This is an
> interesting discipline, but I'm not sure it is of much practical value.

So to forward port fixes?  We're usually working the other way around,
fix trunk first, then backport.  I don't think we want any merges across
branches.

Richard.

> Jason
>

Re: [RFC]: Vectorization cost benefit changes.

[Richard Biener]

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 the most cost effective than the outside cost.

I think you are confused about what the variables cost are associated
to.  You are changing a place that computes also the cost
for non-outer-loop-vectorization so your patch is clearly not applicable.

vec_outside_cost is the cost of setting up invariants for example.
All costs apply to the "outer" loop - if there is a nested loop
inside that loop its costs are folded into the "outer" loop cost
already at this stage.

So I think your analysis is simply wrong and thus your patch.

You need to find another place to fix inner loop cost.

Richard.

>  min_profitable_iters = ((scalar_single_iter_cost
> - vec_inside_cost) *vf);
>
> The Scalar_single_iter_cost consider the hardcoded value 50 which is used for 
> most of the targets and the scalar cost is multiplied
> With 50. This scalar cost is subtracted with vector cost and as the scalar 
> cost is increased the chances of vectorization is more with same
> Vectorization factor  and more loops will be vectorized.
>
> I have not changed the iteration count which is hardcoded with 50 and I will 
> do the changes to replace the 50 with the static
> Estimates of iteration count if you agree upon the below changes.
>
> I have ran the SPEC cpu 2000 benchmarks with the below changes for i386 
> targets and the significant gains are achieved with respect
> To INT and FP benchmarks.
>
> Here is the data.
>
> Ratio of vectorization cost changes(FP benchmarks) vs Ratio of without 
> vectorization cost changes( FP benchmarks)  = 4640.102 vs 4583.379.
> Ratio of vectorization cost changes (INT benchmarks ) vs Ratio of without 
> vectorization cost changes( INT benchmarks0 = 3812.883 vs 3778.558
>
> Please give your feedback on the below changes for vectorization cost benefit.
>
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index 422b883..35d538f 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -2987,11 +2987,8 @@ vect_estimate_min_profitable_iters (loop_vec_info 
> loop_vinfo,
>  min_profitable_iters = 1;
>else
>  {
> -  min_profitable_iters = ((vec_outside_cost - scalar_outside_cost) * 
> vf
> - - vec_inside_cost * peel_iters_prologue
> -  - vec_inside_cost * peel_iters_epilogue)
> - / ((scalar_single_iter_cost * vf)
> -- vec_inside_cost);
> +  min_profitable_iters = ((scalar_single_iter_cost
> +- vec_inside_cost) *vf);
>
>if ((scalar_single_iter_cost * vf * min_profitable_iters)
><= (((int) vec_inside_cost * min_profitable_iters)
>
> Thanks & Regards
> Ajit

Re: Moving to git

[Martin Jambor]

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 transition.  Does anyone have more information about 
> > this discussion?
> > 
> > Our current workflow translates over to a git master pretty easily: 
> > basically, in the current git-svn workflow, replace git svn rebase and 
> > git svn dcommit with git pull --rebase and git push.
> > 
> > It should be pretty straightforward to use the existing git mirror as 
> > the master repository; the main adjustment I'd want to make is rewriting 
> > the various subdirectory branches to be properly represented in git. 
> > This is straightforward, but we'll want to stop SVN commits to 
> > subdirectory branches shortly before the changeover.
> > 
> > It would be good to have a more explicit policy on branch/tag creation, 
> > rebasing, and deletion in the git world where branches are lighter 
> > weight and so more transient.
> 
> 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?
> 

I second this, looking at history with git shortlog or in tig
(something I do every now and then) would then be much more
convenient.

And yes, we can actually start doing that now and people using git
mirror would benefit immediately.

Thanks for bringing this up,

Martin

Re: Moving to git

[Martin Jambor]

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?
> > 
> > Currently:
> > https://www.gnu.org/software/gcc/svnwrite.html#checkin says:
> > 
> > "The log message for that checkin should be the complete ChangeLog entry
> > for the change."
> > 
> > and the subsection "Commit the changes to the central repository" below
> > https://www.gnu.org/software/gcc/svnwrite.html#example
> > has an example showing this.
> > 
> > 
> > In the git world, the first line of the commit message has special
> > meaning, being treated as the "title" of the commit.
> 
> It would be nice if we could use a real commit message, not just a short
> title line; for example, people who prepare their patches in git already
> have that, and use it with format-patch as you say.  And many bonus points
> if we don't have to repeat the changelog in the commit message (it's in
> the commit already, the bugzilla hook could just pull it from out there).
> 

I suppose it would be too much to try to enforce patch email as the
commit message.  Patches get changed during discussions in the mailing
lists and it would be then quite unclear how to make these combined
emails and commit messages useful for both purposes and yet not
awkward and superfluous.

But let me re-iterate that I do wholeheartedly support the idea of a
patch title (which should be the same as the subject of the
corresponding mail to the list).

> Or we could have another discussion about if we want to have changelogs
> at all...
> 

Much less important but: I like them.  They force everybody to go
through their patches before submitting them, and giving them a chance
to spot simple bugs and spurious whitespace changes.
 In fact, I think that auto-generating changelogs
should be banned ;-)  Also, when gcc sources leave
any kind of version control system, changelogs are a useful way of
identifying what they might be.

In any way, that is a separate issue,

Martin

RE: [RFC]: Vectorization cost benefit changes.

[Ajit Kumar Agarwal]

-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 cost benefit changes.

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 the most cost effective than the outside cost.

>>I think you are confused about what the variables cost are associated to.  
>>You are changing a place that computes also the cost for 
>>non-outer-loop->>vectorization so your patch is clearly not applicable.

>>vec_outside_cost is the cost of setting up invariants for example.
>>All costs apply to the "outer" loop - if there is a nested loop inside that 
>>loop its costs are folded into the "outer" loop cost already at this stage.

>>So I think your analysis is simply wrong and thus your patch.

>>You need to find another place to fix inner loop cost.

Thanks for your valuable suggestions and feedback. I will certainly look into 
it.

Thanks & Regards
Ajit
Richard.

>  min_profitable_iters = ((scalar_single_iter_cost
> - vec_inside_cost) *vf);
>
> The Scalar_single_iter_cost consider the hardcoded value 50 which is 
> used for most of the targets and the scalar cost is multiplied With 
> 50. This scalar cost is subtracted with vector cost and as the scalar cost is 
> increased the chances of vectorization is more with same Vectorization factor 
>  and more loops will be vectorized.
>
> I have not changed the iteration count which is hardcoded with 50 and 
> I will do the changes to replace the 50 with the static Estimates of 
> iteration count if you agree upon the below changes.
>
> I have ran the SPEC cpu 2000 benchmarks with the below changes for 
> i386 targets and the significant gains are achieved with respect To INT and 
> FP benchmarks.
>
> Here is the data.
>
> Ratio of vectorization cost changes(FP benchmarks) vs Ratio of without 
> vectorization cost changes( FP benchmarks)  = 4640.102 vs 4583.379.
> Ratio of vectorization cost changes (INT benchmarks ) vs Ratio of 
> without vectorization cost changes( INT benchmarks0 = 3812.883 vs 
> 3778.558
>
> Please give your feedback on the below changes for vectorization cost benefit.
>
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c index 
> 422b883..35d538f 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -2987,11 +2987,8 @@ vect_estimate_min_profitable_iters (loop_vec_info 
> loop_vinfo,
>  min_profitable_iters = 1;
>else
>  {
> -  min_profitable_iters = ((vec_outside_cost - scalar_outside_cost) * 
> vf
> - - vec_inside_cost * peel_iters_prologue
> -  - vec_inside_cost * peel_iters_epilogue)
> - / ((scalar_single_iter_cost * vf)
> -- vec_inside_cost);
> +  min_profitable_iters = ((scalar_single_iter_cost
> +- vec_inside_cost) *vf);
>
>if ((scalar_single_iter_cost * vf * min_profitable_iters)
><= (((int) vec_inside_cost * min_profitable_iters)
>
> Thanks & Regards
> Ajit

Re: Compilation of object creation in C++

[Uday P. Khedker]

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 to do the trick and 
now the behaviour is same. C intermediate language


On 08/19/2015 06:00 PM, Richard Biener wrote:

On Wed, Aug 19, 2015 at 2:10 PM, Uday P. Khedker  wrote:

Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:


Most of this is already in GCC 5 and above.  Including the IPA pass.
Have you looked into that pass yet?

 From what I have read, it involves flow insensitive analysis whereas we are
looking at flow sensitive analysis.

It also performs flow-sensitive analysis, exactly like you suggest by looking
for constructor calls or patterns that involve setting the vtable pointer
exposed through inlining.



When I said flow sensitive, I have interprocedural version in mind. When I 
looked up ipa-devirt.c,
there seems to be a traversal  using FOR_EACH_DEFINED_FUNCTION (n), but nothing 
in it
indicates, an interprocedural transfer of information. I also looked up Jan 
Hubicka's blogs
(http://hubicka.blogspot.ca/2014/01/devirtualization-in-c-part-2-low-level.html)
and if I have understood it correctly, the analysis done by constant 
propagation and global
value numbering is at the intraprocedural level (haven't looked up these passes 
though).

Here's a rather trivial example where gcc-5.1 misses devirtualization

class A
{
   public:
   virtual void f() {cout << "\tA:f" << endl;}
};

class B : public A
{ public:
  void f() {cout << "\tB:f" << endl;}
};

class C : public B
{
 public:
  void f() {cout<< "\tC:f" << endl;}
};

void fun1 (A *a, int i)
{
cout << "\nhi in fun1" << i << endl ;
a->f();
}

int main()
{
A  *a1;
a1 = new A;
fun1 (a1, 10);

A *a2;
a2 = new A;
fun1 (a2, 5);
}

Assuming that there is no other translation unit and this is the complete program, 
the call a->f() is always for class
A but the dump in .058i.devirt says

Procesing function void fun1(A*, int)/232
  Targets of polymorphic call of type 28:struct A token 0
Outer type (dynamic):struct A (or a derived type) offset 0
This is partial list; extra targets may be defined in other units. (derived 
types included)
   virtual void A::f()/229 virtual void B::f()/230 virtual void C::f()/231

suggesting that A, B, and C are possible classes.

Even a simple field and context insensitive interprocedural analysis would 
figure out that only one call is
possible (assuming this is the complete program).

The situation we are looking at involves interprocedural propagation with complex calls 
such as a->f->g->h(). We
plan to use a demand driven flow, context, and field sensitive sensitive 
points-to analysis which involves just about enough
computation required to resolves such calls.

Uday.

Re: Moving to git

[Ramana Radhakrishnan]

>
> 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 branches - I agree this is a
complete no-no.

A push-rebase-push development model is possible / may be useful when
the developers collaborating on that branch agree on that model.

git config branch..rebase true - tells git to rebase
instead of merging when pulling into  branch.


In private development branches, instead of creating bazillion
branches and deleting them for ever for something like this - when
trying to maintain a set of patches on top of trunk it's been useful
in the past to allow for a push rebase push style workflow. While
rebasing in this flow, what we also did was to create tags for each of
the rebase points which essentially meant that at any point of time it
was possible to have a linear view of history for everything on that
particular branch. This was useful in cases where we had particularly
long running branches. However when we transitioned to this there was
a bit of pain in that every developer working on those branches needed
to mark the appropriate branches as rebase only.

Given current practice of merging development branches into mainline
being effectively a "rebase" which allows for the linear history on
mainline to be retained, we should document very clearly how git merge
should be used on mainline from development branches.


>
> There are many opinions about best practices, but I don't think any of them
> are enough better than what we already do to justify a change.
>
> 'git help workflow' describes how development of git itself works: they have
> "maint", "master" and "next" branches that would roughly correspond to our
> latest release branch, trunk, and next-stage-1-trunk.  Having a "next"
> branch could be useful, but I think we deliberately don't have one currently
> in order to focus people on release preparation during stage 3 rather than
> it always being stage 1 somewhere.

The "next" name seems to be abused in many tools around git. This
suggestion from git workflow is one, the other use of "next" I've seen
is with gerrit, where "next" refers to a "next" commit that's been put
up for code review.

>
> One interesting thing that they do is to keep earlier branches merged into
> later branches, so 4.9 into 5, 5 into trunk, trunk into next.  This is an
> interesting discipline, but I'm not sure it is of much practical value.

I don't see how that fits with our development model.

regards
Ramana


>
> Jason
>

Re: Compilation of object creation in C++

[Richard Biener]

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 inlined as it is short.
>>
>>
>
> Thanks, this is a useful lead. Setting -fno-inline seems to do the trick and
> now the behaviour is same. C intermediate language
>
>
> On 08/19/2015 06:00 PM, Richard Biener wrote:
>>
>> On Wed, Aug 19, 2015 at 2:10 PM, Uday P. Khedker 
>> wrote:
>>>
>>> Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:


 Most of this is already in GCC 5 and above.  Including the IPA pass.
 Have you looked into that pass yet?
>>>
>>>  From what I have read, it involves flow insensitive analysis whereas we
>>> are
>>> looking at flow sensitive analysis.
>>
>> It also performs flow-sensitive analysis, exactly like you suggest by
>> looking
>> for constructor calls or patterns that involve setting the vtable pointer
>> exposed through inlining.
>>
>>
> When I said flow sensitive, I have interprocedural version in mind. When I
> looked up ipa-devirt.c,
> there seems to be a traversal  using FOR_EACH_DEFINED_FUNCTION (n), but
> nothing in it
> indicates, an interprocedural transfer of information. I also looked up Jan
> Hubicka's blogs
> (http://hubicka.blogspot.ca/2014/01/devirtualization-in-c-part-2-low-level.html)
> and if I have understood it correctly, the analysis done by constant
> propagation and global
> value numbering is at the intraprocedural level (haven't looked up these
> passes though).
>
> Here's a rather trivial example where gcc-5.1 misses devirtualization
>
> class A
> {
>public:
>virtual void f() {cout << "\tA:f" << endl;}
> };
>
> class B : public A
> { public:
>   void f() {cout << "\tB:f" << endl;}
> };
>
> class C : public B
> {
>  public:
>   void f() {cout<< "\tC:f" << endl;}
> };
>
> void fun1 (A *a, int i)
> {
> cout << "\nhi in fun1" << i << endl ;
> a->f();
> }
>
> int main()
> {
> A  *a1;
> a1 = new A;
> fun1 (a1, 10);
>
> A *a2;
> a2 = new A;
> fun1 (a2, 5);
> }
>
> Assuming that there is no other translation unit and this is the complete
> program, the call a->f() is always for class
> A but the dump in .058i.devirt says
>
> Procesing function void fun1(A*, int)/232
>   Targets of polymorphic call of type 28:struct A token 0
> Outer type (dynamic):struct A (or a derived type) offset 0
> This is partial list; extra targets may be defined in other units.
> (derived types included)
>virtual void A::f()/229 virtual void B::f()/230 virtual void
> C::f()/231
>
> suggesting that A, B, and C are possible classes.
>
> Even a simple field and context insensitive interprocedural analysis would
> figure out that only one call is
> possible (assuming this is the complete program).

Did you tell GCC this is a complete program?

> The situation we are looking at involves interprocedural propagation with
> complex calls such as a->f->g->h(). We
> plan to use a demand driven flow, context, and field sensitive sensitive
> points-to analysis which involves just about enough
> computation required to resolves such calls.

I see.

Richard.

> Uday.
>
>
>
>

Re: Moving to git

[Jonathan Wakely]

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
>> pushing again.
>
> On the FSF trunk and the main release branches - I agree this is a
> complete no-no.
>
> A push-rebase-push development model is possible / may be useful when
> the developers collaborating on that branch agree on that model.

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.

> Given current practice of merging development branches into mainline
> being effectively a "rebase" which allows for the linear history on
> mainline to be retained, we should document very clearly how git merge
> should be used on mainline from development branches.

Yes, definitely.

Re: Moving to git

[Jonathan Wakely]

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, something that doesn't seem to be supported.  Heh.  Well,
> just "fixed" the test script.

I'm pretty sure you can have bad older than good, just not when you're
using git bisect run to automate it.

Re: Moving to git

[Richard Biener]

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 bad) - I've tried to find a change that was _fixing_
>> a problem, something that doesn't seem to be supported.  Heh.  Well,
>> just "fixed" the test script.
>
> I'm pretty sure you can have bad older than good, just not when you're
> using git bisect run to automate it.

The point was to use git bisect.

Richard.

Re: Compilation of object creation in C++

[Swati Rathi]

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 the function has been inlined as it is short.




Thanks, this is a useful lead. Setting -fno-inline seems to do the 
trick and

now the behaviour is same. C intermediate language


On 08/19/2015 06:00 PM, Richard Biener wrote:


On Wed, Aug 19, 2015 at 2:10 PM, Uday P. Khedker 


wrote:


Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:



Most of this is already in GCC 5 and above.  Including the IPA 
pass.

Have you looked into that pass yet?


 From what I have read, it involves flow insensitive analysis 
whereas we

are
looking at flow sensitive analysis.


It also performs flow-sensitive analysis, exactly like you suggest 
by

looking
for constructor calls or patterns that involve setting the vtable 
pointer

exposed through inlining.


When I said flow sensitive, I have interprocedural version in mind. 
When I

looked up ipa-devirt.c,
there seems to be a traversal  using FOR_EACH_DEFINED_FUNCTION (n), 
but

nothing in it
indicates, an interprocedural transfer of information. I also looked 
up Jan

Hubicka's blogs

(http://hubicka.blogspot.ca/2014/01/devirtualization-in-c-part-2-low-level.html)
and if I have understood it correctly, the analysis done by constant
propagation and global
value numbering is at the intraprocedural level (haven't looked up 
these

passes though).

Here's a rather trivial example where gcc-5.1 misses 
devirtualization


class A
{
   public:
   virtual void f() {cout << "\tA:f" << endl;}
};

class B : public A
{ public:
  void f() {cout << "\tB:f" << endl;}
};

class C : public B
{
 public:
  void f() {cout<< "\tC:f" << endl;}
};

void fun1 (A *a, int i)
{
cout << "\nhi in fun1" << i << endl ;
a->f();
}

int main()
{
A  *a1;
a1 = new A;
fun1 (a1, 10);

A *a2;
a2 = new A;
fun1 (a2, 5);
}

Assuming that there is no other translation unit and this is the 
complete

program, the call a->f() is always for class
A but the dump in .058i.devirt says

Procesing function void fun1(A*, int)/232
  Targets of polymorphic call of type 28:struct A token 0
Outer type (dynamic):struct A (or a derived type) offset 0
This is partial list; extra targets may be defined in other 
units.

(derived types included)
   virtual void A::f()/229 virtual void B::f()/230 virtual void
C::f()/231

suggesting that A, B, and C are possible classes.

Even a simple field and context insensitive interprocedural analysis 
would

figure out that only one call is
possible (assuming this is the complete program).


Did you tell GCC this is a complete program?


Yes, we did specify the -fwhole-program option with optimization level 
O3.

Is there any other option we should try?



The situation we are looking at involves interprocedural propagation 
with

complex calls such as a->f->g->h(). We
plan to use a demand driven flow, context, and field sensitive 
sensitive

points-to analysis which involves just about enough
computation required to resolves such calls.


I see.

Richard.


Uday.

Re: Using the asm suffix

[Segher Boessenkool]

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 local variable." or maybe "It
> >>is not supported to use this feature with a non-static local variable
> >>since such variables do not have assembler names."
> >"You cannot use this feature ..." etc.?  Keep the part about not having
> >assembler names, it is useful.
> 
> Due to the quirks of the English language, I'm not sure 'cannot' is the 
> right word here.  More correct would be 'cannot reliably' but I don't 
> want to be that wishy-washy.
> 
> And I'm a little iffy about the 'since such variables do not have 
> assembler names,' as it seemed a bit bold to make assertions about the 
> implementation details for all assemblers (past, present and future) for 
> all platforms.  But you are right, it does convey a bit of the 'why' for 
> this limitation, so keeping it is a good idea.  How about:

I think "cannot" is the correct word; this is not about what assemblers
do at all, but about what the *compiler* does.  It would have to jump
through hoops to be able to give stack vars a name; or not use stack
vars, even worse :-)

> "gcc does not support using this feature with a non-static local 
> variable since typically such variables do not have assembler names."

[spelling "GCC" correctly, of course...]

Get rid of "typically" and this looks fine.

> BTW, the trick for getting the "ignoring asm-specifier for non-static 
> local variable" message was renaming my file from sta5.cpp to sta5.c.  
> Seems like this should apply to both, but whatever.

Huh, strange.  Please file a PR.

> >>>The first part ("must not use a register name") is an important warning.
> >>Clarifying this is a good idea.  Although limiting it to only saying
> >>"don't use register names" seems a little, well, limiting. Who knows
> >>what kind of offsets or asm qualifiers they might try to cram in here?
> >Register names is the common case to hurt you...  "r0" etc. ;-)
> 
> But as we have seen (%gs:4), people are willing to try other things.  
> And rather than try to list all the things that don't work (register, 
> registers with offsets, etc), I'm hoping we can find a way to specify 
> the one thing that is supported.

It already says what is supported: a valid name.  "(%gs:4)" is not, "r0"
is, with most assemblers.  This is one reason why some systems prefix
all C symbols with an underscore.


Segher

Re: Moving to git

[Jonathan Wakely]

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 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 to be supported.  Heh.  Well,
>>> just "fixed" the test script.
>>
>> I'm pretty sure you can have bad older than good, just not when you're
>> using git bisect run to automate it.
>
> The point was to use git bisect.


I assume you mean git bisect *run*, because otherwise what I said
stands :-) You can use 'git bisect good' and 'git bisect bad' in any
order.

Re: Moving to git

[Andreas Schwab]

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 to be supported.  Heh.  Well,
> just "fixed" the test script.

You can surely bisect a fix, you just have to remember that bad means
fixed and good means unfixed.  And of course, the git community is
working on enhancing the bisect UI for this use case.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[Ramana Radhakrishnan]

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-rebase-push their own branches need to delete the branch before
>>> pushing again.
>>
>> On the FSF trunk and the main release branches - I agree this is a
>> complete no-no.
>>
>> A push-rebase-push development model is possible / may be useful when
>> the developers collaborating on that branch agree on that model.
>
> 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 of the reasons that teams are
doing their development on a feature branch is so that they can obtain
feedback and collaborate with others in the community. People wanting
to adopt more aggressive uses of git should be allowed to do so in
their private branches as long as they are not able to mess up the
official branches in the repository.

If there is no way to have some branches in a repo allow rebasing and
others not, that's fine but I'd like to know that's the case.

Adopting restrictions on the official branches is quite right (list
below not extensive but it sounds like) ...

a. no rebase / rewriting history
b. no git merges from feature branches.

My 10 paise.

regards
Ramana

Re: Compilation of object creation in C++

[Richard Biener]

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 
 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 to do the trick
>>> and
>>> now the behaviour is same. C intermediate language
>>>
>>>
>>> On 08/19/2015 06:00 PM, Richard Biener wrote:


 On Wed, Aug 19, 2015 at 2:10 PM, Uday P. Khedker 
 wrote:
>
>
> Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:
>>
>>
>>
>> Most of this is already in GCC 5 and above.  Including the IPA pass.
>> Have you looked into that pass yet?
>
>
>  From what I have read, it involves flow insensitive analysis whereas
> we
> are
> looking at flow sensitive analysis.


 It also performs flow-sensitive analysis, exactly like you suggest by
 looking
 for constructor calls or patterns that involve setting the vtable
 pointer
 exposed through inlining.


>>> When I said flow sensitive, I have interprocedural version in mind. When
>>> I
>>> looked up ipa-devirt.c,
>>> there seems to be a traversal  using FOR_EACH_DEFINED_FUNCTION (n), but
>>> nothing in it
>>> indicates, an interprocedural transfer of information. I also looked up
>>> Jan
>>> Hubicka's blogs
>>>
>>>
>>> (http://hubicka.blogspot.ca/2014/01/devirtualization-in-c-part-2-low-level.html)
>>> and if I have understood it correctly, the analysis done by constant
>>> propagation and global
>>> value numbering is at the intraprocedural level (haven't looked up these
>>> passes though).
>>>
>>> Here's a rather trivial example where gcc-5.1 misses devirtualization
>>>
>>> class A
>>> {
>>>public:
>>>virtual void f() {cout << "\tA:f" << endl;}
>>> };
>>>
>>> class B : public A
>>> { public:
>>>   void f() {cout << "\tB:f" << endl;}
>>> };
>>>
>>> class C : public B
>>> {
>>>  public:
>>>   void f() {cout<< "\tC:f" << endl;}
>>> };
>>>
>>> void fun1 (A *a, int i)
>>> {
>>> cout << "\nhi in fun1" << i << endl ;
>>> a->f();
>>> }
>>>
>>> int main()
>>> {
>>> A  *a1;
>>> a1 = new A;
>>> fun1 (a1, 10);
>>>
>>> A *a2;
>>> a2 = new A;
>>> fun1 (a2, 5);
>>> }
>>>
>>> Assuming that there is no other translation unit and this is the complete
>>> program, the call a->f() is always for class
>>> A but the dump in .058i.devirt says
>>>
>>> Procesing function void fun1(A*, int)/232
>>>   Targets of polymorphic call of type 28:struct A token 0
>>> Outer type (dynamic):struct A (or a derived type) offset 0
>>> This is partial list; extra targets may be defined in other units.
>>> (derived types included)
>>>virtual void A::f()/229 virtual void B::f()/230 virtual void
>>> C::f()/231
>>>
>>> suggesting that A, B, and C are possible classes.
>>>
>>> Even a simple field and context insensitive interprocedural analysis
>>> would
>>> figure out that only one call is
>>> possible (assuming this is the complete program).
>>
>>
>> Did you tell GCC this is a complete program?
>
>
> Yes, we did specify the -fwhole-program option with optimization level O3.
> Is there any other option we should try?

No, that should be all for single-file testcases.  But maybe it no longer
works reliably ("may be defined in other units" shouldn't appear with that).

Richard.

>
>>
>>> The situation we are looking at involves interprocedural propagation with
>>> complex calls such as a->f->g->h(). We
>>> plan to use a demand driven flow, context, and field sensitive sensitive
>>> points-to analysis which involves just about enough
>>> computation required to resolves such calls.
>>
>>
>> I see.
>>
>> Richard.
>>
>>> Uday.
>>>
>>>
>>>
>>>
>

Re: Moving to git

[H.J. Lu]

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 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 branches - I agree this is a
>>> complete no-no.
>>>
>>> A push-rebase-push development model is possible / may be useful when
>>> the developers collaborating on that branch agree on that model.
>>
>> 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 of the reasons that teams are
> doing their development on a feature branch is so that they can obtain
> feedback and collaborate with others in the community. People wanting
> to adopt more aggressive uses of git should be allowed to do so in
> their private branches as long as they are not able to mess up the
> official branches in the repository.
>
> If there is no way to have some branches in a repo allow rebasing and
> others not, that's fine but I'd like to know that's the case.
>
> Adopting restrictions on the official branches is quite right (list
> below not extensive but it sounds like) ...
>
> a. no rebase / rewriting history
> b. no git merges from feature branches.

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?

-- 
H.J.

Re: Moving to git

[Markus Trippelsdorf]

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 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 branches - I agree this is a
> >>> complete no-no.
> >>>
> >>> A push-rebase-push development model is possible / may be useful when
> >>> the developers collaborating on that branch agree on that model.
> >>
> >> 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 of the reasons that teams are
> > doing their development on a feature branch is so that they can obtain
> > feedback and collaborate with others in the community. People wanting
> > to adopt more aggressive uses of git should be allowed to do so in
> > their private branches as long as they are not able to mess up the
> > official branches in the repository.
> >
> > If there is no way to have some branches in a repo allow rebasing and
> > others not, that's fine but I'd like to know that's the case.
> >
> > Adopting restrictions on the official branches is quite right (list
> > below not extensive but it sounds like) ...
> >
> > a. no rebase / rewriting history
> > b. no git merges from feature branches.
> 
> 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?

The Linux kernel uses merges all the time, yet "git bisect" works
without any issues. So this not a reason to forbid merges.

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?

-- 
Markus

Re: Moving to git

[Jason Merrill]

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 it, I tend to think,
why not let them.


Makes sense.


Well, I think that all public branches should follow the trunk model - if only
to make merging a dev branch to trunk possible without introducing messy
history.


All shared branches, yes, but I think personal branches can be more 
volatile.



Can we limit the namespace one can create branches in?  Like force all
branches created by $user to be in namespace $user?
So require some super-powers to create a toplevel branch?


We can.


And make [user branches] not automatically pulled?


We can't control what 'git clone' pulls by default.  People can clone 
with --single-branch to get just the trunk and then adjust what else 
gets pulled, but I think it will make most sense for most people to pull 
everything.


Jason

Re: Moving to git

[Andreas Schwab]

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 of the reasons that teams are
> doing their development on a feature branch is so that they can obtain
> feedback and collaborate with others in the community.

It is also much easier for others to pull from foreign repositories with
git, so this isn't a severe downside.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[Jason Merrill]

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
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 branches - I agree this is a
complete no-no.

A push-rebase-push development model is possible / may be useful when
the developers collaborating on that branch agree on that model.


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 of the reasons that teams are
doing their development on a feature branch is so that they can obtain
feedback and collaborate with others in the community. People wanting
to adopt more aggressive uses of git should be allowed to do so in
their private branches as long as they are not able to mess up the
official branches in the repository.

If there is no way to have some branches in a repo allow rebasing and
others not, that's fine but I'd like to know that's the case.

Adopting restrictions on the official branches is quite right (list
below not extensive but it sounds like) ...

a. no rebase / rewriting history


That is, all pushes to official branches must be fast-forward.


b. no git merges from feature branches.


I think that's right at least initially, but I would note that git merge 
--squash doesn't count as a merge for this rule and is indeed the 
recommended way to merge a feature branch.


Jason

Re: Moving to git

[Andreas Schwab]

"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...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[Ramana Radhakrishnan]

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 that
>>> with git.
>>
>> Yes you are right they sure can, but one of the reasons that teams are
>> doing their development on a feature branch is so that they can obtain
>> feedback and collaborate with others in the community.
>
> It is also much easier for others to pull from foreign repositories with
> git, so this isn't a severe downside.

It isn't a severe downside as long as people aren't prevented from
discussing / recording such patches on gcc-patches because said
branches are hosted in a "foreign repository".

regards
Ramana

>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

Re: Moving to git

[Andreas Schwab]

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-push on that branch, then later remove it, I tend to think,
 why not let them.
>>>
>>> Makes sense.
>>
>> Well, I think that all public branches should follow the trunk model - if 
>> only
>> to make merging a dev branch to trunk possible without introducing messy
>> history.
>
> All shared branches, yes, but I think personal branches can be more
> volatile.
>
>> 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 the future.  If
you allow arbitrarily named namespaces clashes will happen.

>> So require some super-powers to create a toplevel branch?
>
> We can.
>
>> And make [user branches] not automatically pulled?
>
> We can't control what 'git clone' pulls by default.

close pulls everything below refs/heads by default.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[H.J. Lu]

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 repo.


-- 
H.J.

Re: Moving to git

[Peter Bergner]

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 to do that
> >> with git.
> >
> > Yes you are right they sure can, but one of the reasons that teams are
> > doing their development on a feature branch is so that they can obtain
> > feedback and collaborate with others in the community.
> 
> It is also much easier for others to pull from foreign repositories with
> git, so this isn't a severe downside.

It may be easy for git to pull from foreign repositories, but it may
be difficult/impossible (policy wise) for some developers from some
companies to be able to write to foreign repositories.  At IBM, we
cannot host our own source repositories that others can access.  We can
only write to the official source code repositories for the projects
that we have clearance to work in.  We currently have an IBM vendor
directory where we have our branches.  If we move to git (I'm all for
it), I would hope that those can remain in the official source code
repository.

That said, if the GCC project created an "official" side repository
where branches are stored, we could participate in that.

Peter

Re: Moving to git

[H.J. Lu]

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?
>
> bisect works fine with merges.
>

I keep binutils users/hjl/linux/master branch:

https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/hjl/linux/master

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.

Also "git bisect" doesn't work on gcc trunk in GCC git mirror
for commits around wide-int branch merge.


-- 
H.J.

Re: Moving to git

[Jeff Law]

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 he keeps around for very fast bisection.  I think when we
talked about it last year, he just needs an increasing # for each
commit, presumably starting with whatever the last SVN ID is when we
make the change.


Jakub: How about using git bisect instead, and identify the compiler
binaries with the git commit sha1?
That would seem to make reasonable sense to me.  Jakub is on PTO, so we 
should re-engage on this tweak to his workflow when he returns.


Jeff

Re: Moving to git

[Joseph Myers]

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 to leave the tree in a 
working state; if a change was split up purely for review purposes rather 
than with each subset 1-N of the patches intended to leave a working tree, 
combine the changes before committing.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Moving to git

[Ramana Radhakrishnan]

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
>> >> 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 of the reasons that teams are
>> > doing their development on a feature branch is so that they can obtain
>> > feedback and collaborate with others in the community.
>>
>> It is also much easier for others to pull from foreign repositories with
>> git, so this isn't a severe downside.
>
> It may be easy for git to pull from foreign repositories, but it may
> be difficult/impossible (policy wise) for some developers from some
> companies to be able to write to foreign repositories.  At IBM, we
> cannot host our own source repositories that others can access.  We can
> only write to the official source code repositories for the projects
> that we have clearance to work in.  We currently have an IBM vendor
> directory where we have our branches.  If we move to git (I'm all for
> it), I would hope that those can remain in the official source code
> repository.

I don't think I've seen anyone argue against the existence of such
branches in the main repository.

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 (manual) fast-forward /
rebase and apply kind of development workflow while feature
development branches cannot maintain these in terms of
 without jumping through hoops.


regards
Ramana

>
> That said, if the GCC project created an "official" side repository
> where branches are stored, we could participate in that.
>
> Peter
>
>
>

Re: Moving to git

[Andreas Schwab]

"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 branch merge.

Please define "doesn't work".

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[H.J. Lu]

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 work on gcc trunk in GCC git mirror
>> for commits around wide-int branch merge.

"git bisect good"/"git bisect bad" land my tree not on trunk when
they are used on commits from wide-int branch merge.  Those
commits are

205112
205363
205375
205900
205966
205968
205968
205969
205670
205971
206028
206035
206689
209692
209944


-- 
H.J.

Re: Moving to git

[Ramana Radhakrishnan]

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
>> >> 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 of the reasons that teams are
>> > doing their development on a feature branch is so that they can obtain
>> > feedback and collaborate with others in the community.
>>
>> It is also much easier for others to pull from foreign repositories with
>> git, so this isn't a severe downside.
>
> It may be easy for git to pull from foreign repositories, but it may
> be difficult/impossible (policy wise) for some developers from some
> companies to be able to write to foreign repositories.  At IBM, we
> cannot host our own source repositories that others can access.  We can
> only write to the official source code repositories for the projects
> that we have clearance to work in.  We currently have an IBM vendor
> directory where we have our branches.  If we move to git (I'm all for
> it), I would hope that those can remain in the official source code
> repository.
>

On re-reading this yes, I see your point and I think that's a valid
argument against forcing folks to go and do their own thing for
foreign repositories for such use cases.


regards
Ramana

> That said, if the GCC project created an "official" side repository
> where branches are stored, we could participate in that.
>
> Peter
>
>
>

Re: Moving to git

[Andreas Schwab]

"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 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[H.J. Lu]

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.J.

Re: Moving to git

[Andreas Schwab]

"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 help me bisect GCC trunk.

Yes, it does.  The branches are part of it.  If you think you can label
a commit without testing it, go ahead, but don't complain if you get
garbage.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

A variation of constructor attribute

[J Decker]

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))) similar to constructor, but, and
especially significant under windows, doesn't run until just before
main() is dispatched.  The initializers would be added to a list (or
linked into a list) so they will all run in-order.  It's not always
proper to run lowest level initializers first (at dynamic library load
time), and under windows the dll loader lock that blocks thread
creation prevents creation of threads in constructor or DllMain level
initializers.  By waiting until all libraries have been loaded, and
then dispatching their initializers the thread block is overcome.

I implemented for my own library a method of doing this; but it
requires additional code be added to each library/executable that uses
this.  Perhaps there is a way to overcome 2 of the source files I
include, but the third (the scheduling part) would still have to be
added, which makes adding new projects annoying.  (I add a source at
start with a known, unique name that indicates the first in a
__attribute__((section( "deadstart_list" ))) and another that's the
last in the section, the third source knows the section and can
iterate through the objects defined there and schedule them.  In the
program I link a 4th source that has a __attribute__((constructor))
that calls all the registered startups.)

So this new attribute would create a data structure similar to
constructor, with a few extra fields to support adding it in-place
into a list, and a flag for dispatched.  it is possible that the list
will change as the list is processed too, since a initializer could
load another library which has it's own intializer attributed
functions with various priorities (perhaps priorities that are lower
than what has already been processed).

I do assume that this is like most other projects I've run into that
'if I want something done, I'll have to do it myself'.

Here's a rough flow of a process consisting of program lib1, plugin1

program loads, lib1 gets loaded; using constructor attributes,
initializers in lib1 run (and cannot create threads in windows)... but
if lib1 actually has a high priority constructor that loads plugin1
not all of the constructors have nessecarily run, but plugin1's
constructors will all run at that time;  It may rely on higher
priority constructors from lib1 which run after the point it's
dynamically loaded.

after scheduling the routines,  and returning to main initializers,
intializer routines should start running, and new libraries loaded
during initialization should get their initializers scheduled at that
time (which may include initializers that are higher in priority than
the current running initializer).  But after all initializers have
run, when a new library is loaded initializers should run
immediately...

hmm requires support in dlopen/LoadLibrary function too, because
again, have to return to code outside of the loading process to create
threads so maybe it's not practical to implement

Re: Moving to git

[Jason Merrill]

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
separate commits, each commit should be intended to leave the tree in a
working state; if a change was split up purely for review purposes rather
than with each subset 1-N of the patches intended to leave a working tree,
combine the changes before committing.


Yes.  But if there was a merge from a feature branch that doesn't 
achieve this (as I expect many don't, in early WIP stages), then you can 
tell bisect to avoid descending into other branches.


https://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches

Jason

Re: Moving to git

[Jason Merrill]

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 (manual) fast-forward /
rebase and apply kind of development workflow while feature
development branches cannot maintain these in terms of
 without jumping through hoops.


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

Re: Moving to git

[Jason Merrill]

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 the future.  If
you allow arbitrarily named namespaces clashes will happen.


I had been thinking of "namespace" as a subdirectory of refs/heads.  But 
now I see that there is something called "namespace" in git.  Where did 
you see that git was going to claim certain namespace names?  git help 
namespaces doesn't suggest anything like that.



We can't control what 'git clone' pulls by default.


close pulls everything below refs/heads by default.


Yes; my point was that you can't change that except with 
--single-branch.  But if we encourage people to use personal git 
namespaces, then they won't be under refs/heads, so they won't be pulled 
by default.


Jason

Re: Moving to git

[Andreas Schwab]

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 of the feature branch.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[Andreas Schwab]

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 git was going to claim certain namespace names?
> git help namespaces doesn't suggest anything like that.

I wasn't referring to gitnamespaces, but the directories directly below
refs.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[Jason Merrill]

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.


This will of course lose the history of the feature branch.


Yep.  Merging vs. squashing is a subject of debate.

Keeping the history of the feature branch is both a pro and a con: it 
feels bad to throw away history, but keeping it makes both browsing and 
bisecting more complicated.


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.  I wonder if that avoids the bisect complications?


Jason

Re: Moving to git

[Andreas Schwab]

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.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[Jason Merrill]

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 would be worse, since changes are duplicated.


How duplicated?  The non-squash merge would make no changes, only 
express that the branch is now merged.


Jason

Re: Moving to git

[Joseph Myers]

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 namespace $user?
> > 
> > git will create new namespaces for its own purpose in the future.  If
> > you allow arbitrarily named namespaces clashes will happen.
> 
> I had been thinking of "namespace" as a subdirectory of refs/heads.  But now I

That's my assumption - all refs (including renamed ones from the old 
git-svn history) are under refs/heads or refs/tags, users / companies may 
use subdirectories under there, all refs get pulled by default.  (And I 
don't think we should try to limit branch creation; if anyone wants to 
create a project branch shared by multiple users, they should be able to 
do so and not need to put it under a user directory.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Moving to git

[Jason Merrill]

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 $user to be in namespace $user?


git will create new namespaces for its own purpose in the future.  If
you allow arbitrarily named namespaces clashes will happen.


I had been thinking of "namespace" as a subdirectory of refs/heads.  But now I


That's my assumption - all refs (including renamed ones from the old
git-svn history) are under refs/heads or refs/tags, users / companies may
use subdirectories under there, all refs get pulled by default.  (And I
don't think we should try to limit branch creation; if anyone wants to
create a project branch shared by multiple users, they should be able to
do so and not need to put it under a user directory.)


I lean that way as well.

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.


Jason

Re: Moving to git

[Joseph Myers]

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 should be fine for the deletion and recreation to 
disappear completely from the history, or to appear as commits that don't 
modify the tree.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Moving to git

[Joseph Myers]

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 concerned), but potentially rename into a subdirectory e.g. 
refs/heads/old/.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Moving to git

[Andreas Schwab]

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, but the history is available.
>>
>> That would be worse, since changes are duplicated.
>
> How duplicated?

In the squashed commit and in the branch.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving to git

[Mikhail Maltsev]

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 
> again.
> 
> There are many opinions about best practices, but I don't think any of them 
> are
> enough better than what we already do to justify a change.

Regardless of what the non-fast-forward-push policy will be (please don't get me
wrong - I'm not trying to meddle into development of policies), why is deleting
and pushing a branch again better than pushing with force? AFAIK, git tracks
remote branches just by their names, so, for example if user A checked out user
B's branch, and B later deleted it and pushed again after, perhaps, rebasing
locally, then user A will get a conflict, if he tries to pull (same result as
with "git push -f").

-- 
Regards,
Mikhail Maltsev

[PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

[David Malcolm]

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, to add meaningful
> >> titles to commits?
> >>
> >> Currently:
> >> https://www.gnu.org/software/gcc/svnwrite.html#checkin says:
> >>
> >> "The log message for that checkin should be the complete ChangeLog entry
> >> for the change."
> >>
> >> and the subsection "Commit the changes to the central repository" below
> >> https://www.gnu.org/software/gcc/svnwrite.html#example
> >> has an example showing this.
> >>
> >>
> >> In the git world, the first line of the commit message has special
> >> meaning, being treated as the "title" of the commit.
> >
> > It would be nice if we could use a real commit message, not just a short
> > title line; for example, people who prepare their patches in git already
> > have that, and use it with format-patch as you say.
> 
> I think that's what David was suggesting; a short title line, followed 
> by a blank line, followed by a more substantive commit message.
> 
> This change doesn't need to be tied to the git transition; it could 
> happen either before or after.

Attached is a patch for the website which advises doing this when
committing.

> > And many bonus points
> > if we don't have to repeat the changelog in the commit message (it's in
> > the commit already, the bugzilla hook could just pull it from out there).
> >
> > Or we could have another discussion about if we want to have changelogs
> > at all...
> 
> That's a good question, but I think it's definitely independent.
> 
> Jason
> 

? htdocs/.#index.html.1.940
? htdocs/index.html.~1.940.~
? htdocs/svnwrite.html.~1.34.~
Index: htdocs/svnwrite.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v
retrieving revision 1.34
diff -u -p -r1.34 svnwrite.html
--- htdocs/svnwrite.html	6 Apr 2015 12:15:18 -	1.34
+++ htdocs/svnwrite.html	21 Aug 2015 21:40:10 -
@@ -210,13 +210,20 @@ when performing checkins to avoid accide
 code.
 
 We prefer that each SVN checkin be of a complete, single logical
-change, which may affect multiple files.  The log message for that
-checkin should be the complete ChangeLog entry for the change.  This
-makes it easier to correlate changes across files, and minimizes the
+change, which may affect multiple files.  This makes it easier to
+correlate changes across files, and minimizes the
 time the repository is inconsistent.  If you have several unrelated
 changes, you should check them in with separate SVN commit
 commands.
 
+The log message for a checkin should be a single line giving a
+descriptive title for the checkin, followed by a blank line, followed by
+the complete ChangeLog entry for the change.  This is the git convention;
+giving titles to checkins makes life easier for developers using git
+mirrors of SVN.  Typically the descriptive title should be the "Subject"
+line of the relevant gcc-patches thread (without any "[PATCH]" or "[PING]"
+prefixes).
+
 
 Sync your sources with the master repository via "svn
 update" before attempting a checkin; this will save you a little
@@ -253,7 +260,12 @@ an error occurs and it will not check in
 Example check-in session
 
 Here's an actual check-in session for a patch John Carr recently
-sent to the GCC list.  This was the ChangeLog for his change:
+sent to the GCC list.
+
+His patch was sent in a mail titled
+compiler patches for HOST_WIDE_INT = long long
+
+This was the ChangeLog for his change:
 
 
 Sun Feb  8 08:02:13 1998  John Carr  
@@ -355,11 +367,12 @@ this particular case all three needed th
 [/law/gcc/gcc] svn commit ChangeLog bitmap.c calls.c genattrtab.c
 
 
-My editor starts and I enter the log message; the lines starting
+My editor starts and I enter the title and log message; the lines starting
 with This line, and those below, will be ignored are automatically 
 added by SVN and will be automatically removed:
 
-
+compiler patches for HOST_WIDE_INT = long long
+
 * bitmap.c (bitmap_debug_file): HOST_PTR_PRINTF converts a pointer,
 not a HOST_WIDE_INT.
 

Re: Moving to git

[Jason Merrill]

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 delete the branch before pushing 
again.

There are many opinions about best practices, but I don't think any of them are
enough better than what we already do to justify a change.


Regardless of what the non-fast-forward-push policy will be (please don't get me
wrong - I'm not trying to meddle into development of policies),


Feel free to meddle. :)


why is deleting and pushing a branch again better than pushing with force?


The effect is the same but it's less convenient, so it discourages 
people from doing it without considering whether that's really the right 
thing to do.  But I'm flexible on this point.


Jason

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

[Jason Merrill]

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