Re: Obsolete powerpc*-*-*spe*

2017-02-17 Thread Richard Biener
On Fri, Feb 17, 2017 at 1:10 AM, David Edelsohn wrote: > On Thu, Feb 16, 2017 at 3:53 PM, Sandra Loosemore > wrote: >> On 02/16/2017 03:19 PM, Segher Boessenkool wrote: >>> >>> On Thu, Feb 16, 2017 at 02:49:47PM -0700, Sandra Loosemore wrote: > > I propose to mark powerpc*-*-*spe* as obso

Re: Obsolete powerpc*-*-*spe*

2017-02-17 Thread Janne Blomqvist
On Fri, Feb 17, 2017 at 11:19 AM, Richard Biener wrote: > I'd like us to be more agressive in deprecating/removing of unmaintained > parts of GCC. It's not only target/host support but also things like > unmaintained > language extensions (or frontends) as well as optimization passes. So... what

Improving code generation in the nvptx back end

2017-02-17 Thread Thomas Schwinge
Hi! I'm not all to familiar with the nvptx back end, and I keep forgetting (and then later re-learning) a lot of PTX details, so please bear with me... I'd like to discuss/gather some ideas about how to improve (whatever that may mean exactly) code generation in the nvptx back end. We're curren

Re: Improving code generation in the nvptx back end

2017-02-17 Thread Thomas Schwinge
Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: > [...] for "normal" functions there is no reason to use the > ".param" space for passing arguments in and out of functions. We can > then get rid of the boilerplate code to move ".param %in_ar*" into ".reg > %ar*", and the other way round for "%va

Re: Obsolete powerpc*-*-*spe*

2017-02-17 Thread Nathan Sidwell
On 02/17/2017 04:19 AM, Richard Biener wrote: I'd like us to be more agressive in deprecating/removing of unmaintained parts of GCC. It's not only target/host support but also things like unmaintained language extensions (or frontends) as well as optimization passes. If you want a compiler th

Re: Re: Improving code generation in the nvptx back end

2017-02-17 Thread Cesar Philippidis
On 02/17/2017 05:09 AM, Thomas Schwinge wrote: > On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: >> [...] for "normal" functions there is no reason to use the >> ".param" space for passing arguments in and out of functions. We can >> then get rid of the boilerplate code to move ".param %in_ar*" into

Fwd: [patch, contrib] Add support to install libcaf-mpi for multi-image coarray Fortran

2017-02-17 Thread Jerry DeLisle
I forgot to copy gcc list for this request for comments and approval to commit. Regards, Jerry Forwarded Message Subject: [patch, contrib] Add support to install libcaf-mpi for multi-image coarray Fortran Date: Wed, 15 Feb 2017 22:20:49 -0800 From: Jerry DeLisle To: GCC Patch