Dear Stefan Roese,
In message <201012140909.27701...@denx.de> you wrote:
>
> I can do this if Wolfgang has no objections. So I'll wait a short while and
> pull it onto next then upstream pushing.
I have no objections:
Acked-by: Wolfgang Denk
Best regards,
Wolfgang Denk
--
DENX Software Eng
On Tuesday 14 December 2010 00:06:11 Kim Phillips wrote:
> On Fri, 10 Dec 2010 17:00:51 -0600
>
> Scott Wood wrote:
> > Recent GCC (4.4+) performs out-of-line epilogues in some cases, when
> > optimizing for size. It causes a link error for _restgpr_30_x (and
> > similar) if libgcc is not linked
On Tuesday 14 December 2010 00:49:20 Scott Wood wrote:
> > Q2: What happens with older compilers, that don't need this? Is this
> > change a No-Op for these?
>
> With compilers that don't do this, the symbol references won't be
> generated, and no part of libgcc.a will be pulled in.
I tested
On Tue, 14 Dec 2010 00:16:28 +0100
Wolfgang Denk wrote:
> Just two questions:
>
> Q1: Are we sure that the observed behaviour is intentional, and not
> eventually unintended behaviour (well, a bug) in the new versions
> of GCC? In general newer releases are supposed to provide better
>
Dear Scott Wood,
In message <20101210230051.ga30...@udp111988uds.am.freescale.net> you wrote:
> Recent GCC (4.4+) performs out-of-line epilogues in some cases, when
> optimizing for size. It causes a link error for _restgpr_30_x (and similar)
> if libgcc is not linked.
>
> It actually increases
On Fri, 10 Dec 2010 17:00:51 -0600
Scott Wood wrote:
> Recent GCC (4.4+) performs out-of-line epilogues in some cases, when
> optimizing for size. It causes a link error for _restgpr_30_x (and similar)
> if libgcc is not linked.
>
> It actually increases size with very small binaries, due to th
6 matches
Mail list logo
