port other
architectures, or otherwise. We can backport those changes, or we can
just wait for our next merge from upstream, and get them then.
This would give Linaro the clearly focused mission of providing
excellent tools for ARMv7-A.
My two cents,
--
Mark M
ormance improvement on ARM resulted in a 2% decrease on MIPS
or 3% on x86? What commitment, if any, are we making to a distribution
that cares about all of ARM, MIPS, and x86?
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
__
on between
"make the best possible ARM Linux system" and "don't break other
architectures".
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
___
linaro-toolchain mailing list
linaro-toolchai
ructions are considered valid, I'll have to
> extend the SPU move expander to handle them. Thoughts?
I haven't participated in the upstream discussion -- I'm way behind on
that list :-( :-( -- but I think such sets should be considered valid.
Thank you,
--
Mark Mi
7;d still like to see this handled a lot more
generally, but I'm not saying that we should gate incremental progress
on a grand plan. We could do both. :-)
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
___
linaro-t
users. For example, a library
developer might very well like to ship some Python code that told the
compiler that calling f(g(x)) is equivalent to calling h(x), or that if
n < 3, you should translate f(n) into g(1); ...; g(n).
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x71
answers are
going to change depending on the application and on the core.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
time for you, and let me know when it is.
Thank you,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
if memcpy is the key example, we could get 80% of the
benefit of your idea simply by a test inside memcpy as to the length of
the data to be copied?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
ical path, I'm
probably happy to do it slowly if that's more efficient than waking up
the NEON unit. But, which of these cases I'm in isn't always locally
known at the point I'm doing the computation; the computation may be
buried in a small library routine.
ings require some significant infrastructure work. They
aren't ARM-specific back-end changes. But, I suspect that they're
important in terms of allowing GCC to take full advantage of ARM CPUs.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
_
On 11/16/2010 7:35 PM, Michael Hope wrote:
> Andrew, could you look into (2) please? We need to have an
> authoritative answer from the GCC overseers or to assume 'no'.
GCC policy is simple: you can host any branch you want in GCC SVN, so
long as all the code is assigned to th
On 11/13/2010 8:03 AM, Christian Robottom Reis wrote:
> I noticed that there's a QEMU users forum at:
>
> http://adt.cs.upb.de/quf/
Thanks for pointing this out -- I've forwarded this internally beyond
just our Linaro team to see if anyone is interested in pr
best way to do that. It's also the
simplest for an upstream GCC developer coming to work on Linaro.
So, fundamentally, we have to choose whether we want to work as much as
possible upstream (using an SVN branch), or whether we want uniformity
across Linaro projects (using Launchpad).
--
Mar
ou might consider doing it this way
instead" or "that looks pretty good!".
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
d). That is one of the
reasons that building the kernel and U-Boot tends to require lots of
complex command-line options; you have to tell the compiler that it
can't assume it's building a Linux application.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.c
tter luck if you do
not restrict it to ARM; i.e., if you are willing to also accept code for
other CPUs, and even share algorithmic infrastructure that's common
across various CPUs. You also want to design for some of the
differences between a statically linked libc and a dynamic libc.
--
M
On 9/30/2010 4:31 AM, Loïc Minier wrote:
> On Wed, Sep 29, 2010, Mark Mitchell wrote:
>> It is theoretically possible that there's insufficient information for
>> strip to know what it's looking at, but I'd be very surprised; there
>> should be an ELF header f
the right kind of
strip and punt. It shouldn't blindly damage your object file when it
has enough information to know that it doesn't know what it's doing.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
__
On 9/22/2010 8:34 AM, Loïc Minier wrote:
> Which component is to blame here? Are we looking at a binutils or a
> gcc bug for not being able to set or read enough data that the
> architecture mismatch isn't detected? What could we do about it?
This is definitely a binutils
ages
for ARM -- for all of bare-metal, uClinux, and Linux -- with both
Windows and Linux hosts. They're being downloaded thousands of times
per month. Why reinvent the wheel?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
___
this case, implementation-defined-ness,
IIRC) helps the compiler; it's free to do as it wants. So, this is no
excuse for the compiler generating slow code. (In particular, the
compiler needn't generate a test to see whether the argument is greater
than INT_MAX.)
--
Mark Mitchell
CodeSo
cies on other shared libraries,
that could potentially break binary compatibility across Linux
distributions.
If someone wants to build libgcc with -fstack-protector, that would
require an assessment of all code in libgcc to make sure that is safe.
libgcc is emphatically not "application" c
always have a Linaro-specific
hack to accept the option and ignore it; certainly, CodeSourcery will
support this command-line option in our tools going forward "forever".
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
__
24 matches
Mail list logo
