Bug detecting AMD K6-2+ with -march=native ?

[Stroller <stroller at stellar dot eclipse dot co dot uk>]

Hi there,

I have a Sun / Cobalt Qube 3 with an AMD K6-2+ CPU, and gcc seems to be misdetecting it as an Athlon when using -march=native

# gcc -v -Q --help=target -march=native 2>&1 | grep march
/usr/libexec/gcc/i586-pc-linux-gnu/4.5.2/cc1 -v help-dummy -D_FORTIFY_SOURCE=2 -march=athlon --param l1-cache-size=32 --param l1-cache-line-size=32 --param l2-cache-size=128 -mtune=athlon -dumpbase help-dummy -auxbase help-dummy -version -fhelp=target -o /tmp/ccQrke9q.s
 -march=                               athlon
# 

I've tried a couple of different versions of gcc - 4.4.4 and 4.5.2 - but they both show the same.
Someone on the linux-cobalt mailing list can also reproduce. 

When I compile nano using `-march=i586`, `-march=k6-2` or `-march=k6-3` it works fine.
If I compile it with `-march=native` then nano crashes on startup saying "illegal instruction".

/proc/cpuinfo seems to show the CPU correctly:

# cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 13
model name      : AMD-K6(tm)-III Processor
stepping        : 4
cpu MHz         : 448.140
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnowext 3dnow k6_mtrr
bogomips        : 896.28
clflush size    : 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management: ts fid vid

#

AIUI the K6-2+ is architecturally the same as a K6-3, so I assume this is fine. The family & model above match what wikipedia says it should be for a K6-2+ (although they're also the same for a K6-3+).

The Cobalt Qube 3 is slightly unusual in that it doesn't have a regular BIOS, but OTOH it doesn't seem much different from a regular PC - it uses standard EIDE hard-drives (SCSI optional) and has a PCI slot. A patch [1] is applied to the 2.6.36.2 vanilla kernel but I think this is just to support ACPI, the LCD panel, the front LED and measuring the fan speed.
I don't think these things should affect gcc's detection of the CPU, but I thought I should mention it to be on the safe side.

I'm a complete n00b here, and don't really know how to debug further. My C isn't really up to digging around in gcc's source - not blindly, at least - and seeing if this is the Qube's fault or what. If anyone could give me *any* pointers at all, I'd be grateful. I don't know whether I should be simply reporting this as a bug, or asking for an explanation of how gcc determines CPU type so I can compare with what I'm seeing.

Thanks in advance for any suggestions,

Stroller.



[1] http://downloads.raqcop.com/cobalt_ipcop/extras/cobalt-kernel-patches/2.6-kernel/linux-cobalt-2.6.36.patch
http://downloads.raqcop.com/cobalt_ipcop/extras/Cobalt-Server-Kernels/configs/2.6.36.2-3-cobalt.config.txt