[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]))

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: > >

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]))

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

New GCC Mirror

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]))

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

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]))

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]))

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

Converting to LRA (calling all maintainers)

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: Converting to LRA (calling all maintainers)

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,

Re: Converting to LRA (calling all maintainers)

> 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)

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)

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)

> 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