I get a new laptop with a Core i7 2630QM (2nd Gen.). I upgraded to and rebuilt my system against GCC 4.6.1 with march=native; however, "emerge --info" does not show all the instruction sets (notably ssse4.2 and avx seem to be missing). I thought march=native worked with this version of GCC and the second generation Cores.

First of all, is it using all of the instruction sets supported by my processor? Why are all of them not showing in emerge --info with march=native (or march=corei7=avx)? Should I add the supported instruction sets to my use flags? If so would anyone care to share what they use with their 2nd Gens.

Where do you think that information should be shown? If you're talking about USE flags then no, those have nothing to do with gcc flags, and adding non-existant use flags won't do anything. -march=native is a gcc option, so you'll have to ask gcc about what it expands to.

These -m options are defined for the i386 and x86-64 family of computers:

-mtune=cpu-type
Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are:

generic
Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option.

As new processors are deployed in the marketplace, the behavior of this option will change. Therefore, if you upgrade to a newer version of GCC, the code generated option will change to reflect the processors that were most common when that version of GCC was released.

There is no -march=generic option because -march indicates the instruction set the compiler can use, and there is no generic instruction set applicable to all processors. In contrast, -mtune indicates the processor (or, in this case, collection of processors) for which the code is optimized.

native
This selects the CPU to tune for at compilation time by determining the processor type of the compiling machine. Using -mtune=native will produce code optimized for the local machine under the constraints of the selected instruction set. Using -march=native will enable all instruction subsets supported by the local machine (hence the result might not run on different machines).

i386
Original Intel's i386 CPU.

i486
Intel's i486 CPU. (No scheduling is implemented for this chip.)

i586, pentium
Intel Pentium CPU with no MMX support.

pentium-mmx
Intel PentiumMMX CPU based on Pentium core with MMX instruction set support.

pentiumpro
Intel PentiumPro CPU.

i686
Same as "generic", but when used as "march" option, PentiumPro instruction set will be used, so the code will run on all i686 family chips.

pentium2
Intel Pentium2 CPU based on PentiumPro core with MMX instruction set support
.
pentium3, pentium3m
Intel Pentium3 CPU based on PentiumPro core with MMX and SSE instruction set support.

pentium-m
Low power version of Intel Pentium3 CPU with MMX, SSE and SSE2 instruction set support. Used by Centrino notebooks.

winchip-c6
IDT Winchip C6 CPU, dealt in same way as i486 with additional MMX instruction set support.

winchip2
IDT Winchip2 CPU, dealt in same way as i486 with additional MMX and 3DNow! instruction set support.

c3
Via C3 CPU with MMX and 3DNow! instruction set support. (No scheduling is implemented for this chip.)

c3-2
Via C3-2 CPU with MMX and SSE instruction set support. (No scheduling is implemented for this chip.)

geode
Embedded AMD CPU with MMX and 3DNow! instruction set support.

While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used.

-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type.

As I understand it, emerge --info only reports the default profile and whatever mods you have made in /etc/make.conf.

Also, these readouts don't seem to be too reliable, as they aren't reporting the same thing. On my current system, one reports amdfam10-, the other fam16.

cat /proc/cpuinfo seems to be more explicit (pni is aka sse3).
I used to put sse sse2 sse3 and others in make.conf that according to man:gcc corresponded top my current cpu, but since I started using march=native I haven't. However, now I'm thinking maybe "native" isn't actually passing all the flags the cpu is capable of utilizing.

Come to think of it, when I manually added flags in make.conf the flags would show up in the gcc output while compiling, but with "native" I don't really recall seeing the "full set" as cpuinfo reports. Of course I've always realized gentoo USE flags and gcc cflags are two different things, but there doesn't seem to be hard and fast rules defining what actually shows up in the gcc output, as regard to what's in make.conf and it's relationship to what the cpu and/or gcc is actually using or capable of. Sure would like some more reliable info on all this.

It was in the USE flag list. The KDE desktop profile list mmx, sse and sse2 in USE flags, but I thought these were processor instruction sets, not use flags. If these are here, why not the rest?

There are some hardware related use flags for packages that can make use of hand-crafted assembler code for example (e.g. USE=sse could pull in a patch containing assembler code). But those have absolutely nothing to do with C*FLAGS or any other compiler settings. And if there are no use cases for e.g. a sse4.1 flag then such a flag doesn't exist.

Pretty confusing, as all the sse options are disabled, even though amdfam10 is enabled. Could this be related to the fact I have to select k8 in my kernel config, as there is no other option to build for k10's? (Had read somewhere a while back that the k10 kernel option hadn't been implemented due to some problems, and was apparently never addressed by the kernel devs).

Should the sse options my athlon II x4 640 propus core is capable of be placed in make.conf, as only using march=native doesn't seem to be doing the job?

Which is appropriate, the -msseX version, or the USE flags sseX, or both? Or maybe switch from -march=native to -march=amdfam10?