On 17 August 2012 07:29, Julian Brown wrote:
> On Thu, 16 Aug 2012 19:56:52 +0100
> Ramana Radhakrishnan wrote:
>
>> On 07/24/12 13:27, Julian Brown wrote:
>> > On Fri, 20 Jul 2012 11:15:27 +0100
>> > Julian Brown wrote:
>> >
>> >> Anyway: this revised version of the patch removes the strange
>>
On Fri, Aug 17, 2012 at 9:13 AM, Ian Lance Taylor wrote:
>
> Looks fine to me.
>
> Ian
Will backport to arm/embedded-4_7-branch. No sure if appropriate for
4.7 branch since it is not a stability problem.
- Joey
On Thu, Aug 16, 2012 at 11:56 AM, Ramana Radhakrishnan wrote:
> On 07/24/12 13:27, Julian Brown wrote:
>>
>> On Fri, 20 Jul 2012 11:15:27 +0100
>> Julian Brown wrote:
>>
>>> Anyway: this revised version of the patch removes the strange libgcc
>>> Makefile-fragment changes, the equivalent of which
On Thu, 16 Aug 2012 19:56:52 +0100
Ramana Radhakrishnan wrote:
> On 07/24/12 13:27, Julian Brown wrote:
> > On Fri, 20 Jul 2012 11:15:27 +0100
> > Julian Brown wrote:
> >
> >> Anyway: this revised version of the patch removes the strange
> >> libgcc Makefile-fragment changes, the equivalent of w
On 07/24/12 13:27, Julian Brown wrote:
On Fri, 20 Jul 2012 11:15:27 +0100
Julian Brown wrote:
Anyway: this revised version of the patch removes the strange libgcc
Makefile-fragment changes, the equivalent of which have since been
incorporated into mainline GCC now anyway, so the patch is somew
Hello,
with this move to t-bpabi other targets like RTEMS profit also from this
change. This is very good since the unwinder pull-in for 64-bit divisions was
pretty bad for small Cortex-M3 systems with internal flash only.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 3
On Fri, 20 Jul 2012 11:15:27 +0100
Julian Brown wrote:
> Anyway: this revised version of the patch removes the strange libgcc
> Makefile-fragment changes, the equivalent of which have since been
> incorporated into mainline GCC now anyway, so the patch is somewhat
> more straightforward than it w
Hi,
This (old!) patch avoids uselessly pulling in the unwinder for 64-bit
division routines. I last posted it here:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01618.html
Other people have noticed the same issue, e.g.:
http://gcc.gnu.org/ml/gcc-help/2011-03/msg00187.html
Note that we take spe