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 t
‐‐‐ 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 (_Comp
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/sup
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 s
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
>
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 t
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
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
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
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
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
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 chec
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
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 s
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 believ
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
> > > red
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
>
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 ju
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 po
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 separa
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
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
>> >
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,
>
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
re
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 achi
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
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 s
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
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 sub
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 i
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 subvers
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 thi
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
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
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
> > > d
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
>
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
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 tryi
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 followi
39 matches
Mail list logo
