Re: Converting to LRA (calling all maintainers)

2016-09-16 Thread Eric Botcazou
> p.s. Are there plans for converting the SPARC port? There are more than plans - actual patches by DaveM that were installed at some point and then reverted quickly because of unexpected fallout. -- Eric Botcazou

Re: Converting to LRA (calling all maintainers)

2016-09-16 Thread Segher Boessenkool
On Fri, Sep 16, 2016 at 11:22:04PM +0200, Eric Botcazou wrote: > > Since a few days TARGET_LRA_P defaults to returning "true". I changed > > all in-tree ports to still behave the same as before, which for most > > ports means they use old reload always. All the primary platforms (see > > the rele

Re: Converting to LRA (calling all maintainers)

2016-09-16 Thread Segher Boessenkool
On Fri, Sep 16, 2016 at 02:53:16PM -0600, Jeff Law wrote: > Under traps for the unwary -- LRA requires the target to not use the old > cc0 condition code handling... I added this now, thanks Jeff. > ANd yes, I see this as a way to deprecating those cc0 targets like the > m68k :-) Would be a sh

Re: Converting to LRA (calling all maintainers)

2016-09-16 Thread Eric Botcazou
> Since a few days TARGET_LRA_P defaults to returning "true". I changed > all in-tree ports to still behave the same as before, which for most > ports means they use old reload always. All the primary platforms (see > the release criteria, ) now > default

Re: Converting to LRA (calling all maintainers)

2016-09-16 Thread Jeff Law
On 09/16/2016 02:37 PM, Segher Boessenkool wrote: Hi! Since a few days TARGET_LRA_P defaults to returning "true". I changed all in-tree ports to still behave the same as before, which for most ports means they use old reload always. All the primary platforms (see the release criteria,

Converting to LRA (calling all maintainers)

2016-09-16 Thread Segher Boessenkool
Hi! Since a few days TARGET_LRA_P defaults to returning "true". I changed all in-tree ports to still behave the same as before, which for most ports means they use old reload always. All the primary platforms (see the release criteria, ) now default to LR

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

2016-09-16 Thread Joseph Myers
On Fri, 16 Sep 2016, Richard Biener wrote: > Humm ... do we anywhere compare to those global trees by pointer equivalence? > If so then it breaks LTO support for those types. The C front end compares main variants to those types for handling usual arithmetic conversions (and more generally for t

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

2016-09-16 Thread Joseph Myers
On Fri, 16 Sep 2016, Thomas Schwinge wrote: > That's what I was afraid of: for example, I can't tell if it holds for > all GCC configurations (back ends), that complex types' component types > will always match one of the already existing global trees? (I can Well, a component type could certain

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

2016-09-16 Thread Thomas Schwinge
Hi! On Fri, 16 Sep 2016 10:59:16 +0200, Richard Biener wrote: > On Fri, Sep 16, 2016 at 9:05 AM, Thomas Schwinge > wrote: > > On Thu, 08 Sep 2016 13:43:30 +0200, I wrote: > >> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener > >> wrote: > >> > On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge

New GCC Mirror

2016-09-16 Thread mirrors
Hi guys, We're supporters of your project and have created a mirror. Location: Tokyo, Japan Mirror: http://gcc.letterboxdelivery.org (http) | rsync://gcc.letterboxdelivery.org/gcc (rsync) Mirror contact email: mirr...@letterboxdelivery.org Glad to help out! Kind regards, Mitch.

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

2016-09-16 Thread Richard Biener
On Fri, Sep 16, 2016 at 9:05 AM, Thomas Schwinge wrote: > Hi! > > (CCing Bernd and Jakub -- for your information, or: "amusement" -- as > you've discussed offloading preload_common_nodes issues before...) > > Got to look into this some more, yesterday: > > On Thu, 08 Sep 2016 13:43:30 +0200, I wro

[PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

2016-09-16 Thread Thomas Schwinge
Hi! (CCing Bernd and Jakub -- for your information, or: "amusement" -- as you've discussed offloading preload_common_nodes issues before...) Got to look into this some more, yesterday: On Thu, 08 Sep 2016 13:43:30 +0200, I wrote: > On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener > wrote: > >