[RFC] add push/pop pragma to control the scope of "using"

[马江]

Hello,
  After  some google, I find there is no way to control the scope of
"using" for the moment.  This seems strange as we definitely need this
feature especially when writing inline member functions in c++
headers.

  Currently I am trying to build a simple class in a c++ header file
as following:

#include 
using namespace std;
class mytest
{
  string test_name;
  int test_val;
public:
  inline string & get_name () {return test_name;}
};

  As a experienced  C coder, I know that inline functions must be put
into headers or else users could only rely on LTO. And I know that to
use "using" in a header file is a bad idea as it might silently change
meanings of other codes. However, after I put all my inline functions
into the header file, I found I must write many "std::string" instead
of "string" which is totally a torture.
  Can we add something like "#pragma push_using"  (just like #pragma
pop_macro)? I believe it's feasible and probably not hard to
implement.

Re: [RFC] add push/pop pragma to control the scope of "using"

[Jeffrey Walton]

On Wed, Jan 15, 2020 at 3:15 AM 马江  wrote:
>
> Hello,
>   After  some google, I find there is no way to control the scope of
> "using" for the moment.  This seems strange as we definitely need this
> feature especially when writing inline member functions in c++
> headers.
>
>   Currently I am trying to build a simple class in a c++ header file
> as following:
>
> #include 
> using namespace std;
> class mytest
> {
>   string test_name;
>   int test_val;
> public:
>   inline string & get_name () {return test_name;}
> };

https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice

Re: [RFC] add push/pop pragma to control the scope of "using"

[Marc Glisse]

On Wed, 15 Jan 2020, 马江 wrote:


Hello,
 After  some google, I find there is no way to control the scope of
"using" for the moment.  This seems strange as we definitely need this
feature especially when writing inline member functions in c++
headers.

 Currently I am trying to build a simple class in a c++ header file
as following:

#include 
using namespace std;
class mytest
{
 string test_name;
 int test_val;
public:
 inline string & get_name () {return test_name;}
};


Why is mytest in the global namespace?


 As a experienced  C coder, I know that inline functions must be put
into headers or else users could only rely on LTO. And I know that to
use "using" in a header file is a bad idea as it might silently change
meanings of other codes. However, after I put all my inline functions
into the header file, I found I must write many "std::string" instead
of "string" which is totally a torture.
 Can we add something like "#pragma push_using"  (just like #pragma
pop_macro)? I believe it's feasible and probably not hard to
implement.


We try to avoid extensions in gcc, you may want to propose this to the C++ 
standard committee first. However, you should first check if modules 
(C++20) affect the issue.


--
Marc Glisse

Re: Help with new GCC git workflow...

[Richard Biener]

On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond  wrote:
>
> Peter Bergner :
> > At this point, I get a little confused. :-)  I know to submit my patch
> > for review, I'll want to squash my commits down into one patch, but how
> > does one do that?  Should I do that now or only when I'm ready to
> > push this change to the upstream repo or ???  Do I need to even do that?
>
> If you want to squash a commit series, the magic is git rebase -i. You
> give that a number of commits to look back at at and you'll get a buffer
> instructing you how to squash and shuffle that series.  You'll also be able
> to edit the commit message.
>
> I like to write really fine-grained commits when I'm developing, then
> squash before pushing so the public repo commits always go from "tests
> pass" to "test pass".  That way you can do clean bisections on the
> public history.

The question is wheter one could achieve this with branches?  That is,
have master contain a merge commit from a branch that contains the
fine-grained commits?  Because for forensics those can be sometimes
useful.

That basically would somehow record that a series of commits are "related"
(the merge commit has two parents).  Of course usually the merge commit
is empty and thus non-existant but then for branch merges it still
always exists?

> > Also, when I'm ready to push this "change" upstream to trunk, I'll need
> > to move this over to my master and then push.  What are the recommended
> > commands for doing that?
>
> There are a couple of ways.  I usually squash as described above
> then use "git cherry-pick".  But that's because I have philosophical
> reasons to avoid long-lives branches.
>
> >   I assume I need to rebase my branch to
> > current upstream master, since that probably has moved forward since
> > I checked my code out.
>
> Yes, in general you'll want to do that.
>
> > Also, at what point do I write my final commit message, which is different
> > than the (possibly simple) commit messages above?  Is that done after I've
> > pulled my local branch into my master?  ...or before?  ...or during the
> > merge over?
>
> I do it at rebase -i time along with the squash of the series.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
>

Re: Help with new GCC git workflow...

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 08:40, Richard Biener  wrote:
>
> On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond  wrote:
> >
> > Peter Bergner :
> > > At this point, I get a little confused. :-)  I know to submit my patch
> > > for review, I'll want to squash my commits down into one patch, but how
> > > does one do that?  Should I do that now or only when I'm ready to
> > > push this change to the upstream repo or ???  Do I need to even do that?
> >
> > If you want to squash a commit series, the magic is git rebase -i. You
> > give that a number of commits to look back at at and you'll get a buffer
> > instructing you how to squash and shuffle that series.  You'll also be able
> > to edit the commit message.
> >
> > I like to write really fine-grained commits when I'm developing, then
> > squash before pushing so the public repo commits always go from "tests
> > pass" to "test pass".  That way you can do clean bisections on the
> > public history.
>
> The question is wheter one could achieve this with branches?  That is,
> have master contain a merge commit from a branch that contains the
> fine-grained commits?  Because for forensics those can be sometimes
> useful.

A "merge commit" is a special kind of commit that creates a commit
with two (or more) parents, and joins two separate trees. We don't
allow that in master or release branches.

But you can definitely take a series of commits from a branch and put
that whole series into master, without squashing them into one commit.
You just have to rebase the patches onto master (or cherry-pick each
one of the series in turn, but rebase is easier for multiple patches).
That makes a series of new commits on master, each one corresponding
to one of he commits in the branch (but new commits with new hashes,
because the new commit has a different parent than the one on the
branch did). That's fine, but it's not a "merge commit".


> That basically would somehow record that a series of commits are "related"
> (the merge commit has two parents).  Of course usually the merge commit
> is empty and thus non-existant but then for branch merges it still
> always exists?

A merge commit might be empty, but it's not non-existent. But we don't
allow merge commits on master, and we don't need to allow them in
order to have a series of related commits go in together.

Re: [RFC] add push/pop pragma to control the scope of "using"

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 08:15, 马江  wrote:
>
> Hello,
>   After  some google, I find there is no way to control the scope of
> "using" for the moment.  This seems strange as we definitely need this
> feature especially when writing inline member functions in c++
> headers.
>
>   Currently I am trying to build a simple class in a c++ header file
> as following:
>
> #include 
> using namespace std;
> class mytest
> {
>   string test_name;
>   int test_val;
> public:
>   inline string & get_name () {return test_name;}
> };
>
>   As a experienced  C coder, I know that inline functions must be put
> into headers or else users could only rely on LTO. And I know that to
> use "using" in a header file is a bad idea as it might silently change
> meanings of other codes. However, after I put all my inline functions
> into the header file, I found I must write many "std::string" instead
> of "string" which is totally a torture.

It's really not that bad.

>   Can we add something like "#pragma push_using"  (just like #pragma
> pop_macro)? I believe it's feasible and probably not hard to
> implement.

It would create a non-standard, non-portable dialect of C++. We prefer
to avoid adding non-standard extensions these days. You could propose
it to the C++ committee, but I'm pretty sure they would not want such
a thing.

You can already do it anyway, if you put your own code in a namespace
(which is a good idea anyway):

#include 

namespace foo
{
  using std::string;
  class bar
  {
  string name_;
  public
const string& name() const noexcept { return name_; }
  };
}

This doesn't have all the problems of "using namespace" in a header.

Re: Help with new GCC git workflow...

[Richard Biener]

On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely  wrote:
>
> On Wed, 15 Jan 2020 at 08:40, Richard Biener  
> wrote:
> >
> > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond  wrote:
> > >
> > > Peter Bergner :
> > > > At this point, I get a little confused. :-)  I know to submit my patch
> > > > for review, I'll want to squash my commits down into one patch, but how
> > > > does one do that?  Should I do that now or only when I'm ready to
> > > > push this change to the upstream repo or ???  Do I need to even do that?
> > >
> > > If you want to squash a commit series, the magic is git rebase -i. You
> > > give that a number of commits to look back at at and you'll get a buffer
> > > instructing you how to squash and shuffle that series.  You'll also be 
> > > able
> > > to edit the commit message.
> > >
> > > I like to write really fine-grained commits when I'm developing, then
> > > squash before pushing so the public repo commits always go from "tests
> > > pass" to "test pass".  That way you can do clean bisections on the
> > > public history.
> >
> > The question is wheter one could achieve this with branches?  That is,
> > have master contain a merge commit from a branch that contains the
> > fine-grained commits?  Because for forensics those can be sometimes
> > useful.
>
> A "merge commit" is a special kind of commit that creates a commit
> with two (or more) parents, and joins two separate trees. We don't
> allow that in master or release branches.
>
> But you can definitely take a series of commits from a branch and put
> that whole series into master, without squashing them into one commit.
> You just have to rebase the patches onto master (or cherry-pick each
> one of the series in turn, but rebase is easier for multiple patches).
> That makes a series of new commits on master, each one corresponding
> to one of he commits in the branch (but new commits with new hashes,
> because the new commit has a different parent than the one on the
> branch did). That's fine, but it's not a "merge commit".
>
>
> > That basically would somehow record that a series of commits are "related"
> > (the merge commit has two parents).  Of course usually the merge commit
> > is empty and thus non-existant but then for branch merges it still
> > always exists?
>
> A merge commit might be empty, but it's not non-existent. But we don't
> allow merge commits on master, and we don't need to allow them in
> order to have a series of related commits go in together.

OK, I see.  Guess we should document to not think that a git push
of a series represented as multiple commits are a "single" commit
on master then and that if you do that individual commits need to be
bootstrapped and tested.  So, maybe prevent pushes of multiple
commits for safety?

As for not allowing merges I guess we could eventually relax this
to allow merge commits that are "empty" and the referred refs
have linear history from the merge parent?

Richard.

Re: Help with new GCC git workflow...

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 09:49, Richard Biener  wrote:
>
> On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely  
> wrote:
> >
> > On Wed, 15 Jan 2020 at 08:40, Richard Biener  
> > wrote:
> > >
> > > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond  wrote:
> > > >
> > > > Peter Bergner :
> > > > > At this point, I get a little confused. :-)  I know to submit my patch
> > > > > for review, I'll want to squash my commits down into one patch, but 
> > > > > how
> > > > > does one do that?  Should I do that now or only when I'm ready to
> > > > > push this change to the upstream repo or ???  Do I need to even do 
> > > > > that?
> > > >
> > > > If you want to squash a commit series, the magic is git rebase -i. You
> > > > give that a number of commits to look back at at and you'll get a buffer
> > > > instructing you how to squash and shuffle that series.  You'll also be 
> > > > able
> > > > to edit the commit message.
> > > >
> > > > I like to write really fine-grained commits when I'm developing, then
> > > > squash before pushing so the public repo commits always go from "tests
> > > > pass" to "test pass".  That way you can do clean bisections on the
> > > > public history.
> > >
> > > The question is wheter one could achieve this with branches?  That is,
> > > have master contain a merge commit from a branch that contains the
> > > fine-grained commits?  Because for forensics those can be sometimes
> > > useful.
> >
> > A "merge commit" is a special kind of commit that creates a commit
> > with two (or more) parents, and joins two separate trees. We don't
> > allow that in master or release branches.
> >
> > But you can definitely take a series of commits from a branch and put
> > that whole series into master, without squashing them into one commit.
> > You just have to rebase the patches onto master (or cherry-pick each
> > one of the series in turn, but rebase is easier for multiple patches).
> > That makes a series of new commits on master, each one corresponding
> > to one of he commits in the branch (but new commits with new hashes,
> > because the new commit has a different parent than the one on the
> > branch did). That's fine, but it's not a "merge commit".
> >
> >
> > > That basically would somehow record that a series of commits are "related"
> > > (the merge commit has two parents).  Of course usually the merge commit
> > > is empty and thus non-existant but then for branch merges it still
> > > always exists?
> >
> > A merge commit might be empty, but it's not non-existent. But we don't
> > allow merge commits on master, and we don't need to allow them in
> > order to have a series of related commits go in together.
>
> OK, I see.  Guess we should document to not think that a git push
> of a series represented as multiple commits are a "single" commit
> on master

Well yes, because if you push a series of commits then you push ... a
series of commits.

When you push something upstream you make the upstream repo have
exactly the same commits as you have locally. There is no squashing or
flattening involved. The remote repo's HEAD becomes the same commit ID
as your HEAD.

(Before an expert corrects me: strictly speaking, the remote's branch
becomes whatever you push, which doesn't have to be HEAD because you
could do 'git push origin some_commit_hash:master' but in the common
case you just push your HEAD and that becomes the new branch tip on
the remote).


>then and that if you do that individual commits need to be
> bootstrapped and tested.  So, maybe prevent pushes of multiple
> commits for safety?

Please no!


> As for not allowing merges I guess we could eventually relax this
> to allow merge commits that are "empty" and the referred refs
> have linear history from the merge parent?

There's no point. If you have a simple linear history where each
commit has a single parent, there is no merge commit.

I highly recommend this video, to understand the Git model:
https://www.youtube.com/watch?v=1ffBJ4sVUb4
I know it's long, but it's really worth it.

1-800-GIT-HELP question

[Gaius Mulley]

Hello,

Firstly many thanks to all who have worked on the git migration and also
for the offer of help :-)

I'm seeking a little advice on an efficient way to combine the gm2 git
repro with the gcc git repro.  When gcc was using subversion I had a
script which untared the gm2 git over the subversion, applied local
patches to the gcc tree and then it was ready for use.  I could git diff
in the gm2 tree and svn diff in the gcc tree - etc.

I wonder if a similar model can be achieved now gcc uses git?

In essence the gm2 front end adds three subtrees to gcc

libgm2

gcc/m2

gcc/testsuite/gm2

currently these are all in one repro
gm2/gcc-versionno/{libgm2,gcc/m2,gcc/testsuite/gm2}.

http://git.savannah.gnu.org/cgit/gm2.git/tree

I'm a little cautious of choosing an initial working model without
knowing the implications.  There seem to be many possible solutions
(subtree, submodule) to name but two.

Disk space is not a concern, the time to recreate a working tree is more
important.

regards,
Gaius

Re: Do we want to add -fsanitize=function?

[Martin Liška]

On 1/14/20 4:30 PM, Jakub Jelinek wrote:

On Tue, Jan 14, 2020 at 04:15:54PM +0100, Martin Liška wrote:

On 1/14/20 3:00 PM, Jakub Jelinek wrote:

But then the compiler should just fail if you mix the two, rather than
emitting something that doesn't work at all.
Or better fix the design, so that it can grok an endbr64 together with
the following jump as another magic.


Sure. One can make an error when these 2 options are mixed together.
So the question still remains opened, do we want to implement the
sanitizer feature?


IMHO not for GCC 10, for GCC 11, it really sounds too hackish, so unsure.


That's my impression as well that the selected approach is quite a hack.
So unless somebody is really interested I'm not planning to work
on that for GCC 11.

Martin


It should at least cover more than one arch and have these issues like CET
etc. discussed upstream.

Jakub

Re: 1-800-GIT-HELP question

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 10:14, Gaius Mulley  wrote:
>
>
> Hello,
>
> Firstly many thanks to all who have worked on the git migration and also
> for the offer of help :-)
>
> I'm seeking a little advice on an efficient way to combine the gm2 git
> repro with the gcc git repro.  When gcc was using subversion I had a
> script which untared the gm2 git over the subversion, applied local
> patches to the gcc tree and then it was ready for use.  I could git diff
> in the gm2 tree and svn diff in the gcc tree - etc.
>
> I wonder if a similar model can be achieved now gcc uses git?
>
> In essence the gm2 front end adds three subtrees to gcc
>
> libgm2
>
> gcc/m2
>
> gcc/testsuite/gm2
>
> currently these are all in one repro
> gm2/gcc-versionno/{libgm2,gcc/m2,gcc/testsuite/gm2}.
>
> http://git.savannah.gnu.org/cgit/gm2.git/tree
>
> I'm a little cautious of choosing an initial working model without
> knowing the implications.  There seem to be many possible solutions
> (subtree, submodule) to name but two.

Personally I hate submodules, and I've never used subtree. If you need
to make modifications to files in GCC (rather than just adding
completely new dirs) then I don't think submodules would work at all,
I don't know about subtrees.

Is there a reason you can't just make it a branch of the GCC repo?

It would mean you need to merge from upstream GCC into your repo,
rather than just dropping your repo into/onto a GCC clone, but to me
it seems the more natural solution. The modifications to the files in
the GCC tree would also be in your branch (and properly tracked in
git), and so not need to be done manually after untarring gm2 into the
GCC tree.

It would mean your gm2 repo would contain the full GCC history, but
you said disk space isn't a concern. A checkout would need to check
out the full GCC tree as well, but presumably you need some way to
obtain that anyway if you're going to unpack/checkout/whatever the gm2
repo inside the GCC tree.

Re: 1-800-GIT-HELP question

[Matthew Malcomson]

On 15/01/2020 10:13, Gaius Mulley wrote:
> 
> Hello,
> 
> Firstly many thanks to all who have worked on the git migration and also
> for the offer of help :-)
> 
> I'm seeking a little advice on an efficient way to combine the gm2 git
> repro with the gcc git repro.  When gcc was using subversion I had a
> script which untared the gm2 git over the subversion, applied local
> patches to the gcc tree and then it was ready for use.  I could git diff
> in the gm2 tree and svn diff in the gcc tree - etc.
> 
> I wonder if a similar model can be achieved now gcc uses git?
> 
> In essence the gm2 front end adds three subtrees to gcc
> 
>  libgm2
>  
>  gcc/m2
>  
>  gcc/testsuite/gm2
> 
> currently these are all in one repro
> gm2/gcc-versionno/{libgm2,gcc/m2,gcc/testsuite/gm2}.
> 
> http://git.savannah.gnu.org/cgit/gm2.git/tree
> 
> I'm a little cautious of choosing an initial working model without
> knowing the implications.  There seem to be many possible solutions
> (subtree, submodule) to name but two.
> 
> Disk space is not a concern, the time to recreate a working tree is more
> important.
> 
> regards,
> Gaius
> 

I'm not sure if you even can use a subtree/submodule at the top level -- 
I'm under the impression that when creating one you need to put the 
entire other repository in a subdirectory.
(If that's wrong please correct me -- it sounds like it might be useful 
;-) )


Maybe you could look into the `--work-tree` and `--git-dir` options?



One approach would be to have your gm2 repository information under 
`.gm2-git` and your gcc repository information under `.git`.

Then you might be able to create an alias for git that means `git gm2` 
expands to `git --git-dir=$(root directory)/.gm2-git` and everything 
should just work.

(I say might since I'm not 100% sure you can expand to `root directory` 
automatically in a git alias -- maybe through another git alias that 
says `root = !pwd`).

Re: 1-800-GIT-HELP question

[Andrew Pinski]

On Wed, Jan 15, 2020 at 2:14 AM Gaius Mulley  wrote:
>
>
> Hello,
>
> Firstly many thanks to all who have worked on the git migration and also
> for the offer of help :-)
>
> I'm seeking a little advice on an efficient way to combine the gm2 git
> repro with the gcc git repro.  When gcc was using subversion I had a
> script which untared the gm2 git over the subversion, applied local
> patches to the gcc tree and then it was ready for use.  I could git diff
> in the gm2 tree and svn diff in the gcc tree - etc.
>
> I wonder if a similar model can be achieved now gcc uses git?
>
> In essence the gm2 front end adds three subtrees to gcc
>
> libgm2
>
> gcc/m2
>
> gcc/testsuite/gm2
>
> currently these are all in one repro
> gm2/gcc-versionno/{libgm2,gcc/m2,gcc/testsuite/gm2}.
>
> http://git.savannah.gnu.org/cgit/gm2.git/tree
>
> I'm a little cautious of choosing an initial working model without
> knowing the implications.  There seem to be many possible solutions
> (subtree, submodule) to name but two.
>
> Disk space is not a concern, the time to recreate a working tree is more
> important.

One thing which you could do is kinda of what glibc did when they
merged glibc and glibc-ports.
Really it would useful if you get GM2 into the base sources of gcc
instead for GCC 11 :).

Thanks,
Andrew Pinski

>
> regards,
> Gaius

Re: 1-800-GIT-HELP question

[Gaius Mulley]

Jonathan Wakely  writes:

> Is there a reason you can't just make it a branch of the GCC repo?
>
> It would mean you need to merge from upstream GCC into your repo,
> rather than just dropping your repo into/onto a GCC clone, but to me
> it seems the more natural solution. The modifications to the files in
> the GCC tree would also be in your branch (and properly tracked in
> git), and so not need to be done manually after untarring gm2 into the
> GCC tree.
>
> It would mean your gm2 repo would contain the full GCC history, but
> you said disk space isn't a concern. A checkout would need to check
> out the full GCC tree as well, but presumably you need some way to
> obtain that anyway if you're going to unpack/checkout/whatever the gm2
> repo inside the GCC tree.

Hello,

awesome thank you - yes indeed the branch suggestion makes a lot of
sense,

Re: Help with new GCC git workflow...

[Eric S. Raymond]

Richard Biener :
> > I like to write really fine-grained commits when I'm developing, then
> > squash before pushing so the public repo commits always go from "tests
> > pass" to "test pass".  That way you can do clean bisections on the
> > public history.
> 
> The question is wheter one could achieve this with branches?  That is,
> have master contain a merge commit from a branch that contains the
> fine-grained commits?  Because for forensics those can be sometimes
> useful.

Of course you can do this.

Git gives you a number of different possbilities here. You get to chose
based onm how you like your histiry to look.

Discussion of my choice is here:

https://blog.ntpsec.org/2017/04/09/single-head-provable-steps.html
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: 1-800-GIT-HELP question

[Gaius Mulley]

Andrew Pinski  writes:

>
> One thing which you could do is kinda of what glibc did when they
> merged glibc and glibc-ports.
> Really it would useful if you get GM2 into the base sources of gcc
> instead for GCC 11 :).

Hello,

yes indeed this is a huge priority for gm2 - all the big issues are
resolved now (licensing/gpl3/!libpth).  So I'm really hoping this can be
achieved,

regards,
Gaius

Re: 1-800-GIT-HELP question

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 11:21, Gaius Mulley  wrote:
>
> Andrew Pinski  writes:
>
> >
> > One thing which you could do is kinda of what glibc did when they
> > merged glibc and glibc-ports.
> > Really it would useful if you get GM2 into the base sources of gcc
> > instead for GCC 11 :).
>
> Hello,
>
> yes indeed this is a huge priority for gm2 - all the big issues are
> resolved now (licensing/gpl3/!libpth).  So I'm really hoping this can be
> achieved,

Great!

That's even more reason to do it as a branch in (your copies of) the
GCC tree then: it will make the process of submitting patches for
inclusion upstream much more straightforward!

Re: 1-800-GIT-HELP question

[Gaius Mulley]

Jonathan Wakely  writes:

> On Wed, 15 Jan 2020 at 11:21, Gaius Mulley  wrote:
>>
>> Andrew Pinski  writes:
>>
>> >
>> > One thing which you could do is kinda of what glibc did when they
>> > merged glibc and glibc-ports.
>> > Really it would useful if you get GM2 into the base sources of gcc
>> > instead for GCC 11 :).
>>
>> Hello,
>>
>> yes indeed this is a huge priority for gm2 - all the big issues are
>> resolved now (licensing/gpl3/!libpth).  So I'm really hoping this can be
>> achieved,
>
> Great!
>
> That's even more reason to do it as a branch in (your copies of) the
> GCC tree then: it will make the process of submitting patches for
> inclusion upstream much more straightforward!

yes this is good to see triangulation of decisions along the same
direction of travel - thank you!

Re: Silly GIT related question

[Segher Boessenkool]

On Wed, Jan 15, 2020 at 03:11:13AM +, Gary Oblock wrote:
> If you just do a clone and don't checkout a branch, is this equivalent
> the  top of the trunk in the old scheme? If not then how do I get the
> top of trunk?

After doing the clone, run "git status" to see where you're at.  Always
run git status, whenever you're not 100% what the state might be, and
also when you think you do know.

It can read your mind even: it often tells you what you want to do.


Segher

gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

Hi!

As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
a simple
git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
which merged in just a few hours from trunk, but that resulted in
20 separate mails to gcc-cvs ml.
Is that what we want?  I mean it doesn't scale well, even if everybody has
just a couple of personal branches + few vendor branches for all, if some of
them will be tracking master or release branches, if each such push
pushes all the commits again, there will be tens of thousands of mails.
And forcing everybody to squash all merge commits because of this is
undesirable.
Could we somehow detect merges from other branches (or say only master or
release branches) and don't send mails for those and send just a mail for
the merge commit?
Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?

Jakub

Re: Help with new GCC git workflow...

[Jason Merrill]

On 1/15/20 4:55 AM, Jonathan Wakely wrote:

On Wed, 15 Jan 2020 at 09:49, Richard Biener  wrote:


On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely  wrote:


On Wed, 15 Jan 2020 at 08:40, Richard Biener  wrote:


On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond  wrote:


Peter Bergner :

At this point, I get a little confused. :-)  I know to submit my patch
for review, I'll want to squash my commits down into one patch, but how
does one do that?  Should I do that now or only when I'm ready to
push this change to the upstream repo or ???  Do I need to even do that?


If you want to squash a commit series, the magic is git rebase -i. You
give that a number of commits to look back at at and you'll get a buffer
instructing you how to squash and shuffle that series.  You'll also be able
to edit the commit message.

I like to write really fine-grained commits when I'm developing, then
squash before pushing so the public repo commits always go from "tests
pass" to "test pass".  That way you can do clean bisections on the
public history.


The question is wheter one could achieve this with branches?  That is,
have master contain a merge commit from a branch that contains the
fine-grained commits?  Because for forensics those can be sometimes
useful.


A "merge commit" is a special kind of commit that creates a commit
with two (or more) parents, and joins two separate trees. We don't
allow that in master or release branches.

But you can definitely take a series of commits from a branch and put
that whole series into master, without squashing them into one commit.
You just have to rebase the patches onto master (or cherry-pick each
one of the series in turn, but rebase is easier for multiple patches).
That makes a series of new commits on master, each one corresponding
to one of he commits in the branch (but new commits with new hashes,
because the new commit has a different parent than the one on the
branch did). That's fine, but it's not a "merge commit".



That basically would somehow record that a series of commits are "related"
(the merge commit has two parents).  Of course usually the merge commit
is empty and thus non-existant but then for branch merges it still
always exists?


A merge commit might be empty, but it's not non-existent. But we don't
allow merge commits on master, and we don't need to allow them in
order to have a series of related commits go in together.


OK, I see.  Guess we should document to not think that a git push
of a series represented as multiple commits are a "single" commit
on master


Well yes, because if you push a series of commits then you push ... a
series of commits.

When you push something upstream you make the upstream repo have
exactly the same commits as you have locally. There is no squashing or
flattening involved. The remote repo's HEAD becomes the same commit ID
as your HEAD.

(Before an expert corrects me: strictly speaking, the remote's branch
becomes whatever you push, which doesn't have to be HEAD because you
could do 'git push origin some_commit_hash:master' but in the common
case you just push your HEAD and that becomes the new branch tip on
the remote).



then and that if you do that individual commits need to be
bootstrapped and tested.  So, maybe prevent pushes of multiple
commits for safety?


Please no!



As for not allowing merges I guess we could eventually relax this
to allow merge commits that are "empty" and the referred refs
have linear history from the merge parent?


There's no point. If you have a simple linear history where each
commit has a single parent, there is no merge commit.


The only point is the grouping richi mentions.

To that purpose we *could* allow --no-ff merges that otherwise would 
have been fast-forward, but allowing such merges without allowing any 
other merges would be difficult to enforce.  I don't think it's worth 
bothering.


Jason

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Wed, 15 Jan 2020, Jakub Jelinek wrote:

> Hi!
> 
> As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
> a simple
> git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
> git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
> which merged in just a few hours from trunk, but that resulted in
> 20 separate mails to gcc-cvs ml.

Joel, this is definitely a question for you; it's beyond my expertise in 
the working of the hooks.  The issue is that when a merge commit is 
pushed, we only want mails for commits that are new *to the repository* - 
not those that are already in the repository (accessible from some other 
ref before the ref update being processed by the hook comes into effect), 
but are new *to the branch*.

I think there's a similar issue not just for merges but for 
non-fast-forward pushes as well.  As a glibc example, consider 
 and the long 
series of subsequent mails in the glibc-cvs archives.  It's correct that 
the five or so rebased patches on the branch got mailed out again.  It's 
*not* desirable that the 50 or so patches that were already on master, 
that the branch got rebased on top of, got mailed out again.

> Is that what we want?  I mean it doesn't scale well, even if everybody has
> just a couple of personal branches + few vendor branches for all, if some of
> them will be tracking master or release branches, if each such push
> pushes all the commits again, there will be tens of thousands of mails.
> And forcing everybody to squash all merge commits because of this is
> undesirable.
> Could we somehow detect merges from other branches (or say only master or
> release branches) and don't send mails for those and send just a mail for
> the merge commit?
> Or, if that is not possible, disable gcc-cvs mail for vendor and private
> branches altogether?

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

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Wed, Jan 15, 2020 at 02:56:45PM +, Joseph Myers wrote:
> > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
> > a simple
> > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
> > git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
> > which merged in just a few hours from trunk, but that resulted in
> > 20 separate mails to gcc-cvs ml.
> 
> Joel, this is definitely a question for you; it's beyond my expertise in 
> the working of the hooks.  The issue is that when a merge commit is 
> pushed, we only want mails for commits that are new *to the repository* - 
> not those that are already in the repository (accessible from some other 
> ref before the ref update being processed by the hook comes into effect), 
> but are new *to the branch*.

Yeah.  For release branches I think we want mails for all changes, but
then we don't allow merge commits there; for cherry-picked patches e.g. from
trunk to release branches we should still send mail.

> I think there's a similar issue not just for merges but for 
> non-fast-forward pushes as well.  As a glibc example, consider 
>  and the long 
> series of subsequent mails in the glibc-cvs archives.  It's correct that 
> the five or so rebased patches on the branch got mailed out again.  It's 
> *not* desirable that the 50 or so patches that were already on master, 
> that the branch got rebased on top of, got mailed out again.

Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Wed, 15 Jan 2020, Jakub Jelinek wrote:

> On Wed, Jan 15, 2020 at 02:56:45PM +, Joseph Myers wrote:
> > > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
> > > a simple
> > > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
> > > git push origin 
> > > redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
> > > which merged in just a few hours from trunk, but that resulted in
> > > 20 separate mails to gcc-cvs ml.
> > 
> > Joel, this is definitely a question for you; it's beyond my expertise in 
> > the working of the hooks.  The issue is that when a merge commit is 
> > pushed, we only want mails for commits that are new *to the repository* - 
> > not those that are already in the repository (accessible from some other 
> > ref before the ref update being processed by the hook comes into effect), 
> > but are new *to the branch*.
> 
> Yeah.  For release branches I think we want mails for all changes, but
> then we don't allow merge commits there; for cherry-picked patches e.g. from
> trunk to release branches we should still send mail.

A cherry-picked commit has a different commit id from the original, so is 
a new commit in the repository.

Note: the old post-receive-email example hook shipped with git does the 
"only commits new to the repository" thing.  Its form of the logic 
(function show_new_revisions) appears to be "only commits not reachable 
from any ref in refs/heads", which it converts into a list of negated 
revisions to pass to git rev-list when computing the new commits to show.

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

Re: [RFC] add push/pop pragma to control the scope of "using"

[Jiang Ma]

Thanks  for the kindly reply!
> It would create a non-standard, non-portable dialect of C++. We prefer
> to avoid adding non-standard extensions these days. You could propose
>it to the C++ committee, but I'm pretty sure they would not want such
>a thing.
  Indeed, pragma is not portable.  I believe you are right that the
C++ committee would not want such a thing   :-)

> This doesn't have all the problems of "using namespace" in a header.
  Yes, This is a workaround I have considered.  I'm a C++ newbie, and
still not used to  put everything into a namespace. But I am agree
this probably is the best way.

Thanks again for your help!

Jonathan Wakely  于2020年1月15日周三 下午5:37写道：
>
> On Wed, 15 Jan 2020 at 08:15, 马江  wrote:
> >
> > Hello,
> >   After  some google, I find there is no way to control the scope of
> > "using" for the moment.  This seems strange as we definitely need this
> > feature especially when writing inline member functions in c++
> > headers.
> >
> >   Currently I am trying to build a simple class in a c++ header file
> > as following:
> >
> > #include 
> > using namespace std;
> > class mytest
> > {
> >   string test_name;
> >   int test_val;
> > public:
> >   inline string & get_name () {return test_name;}
> > };
> >
> >   As a experienced  C coder, I know that inline functions must be put
> > into headers or else users could only rely on LTO. And I know that to
> > use "using" in a header file is a bad idea as it might silently change
> > meanings of other codes. However, after I put all my inline functions
> > into the header file, I found I must write many "std::string" instead
> > of "string" which is totally a torture.
>
> It's really not that bad.
>
> >   Can we add something like "#pragma push_using"  (just like #pragma
> > pop_macro)? I believe it's feasible and probably not hard to
> > implement.
>
> It would create a non-standard, non-portable dialect of C++. We prefer
> to avoid adding non-standard extensions these days. You could propose
> it to the C++ committee, but I'm pretty sure they would not want such
> a thing.
>
> You can already do it anyway, if you put your own code in a namespace
> (which is a good idea anyway):
>
> #include 
>
> namespace foo
> {
>   using std::string;
>   class bar
>   {
>   string name_;
>   public
> const string& name() const noexcept { return name_; }
>   };
> }
>
> This doesn't have all the problems of "using namespace" in a header.

Re: [RFC] add push/pop pragma to control the scope of "using"

[Jonathan Wakely]

On Wed, 15 Jan 2020 at 15:37, Jiang Ma  wrote:
>
> Thanks  for the kindly reply!
> > It would create a non-standard, non-portable dialect of C++. We prefer
> > to avoid adding non-standard extensions these days. You could propose
> >it to the C++ committee, but I'm pretty sure they would not want such
> >a thing.
>   Indeed, pragma is not portable.  I believe you are right that the
> C++ committee would not want such a thing   :-)

I mean they wouldn't want it under any syntax, not just as a pragma.

It's a terrible fit for a pragma anyway.

Re: [RFC] add push/pop pragma to control the scope of "using"

[Jiang Ma]

Agree!
I will put my definitions into a namespace as you suggested.

Jonathan Wakely  于2020年1月15日周三 下午11:42写道：
>
> On Wed, 15 Jan 2020 at 15:37, Jiang Ma  wrote:
> >
> > Thanks  for the kindly reply!
> > > It would create a non-standard, non-portable dialect of C++. We prefer
> > > to avoid adding non-standard extensions these days. You could propose
> > >it to the C++ committee, but I'm pretty sure they would not want such
> > >a thing.
> >   Indeed, pragma is not portable.  I believe you are right that the
> > C++ committee would not want such a thing   :-)
>
> I mean they wouldn't want it under any syntax, not just as a pragma.
>
> It's a terrible fit for a pragma anyway.

Re: [RFC] add push/pop pragma to control the scope of "using"

[Jiang Ma]

Thanks for the kindly reply!
> Why is mytest in the global namespace?
I'm a C++ newbie, and still not used to  put everything into a
namespace. Sorry to bother...

> We try to avoid extensions in gcc, you may want to propose this to the C++
> standard committee first. However, you should first check if modules
> (C++20) affect the issue.
  Thanks for the detailed explanation!  It seems that my situation is
a corner case as normally definitions should be put into a namespace.
So I will not try to bother the C++ standard committee. Thanks you
again for your help!

Marc Glisse  于2020年1月15日周三 下午4:32写道：
>
> On Wed, 15 Jan 2020, 马江 wrote:
>
> > Hello,
> >  After  some google, I find there is no way to control the scope of
> > "using" for the moment.  This seems strange as we definitely need this
> > feature especially when writing inline member functions in c++
> > headers.
> >
> >  Currently I am trying to build a simple class in a c++ header file
> > as following:
> >
> > #include 
> > using namespace std;
> > class mytest
> > {
> >  string test_name;
> >  int test_val;
> > public:
> >  inline string & get_name () {return test_name;}
> > };
>
> Why is mytest in the global namespace?
>
> >  As a experienced  C coder, I know that inline functions must be put
> > into headers or else users could only rely on LTO. And I know that to
> > use "using" in a header file is a bad idea as it might silently change
> > meanings of other codes. However, after I put all my inline functions
> > into the header file, I found I must write many "std::string" instead
> > of "string" which is totally a torture.
> >  Can we add something like "#pragma push_using"  (just like #pragma
> > pop_macro)? I believe it's feasible and probably not hard to
> > implement.
>
> We try to avoid extensions in gcc, you may want to propose this to the C++
> standard committee first. However, you should first check if modules
> (C++20) affect the issue.
>
> --
> Marc Glisse

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/15/20 9:56 AM, Joseph Myers wrote:

On Wed, 15 Jan 2020, Jakub Jelinek wrote:


Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?


I think this is desirable.  gcc-cvs should only mail about changes to 
master and release branches.


Jason

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Wed, 15 Jan 2020, Jason Merrill wrote:

> On 1/15/20 9:56 AM, Joseph Myers wrote:
> > On Wed, 15 Jan 2020, Jakub Jelinek wrote:
> > 
> > > Or, if that is not possible, disable gcc-cvs mail for vendor and private
> > > branches altogether?
> 
> I think this is desirable.  gcc-cvs should only mail about changes to master
> and release branches.

I thinks commit mails for changes to all branches are desirable (including 
refs/heads/devel/ branches, including user and vendor branches) - but they 
should only be for changes that are new to the repository.  Existing 
practice in SVN was that all branches generated mails, we simply didn't 
have so many branches.

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

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/15/20 11:30 AM, Joseph Myers wrote:

On Wed, 15 Jan 2020, Jason Merrill wrote:


On 1/15/20 9:56 AM, Joseph Myers wrote:

On Wed, 15 Jan 2020, Jakub Jelinek wrote:


Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?


I think this is desirable.  gcc-cvs should only mail about changes to master
and release branches.


I thinks commit mails for changes to all branches are desirable (including
refs/heads/devel/ branches, including user and vendor branches) - but they
should only be for changes that are new to the repository.  Existing
practice in SVN was that all branches generated mails, we simply didn't
have so many branches.


User branches in particular are likely to be very messy in the git 
world; in the old git mirror I would occasionally push a personal branch 
with work-in-progress patches that aren't nicely organized.  Perhaps one 
mail per push for those branches, rather than one per commit?


Jason

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Iain Sandoe]

Joseph Myers  wrote:

> On Wed, 15 Jan 2020, Jason Merrill wrote:
> 
>> On 1/15/20 9:56 AM, Joseph Myers wrote:
>>> On Wed, 15 Jan 2020, Jakub Jelinek wrote:
>>> 
 Or, if that is not possible, disable gcc-cvs mail for vendor and private
 branches altogether?
>> 
>> I think this is desirable.  gcc-cvs should only mail about changes to master
>> and release branches.
> 
> I thinks commit mails for changes to all branches are desirable (including 
> refs/heads/devel/ branches, including user and vendor branches) - but they 
> should only be for changes that are new to the repository.  Existing 
> practice in SVN was that all branches generated mails, we simply didn't 
> have so many branches.

For user/vendor branches that are rebased (a desirable action), is there any
mechanism for excluding unchanged rebased commits from being seen as
 “new”?

I’m guessing that public development branches will probably gravitate to the
no non-FF mode, if they are to be used by people other than the primary author

.. although that does somewhat limit things; rebasing WIP onto trunk and
reorganising / squashing is useful as well.

Iain

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Richard Earnshaw (lists)]

On 15/01/2020 16:30, Joseph Myers wrote:

On Wed, 15 Jan 2020, Jason Merrill wrote:


On 1/15/20 9:56 AM, Joseph Myers wrote:

On Wed, 15 Jan 2020, Jakub Jelinek wrote:


Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?


I think this is desirable.  gcc-cvs should only mail about changes to master
and release branches.


I thinks commit mails for changes to all branches are desirable (including
refs/heads/devel/ branches, including user and vendor branches) - but they
should only be for changes that are new to the repository.  Existing
practice in SVN was that all branches generated mails, we simply didn't
have so many branches.



How about separate email list(s) for the vendor and personal spaces?  I 
do think changes there should be visible, but perhaps fewer folk will be 
interested in tracking them at the same level.


R.

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/15/20 11:37 AM, Iain Sandoe wrote:

Joseph Myers  wrote:


On Wed, 15 Jan 2020, Jason Merrill wrote:


On 1/15/20 9:56 AM, Joseph Myers wrote:

On Wed, 15 Jan 2020, Jakub Jelinek wrote:


Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?


I think this is desirable.  gcc-cvs should only mail about changes to master
and release branches.


I thinks commit mails for changes to all branches are desirable (including
refs/heads/devel/ branches, including user and vendor branches) - but they
should only be for changes that are new to the repository.  Existing
practice in SVN was that all branches generated mails, we simply didn't
have so many branches.


For user/vendor branches that are rebased (a desirable action), is there any
mechanism for excluding unchanged rebased commits from being seen as
  “new”?

I’m guessing that public development branches will probably gravitate to the
no non-FF mode, if they are to be used by people other than the primary author


Except that long-lived public development branches will need to merge 
master periodically, and that will be a non-FF merge.


Jason

Re: Whitespace at the start of first line of commit

[Joseph Myers]

On Tue, 14 Jan 2020, Joseph Myers wrote:

> On Tue, 14 Jan 2020, Jakub Jelinek wrote:
> 
> > (untested), another, suggested by Richard on IRC, would be to reject
> > commits where the first line starts with whitespace.
> 
> I'd suggest making the hooks reject whitespace at the start of the first 
> line of the commit message.

Unfortunately, that's not as simple to implement as I'd hoped, because 
git.py:git_run removes all leading and trailing whitespace from the output 
of the git command it runs, so the code checking commit messages can't 
tell whether there was whitespace at the start of the first line (or the 
end of the last line, I suppose) at all.  I don't know what git commands 
the hooks are using that might depend on removing leading whitespace (no 
doubt the removal of trailing whitespace is needed in various places to 
remove a final newline output by commands giving single-line output).

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

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Wed, 15 Jan 2020, Richard Earnshaw (lists) wrote:

> How about separate email list(s) for the vendor and personal spaces?  I do
> think changes there should be visible, but perhaps fewer folk will be
> interested in tracking them at the same level.

That's currently documented as a feature not supported by the hooks (the 
script to determine the lists to use only receives information about the 
files changed, not about the refs being updated).

I've now filed issues at https://github.com/AdaCore/git-hooks/issues for 
what I think are all the feature requests we have so far for making the 
hooks more configurable so particular features of use to GCC can be 
implemented without needing to patch the hooks themselves as at present.  
If you have a feature request of the form "the hooks should allow 
configuring X" it probably makes sense to file it there to help Joel track 
it.  However, policy questions about how we should configure the hooks for 
GCC (whether or not they depend on new hook features) would best be 
discussed here.

I'll add a check to the GCC hooks for commit messages whose first line is 
a single word, to prevent pushing commits whose summary is just 
"gcc/ChangeLog:" or similar.

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

GCC 10: Add driver options -mbranches-within-32B-boundaries and -malign-branch* for x86

[Fāng-ruì Sòng via gcc]

H.J. Lu's https://sourceware.org/ml/binutils/2019-11/msg00174.html
assembler patch series added -mbranches-within-32B-boundaries and some
fine-grained tuning options to GNU as, which are considered a pretty
important performance mitigation of a serious CPU bug
(https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf
and see the news around this).

It seems that there is still no GCC driver option yet. Currently users
are expected to use:

-Xassembler -mbranches-within-32B-boundaries
-Wa,-mbranches-within-32B-boundaries

I think a compiler driver option will be very important, and users
should use gcc/g++/gfortran/gdc -mbranches-within-32B-boundaries
directly, instead of -Wa,/-Xassembler.

* The compiler may selectively disable some code structs from being
segment override prefixed/NOP padded. Such code may be sensitive to
the exact code sequence. This can be implemented as some assembly
directives (not yet decided). We need a mechanism to communicate this
fact to the compiler. -Wa, is too late.
* The compiler may add assembly directives only in hot code guided by
profile [3]. The code size increase[1] 1%~5% is unacceptable in many
scenarios. Avoiding annotating cold code can mitigate many code
size/memory usage increase problems.

For at least the two reasons, a compiler driver option for the
prominent user-facing option (-mbranches-within-32B-boundaries) will
be useful. An assembler option is too late to make the decisions.
Clang 10 will have a driver option -mbranches-within-32B-boundaries
(along with -malign-branch=, -malign-branch-boundary=, and
-malign-branch-prefix-size=)[3].

I am not clear about GCC 10 release schedule, but it seems GCC 10 is
at a fairly late stage
(https://gcc.gnu.org/ml/gcc/2020-01/msg00199.html). I send this email
in the hope that GCC 10 can have a driver option
-mbranches-within-32B-boundaries (and probably the 3 -malign-branch*),
so that users will not use -mbranches-within-32B-boundaries with one
compiler (Clang) while -Wa,-mbranches-within-32B-boundaries with
another (GCC).

[1]: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137610.html
[2]: https://reviews.llvm.org/D72721
[3]: https://reviews.llvm.org/rG5ca24d09aefaedf8e4148c7fce4b4ab0c4ecc72a


-- 
宋方睿

Re: PPC64 libmvec implementation of sincos

[GT]

‐‐‐ Original Message ‐‐‐
On Thursday, January 9, 2020 8:42 AM, Richard Biener 
 wrote:

>
> As for the other question for testing you probably want to provide a
> OMP simd declaration
> of a function like
>
> _Complex double mycexpi (double);
>
> and make a testcase like
>
> void foo (_Complex double * __restrict out, double *in)
> {
> for (int i = 0; i < 1024; ++i)
> {
> out[i] = mycexpi (in[i]);
> }
> }
>
> or eventually with two output arrays and explicit __real/__imag
> processing. The real
> and main question is how is the OMP SIMD declaration of mycexpi looking like?
>
> So I'd completely side-step sincos() and GCCs sincos() ->
> __builtin_cepxi transform
> and concentrate on OMP SIMD of a function with the signature we need to 
> handle.
>
> Richard.

I think what is required here is to attach either #pragma omp declare simd or 
__attribute__ ((simd))
to the declaration of builtin cexpi. In gcc/builtins.def, some attributes are 
provided during
creation of cexpi (line 656, call containing BUILT_IN_CEXPI). Attaching the 
simd attributes to
function declarations is how sin, cos, and the other math functions were 
handled in math-vector.h
glibc header file.

GCC GSoC 2020: Call for mentors and project ideas

[Martin Jambor]

Hello,

Google Summer of Code (aka GSoC) 2020 yesterday started accepting
Organization Applications.  I believe the last year was very successful
and so think that we want to take part again this year again.  I'll be
happy to volunteer to be the main Org Admin for GCC again (so let me
know if you think I shouldn't or that someone else should, but otherwise
I'll assume that I probably will). The deadline to apply is February
5th, so in the next three weeks we need to work on our project ideas and
have a list of willing mentors.

Therefore, first and foremost, I would like to ask all (moderately)
seasoned GCC contributors to consider mentoring a student this year and
ideally also come up with a project that they would like to lead.  I'm
collecting proposal on our wiki page
https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the
top list there.  Or, if you are unsure, post your offer and project idea
as a reply here to the mailing list.

Eventually each developed project should have a) a project
title/description b) more detailed description of the project (2-5
sentences) c) expected outcomes d) skills required/preferred and e)
possible mentors [1].

Project ideas that come without an offer to also mentor them are always
fun to discuss, by all means feel free to reply to this email with yours
and I will attempt to find a mentor, but please be aware that we can
only use the suggestion it if we actually find one.

Everybody in the GCC community is invited to go over
https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
otherwise bad project suggestions and help improve viable ones which are
not yet viable.  I would especially want to ask GFortran and libstdc++
people to do so.

Finally, please continue helping (prospective) students figure stuff out
about GCC like you always do.  So far I think all of them enjoyed
working with us, even if many sometimes struggled with GCC's complexity.

More information together with GSoC 2020 time line is available at
https://summerofcode.withgoogle.com

Thank you, let's hope we attract some good young talent again this year.

Martin


[1] https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list