Via Nano CPU -march=native options

[Joanna PieroÅek <akai at gmusicbrowser dot org>]

Setting -march=native and -mtune=native flags on a Via Nano U2250
produces Core2 optimized code that works very poorly on this CPU
(programs fail or don't compile). I wonder if it was a conscious
decision of GCC developers to set -march=native options for Via Nano to
these values? This issue has been present since I've bought this CPU in
June and it persists in GCC 4.3.4 and 4.4.2.

gcc -fverbose-asm -mtune=native -march=native -S test.c returns:

# GNU C (Gentoo 4.4.2 p1.0) version 4.4.2 (x86_64-pc-linux-gnu)
#    compiled by GNU C version 4.4.2, GMP version 4.3.1, MPFR version
2.4.1-p5.
# GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
# options passed:  test2.c -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
# -mtune=core2 -fverbose-asm
# options enabled:  -falign-loops -fargument-alias
# -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg -fcommon
# -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-types
# -ffunction-cse -fgcse-lm -fident -finline-functions-called-once
# -fira-share-save-slots -fira-share-spill-slots -fivopts
# -fkeep-static-consts -fleading-underscore -fmath-errno
# -fmerge-debug-strings -fmove-loop-invariants -fpeephole
# -freg-struct-return -fsched-interblock -fsched-spec
# -fsched-stalled-insns-dep -fsigned-zeros -fsplit-ivs-in-unroller
# -ftrapping-math -ftree-cselim -ftree-loop-im -ftree-loop-ivcanon
# -ftree-loop-optimize -ftree-parallelize-loops= -ftree-reassoc
# -ftree-scev-cprop -ftree-switch-conversion -ftree-vect-loop-version
# -funit-at-a-time -funwind-tables -fvect-cost-model -fverbose-asm
# -fzero-initialized-in-bss -m128bit-long-double -m64 -m80387
# -maccumulate-outgoing-args -malign-stringops -mcx16 -mfancy-math-387
# -mfp-ret-in-387 -mfused-madd -mglibc -mieee-fp -mmmx -mno-sse4
# -mpush-args -mred-zone -msahf -msse -msse2 -msse3 -mssse3
# -mtls-direct-seg-refs

On the other hand, I've been using a x86_64 Linux system compiled with:
-mtune=generic -mmmx -msse -msse2 -msse3 -mcx16 -msahf -O2 -pipe on this
CPUand it's been working with no problems for a few months.

I'd like to know if this issue is a bug (I can't find a corresponding
bug report) and what steps should I take to report it if that's necessary.

cat /proc/cpuinfo looks like this:

processor    : 0
vendor_id    : CentaurHauls
cpu family    : 6
model        : 15
model name    :               VIA Nano processor U2250@1300+MHz
stepping    : 2
cpu MHz        : 1596.000
fpu        : yes
fpu_exception    : yes
cpuid level    : 10
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat clflush acpi mmx fxsr sse sse2 ss tm pbe syscall fxsr_opt
rdtscp lm constant_tsc up rep_good pni monitor est tm2 ssse3 cx16 xtpr
lahf_lm
bogomips    : 3195.21
clflush size    : 64
cache_alignment    : 128
address sizes    : 36 bits physical, 48 bits virtual
power management: