On 18/10/11 15:42, Andrew Stubbs wrote:
Which still jumps to not_found without closing f.
Hmmm, I know I fixed that, I know I did!
But I appear to have lost the change somewhere when I updated my checkout?
I'll fix it now.
Fixed and committed as attached.
Apologies for the cock-up. :(
On 17/10/11 14:24, Richard Earnshaw wrote:
There's a presumption in host_detect_local_cpu() that CPU implementer
will appear before CPU part in the output of /proc/cpuinfo. That's
probably a pretty safe assumption (and it appears that it will handle
that case relatively safely -- ie not
On 18/10/11 15:23, Andrew Stubbs wrote:
+ /* Detect arch/cpu. */
+ if (strncmp (buf, CPU part, sizeof (CPU part) - 1) == 0)
+ {
+ int i;
+
+ if (cpu_table == NULL)
+ goto not_found;
+
Which still jumps to not_found without closing f.
R.
On 18/10/11 15:34, Richard Earnshaw wrote:
On 18/10/11 15:23, Andrew Stubbs wrote:
+ /* Detect arch/cpu. */
+ if (strncmp (buf, CPU part, sizeof (CPU part) - 1) == 0)
+ {
+ int i;
+
+ if (cpu_table == NULL)
+ goto not_found;
+
Which still jumps to
On 20/09/11 11:51, Andrew Stubbs wrote:
On 09/09/11 12:55, Richard Earnshaw wrote:
The part number field is meaningless outside of the context of a a
specific vendor -- only taken as a pair can they refer to a specific
part. So why is the vendor field hard-coded rather than factored into
the
Ping.
On 20/09/11 11:51, Andrew Stubbs wrote:
On 09/09/11 12:55, Richard Earnshaw wrote:
The part number field is meaningless outside of the context of a a
specific vendor -- only taken as a pair can they refer to a specific
part. So why is the vendor field hard-coded rather than factored into
On 09/09/11 12:55, Richard Earnshaw wrote:
The part number field is meaningless outside of the context of a a
specific vendor -- only taken as a pair can they refer to a specific
part. So why is the vendor field hard-coded rather than factored into
the table of parts.
Maybe it would be better
On 06/09/11 14:35, Andrew Stubbs wrote:
This update adds many more magic numbers for various ARM CPUs, and
also ensures that the implementer is ARM (as opposed to Marvell, etc.).
The list is far from comprehensive, but it should cover many (but by no
means all) of the cores in current use
This update adds many more magic numbers for various ARM CPUs, and
also ensures that the implementer is ARM (as opposed to Marvell, etc.).
The list is far from comprehensive, but it should cover many (but by no
means all) of the cores in current use and it would not be hard to add
support for
On 29/08/11 04:29, Michael Hope wrote:
On Sat, Aug 27, 2011 at 3:19 AM, Andrew Stubbsa...@codesourcery.com wrote:
Hi all,
This patch adds support for -mcpu=native, -mtune=native, and -march=native
for ARM Linux hosts.
So far, it only recognises Cortex-A8 and Cortex-A9, so I really need to
On Tue, Aug 30, 2011 at 10:47 PM, Stubbs, Andrew
andrew_stu...@mentor.com wrote:
On 29/08/11 04:29, Michael Hope wrote:
On Sat, Aug 27, 2011 at 3:19 AM, Andrew Stubbsa...@codesourcery.com wrote:
Hi all,
This patch adds support for -mcpu=native, -mtune=native, and -march=native
for ARM Linux
On Sat, Aug 27, 2011 at 3:19 AM, Andrew Stubbs a...@codesourcery.com wrote:
Hi all,
This patch adds support for -mcpu=native, -mtune=native, and -march=native
for ARM Linux hosts.
So far, it only recognises Cortex-A8 and Cortex-A9, so I really need to find
out what the magic part numbers
On 26/08/11 17:16, Joseph S. Myers wrote:
arm-tables.opt is a generated file. You need to modify the source files
and regenerate it, not modify the generated file.
Fixed; the native option value is now defined in arm.opt. Thanks for
spotting this.
OK?
Andrew
2011-08-27 Andrew Stubbs
On Fri, 26 Aug 2011, Andrew Stubbs wrote:
Hi all,
This patch adds support for -mcpu=native, -mtune=native, and -march=native for
ARM Linux hosts.
So far, it only recognises Cortex-A8 and Cortex-A9, so I really need to find
out what the magic part numbers are for other cpus before this
14 matches
Mail list logo
