Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-16 Thread Olivier Hainque
On May 16, 2012, at 03:10 , David Edelsohn wrote: Okay. revision 187581. Thanks!

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-16 Thread Sebastian Huber
Hello, since you touch the SPE area would you mind looking at this PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856 -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail :

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-15 Thread Olivier Hainque
Hello David, Back on this one after Alan's correction and extra testing of the patch on my side. On May 7, 2012, at 18:59 , David Edelsohn wrote: http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01667.html Yes, exactly. If we can work through the fallout, this is exactly the type of cleanup

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-15 Thread David Edelsohn
On Tue, May 15, 2012 at 9:47 AM, Olivier Hainque hain...@adacore.com wrote:        config/rs6000:        * rs6000-opts.h (enum processor_type): Add PROCESSOR_PPC8548.        * rs6000-cpus.def: Reference it for cpu=8548.        * rs6000.md (cpu attribute definition): Add ppc8548.        *

remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-07 Thread Olivier Hainque
Hello, This is a followup on a discussion we had a while ago, starting with http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01543.html The original issue was the vxworks port unduly clobbering explicit SPE related options on powerpc, which it still does. The proposed patch at the time was to

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-07 Thread Olivier Hainque
On May 7, 2012, at 15:57 , Olivier Hainque wrote: My first attempt at building there failed, with --target=powerpc-eabispe --with-cpu=8548 --enable-languages=c --disable-libada (internal compiler error on unwind-dw2.c) This failure reproduces with an unpatched tree as well, so

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-07 Thread Joseph S. Myers
On Mon, 7 May 2012, Olivier Hainque wrote: Joseph and David suggested to address this in a more general fashion, along lines proposed in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01667.html The attached patch is a first shot in this direction. Only lightly tested at this point,

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-07 Thread David Edelsohn
On Mon, May 7, 2012 at 12:10 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 7 May 2012, Olivier Hainque wrote: Joseph and David suggested to address this in a more general fashion, along lines proposed in   http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01667.html The attached

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-07 Thread Olivier Hainque
On May 7, 2012, at 18:59 , David Edelsohn wrote: Yes, exactly. If we can work through the fallout, this is exactly the type of cleanup I envisioned. Great :) Thanks, David Do you want a PR for the fallout ? It is not related to this patch at all. I can look into it further and make

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-07 Thread David Edelsohn
On Mon, May 7, 2012 at 1:24 PM, Olivier Hainque hain...@adacore.com wrote: On May 7, 2012, at 18:59 , David Edelsohn wrote: Yes, exactly.  If we can work through the fallout, this is exactly the type of cleanup I envisioned.  Great :) Thanks, David  Do you want a PR for the fallout ? It

Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports

2012-05-07 Thread Olivier Hainque
On May 7, 2012, at 21:27 , Olivier Hainque wrote: Of course. That was actually my point in offering to open a PR, so that Alan (who did the nice recent reorg) can take it from there. He will certainly be more efficient than me in resolving this :) PR 53271