No, you definitely don't want that in -march, use "generic" and manually enable the instruction sets with -m* switches, or use -mno-3dnow (but beware broken ebuilds might filter this out). It should be safe for -mtune though._________________*.ebuild // /etc/service/*

No, you definitely don't want that in -march, use "generic" and manually enable the instruction sets with -m* switches, or use -mno-3dnow (but beware broken ebuilds might filter this out). It should be safe for -mtune though.

just a fyi, i have one of these and did basically that. I have also been experiencing odd program behavior, xfce4 refuses to draw window boarders or titles and can't see multiple workspaces. kde4.x has a high chance of kernel panic when using ati-drivers. using xf86-video-ati causes xorg to just sit there in a black screen and cursor when quitting or logging out or just loosing display completely forcing a ssh in to shut it down.

edit: using -mno-3dnow 'doesn't' work. most if not all ebuilds ignore it._________________"My father rode a camel. I drive a car. My son flies a jet-plane. His son will ride a camel."
Saudi saying
Too late to do anything about it, so just sit back and enjoy the fireworks.

From reading about the questions discussed on this thread, and having built many hundreds of highly tuned kernels for various amd cpus over the years, I'd definitely try updating to at least gcc-4.5.2 and probably gcc-4.6.1 with march=native if I was building a new system with the new amd cpus.

IMO, any gcc-4.4.x is probably completely outdated and doesn't have the needed support. Until more info is avaible, I'm even wondering if gcc-4.6.1 and later will actually have updated full support for these new cpus any time soon._________________Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r5, gcc-7.3.0 kernel-4.15.7-gentoo USE=experimental

From reading about the questions discussed on this thread, and having built many hundreds of highly tuned kernels for various amd cpus over the years, I'd definitely try updating to at least gcc-4.5.2 and probably gcc-4.6.1 with march=native if I was building a new system with the new amd cpus.

IMO, any gcc-4.4.x is probably completely outdated and doesn't have the needed support. Until more info is avaible, I'm even wondering if gcc-4.6.1 and later will actually have updated full support for these new cpus any time soon.

looking through the gcc site. the 4.6.1 branch will have bobcat support which is what these chips are._________________"My father rode a camel. I drive a car. My son flies a jet-plane. His son will ride a camel."
Saudi saying
Too late to do anything about it, so just sit back and enjoy the fireworks.

Zacate doesn't support 3dnow natively.
The correct CFLAGS are -march=btver1 (supported since gcc-4.6).

just posted that
anyway that branch of gcc looks like it lacks a keyword so that means it won't compile a decent amount of packages. I'll wait till it at least gets to unstable._________________"My father rode a camel. I drive a car. My son flies a jet-plane. His son will ride a camel."
Saudi saying
Too late to do anything about it, so just sit back and enjoy the fireworks.

FWIW, I've been running gcc-4.6.0 on both 32bit ~x86 and 64bit ~amd64 installations (both with full kde-4.6.2 through 4.6.5) without any more compiling problems than with gcc-4.5.2. Just went to gcc-4.6.1 from 4.6.0. I'm currently not using graphite or -flto stuff to avoid the associated problems still there, but if you just want to update to 4.6.1 to get the new cpu support it shouldn't be too much of a problem for experienced users.

I'd first rebuild the toolchain with the new gcc and flags, and then try and get cleanly through an emerge -e @system before trying an optional @world. If one is wary of gcc-4.6.x and still running any gcc-4.4.x version on Gentoo stable, I'd move to 4.5.2 first and then do an emerge -e @system, then 4.6.1. I read of some users having problems going from 4.4.x straight to 4.6.x. Might be some problems if you want to still run Gentoo stable and just move to ~Arch versions of gcc and thetoolchain packages- I wouldn't think it's a good idea. Better to go ~Arch on the entire system rather than mix stable and ~Arch packages. That can lead to a big confused mess._________________Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.26-r5, gcc-7.3.0 kernel-4.15.7-gentoo USE=experimental

it's not that i don't know how to do it. it's just that sometimes it's less hassle to go bleeding edge. still i want to rid myself of the kludge cflag's i have been using. the same idea as above. -march=generic and enableing all the cpu flags._________________"My father rode a camel. I drive a car. My son flies a jet-plane. His son will ride a camel."
Saudi saying
Too late to do anything about it, so just sit back and enjoy the fireworks.

i always thought -march=native would find all the usable flags for your CPU without you having to now what they are, i use -march=native and -mtune=native, never had any issues here, am considering upgrading to gcc-4.6.1, but on a laptop with about 600 packages it will take a while.

When I have updated GCC in the past i found the simplest option is to (this is only for major version jumps)

In the normal case, a new CPU gets more instruction, and not less like a Zacate.
And GCC just tries to get a close a possible (amdfam10/barcelona) as it is a amd cpu, expecting, that it supports at least the old instruction set._________________read the portage output!
If my answer is too concise, ask for an explanation.

In the normal case, a new CPU gets more instruction, and not less like a Zacate.
And GCC just tries to get a close a possible (amdfam10/barcelona) as it is a amd cpu, expecting, that it supports at least the old instruction set.

that's part of the problem. the rest is due to certain ebuilds here automatically assuming 3dnow support if a amd cpu is present. qt-gui did this for me for amdfam10 even if i used -mno-3dnow. using -march=generic or -march=btver1 gets around that.
as a former owner of a via cpu(great little things btw) i always ran into similar things due to the cpu having support for most, but not all the stuff that the class of cpu it is should have._________________"My father rode a camel. I drive a car. My son flies a jet-plane. His son will ride a camel."
Saudi saying
Too late to do anything about it, so just sit back and enjoy the fireworks.