On 02/06/14 08:37, nick clifton wrote:
Hi Jeff,
According to our coding conventions, the ability to build with something
other than gcc is still desirable. You could argue that you're unlikely
to be bootstrapping on a mn103 with something other than GCC and if
you're building a cross, you coul
Hi Jeff,
According to our coding conventions, the ability to build with something
other than gcc is still desirable. You could argue that you're unlikely
to be bootstrapping on a mn103 with something other than GCC and if
you're building a cross, you could start by first building gcc native.
H
On 02/05/14 11:26, Joseph S. Myers wrote:
On Wed, 5 Feb 2014, Jeff Law wrote:
However, it's pretty easy to avoid the headaches and just provide a popcount
routine. I don't think this code is at all performance critical (once per
function being compiled), so a simple popcount should be suffici
On Wed, 5 Feb 2014, Jeff Law wrote:
> However, it's pretty easy to avoid the headaches and just provide a popcount
> routine. I don't think this code is at all performance critical (once per
> function being compiled), so a simple popcount should be sufficient. No need
> for lookup tables IMHO.
On 02/05/14 03:44, Nick Clifton wrote:
Hi Jeff, Hi Alex,
Sorry - another MN10300 patch - this time for the stack size reported
with -fstack-usage. Currently the value includes the stack frame, but
it does not take into account any registers that might have been
pushed onto the stack
Hi Jeff, Hi Alex,
Sorry - another MN10300 patch - this time for the stack size reported
with -fstack-usage. Currently the value includes the stack frame, but
it does not take into account any registers that might have been
pushed onto the stack.
The patch below fixes this problem, but
