After deep look into safe cflags wiki, gcc tells me that mmx is disabled Intel 3820X CPU.
Some packages in portage still use the "mmx flag", should I disable it or force gcc to use mmx, or disable both?
Few experiments with lame had shown that enabling mmx is a bit slower but Im not sure if this applies to the other packages too._________________i7-4820X | ROG RIVE | 16GB 2400MHz CL10 | SSD 850 Pro | Essence STX | GTX970

If your flags line in /proc/cpuinfo does not include mmx then your CPU does not have native support for mmx,
You should disable the mmx USE flag, since specially crafted code sections that take advantage of mmx are less useful to you, if they run at all.

What to do in CFLAGS is more complex. If you use -march=native, gcc may just 'get it right'.
If not, you should disable mmx here too.
Its worth checking what -march=native does, there are lots of one liners for that around.

The above holds true for mmxext too_________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

So from my understanding, MMX is supported by CPU but not used during compiling and USE flags can be removed._________________i7-4820X | ROG RIVE | 16GB 2400MHz CL10 | SSD 850 Pro | Essence STX | GTX970

As you say, mmx is supported on yur I7 CPU, but gcc will not generate code that uses it.

However the USE=mmx flag has a different purpose.
Some packages have special optional sections that are written to use mmx. Usually multimedia packages.
USE=mmx builds these optional sections. They are often hand crafted assembler routines, so gcc won't know the mxx instructions are present.

Leave the mmx in your USE flags but you do not have mmxext so that should be removed, if its present._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Thanks for enlightening me again guys!
So theoretically I can use "-mmmx" per package just for testing but I have a feeling that mmx was disabled for a good reason._________________i7-4820X | ROG RIVE | 16GB 2400MHz CL10 | SSD 850 Pro | Essence STX | GTX970

To see what -march=native or -mtune=native enables for your specific CPU, run gcc -march=native -E -v - </dev/null 2>&1 | grep cc1. Simply using this whole output instead of -march=native is not recommended, but cache parameters can be used safely.

That's a pitty I re-emerge almost whole world after upgrade to gcc-4.6.3 and set -march=btver1, so I will set natvie right now and and use it for new and upgraded packages.

They are nominally identical. However, if you use distcc, you need to use the expanded form of CFLAGS, or you will get code built on helper systems for the helpers native CPU.
Thats something you probably won't like.

If you don't use distcc, you will be called a Ricer if you use the expanded form :)_________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

After all the confusion I decided to add "-v" to my CFLAGS.
Now I can see in "the expanded form" which flags are being used during compilation.
Interesting part is: mmx isnt listed but always enabled with SSE.
I think the info output of gcc should be fixed properly._________________i7-4820X | ROG RIVE | 16GB 2400MHz CL10 | SSD 850 Pro | Essence STX | GTX970

They are nominally identical. However, if you use distcc, you need to use the expanded form of CFLAGS, or you will get code built on helper systems for the helpers native CPU.
Thats something you probably won't like.

I will keep.... native

Quote:

If you don't use distcc, you will be called a Ricer if you use the expanded form