Comment 89 for bug 587186

Alright. Posted some test cases on the upstream bug and already got a response.

Invoking "as -mtune=i686" is effectively equivalent to invoking "as -march=i686 -mtune=i686" (a small behavioural difference when compared to gcc). So it will look to produce optimized code for i686, with the whole of the i686 instruction set at its disposition.

So there is no glibc or assembler bug here. We're asking glibc to build for i686, and glibc is doing a better job than most packages of communicating the target architecture through the whole build chain. (by default the optimization flags do not reach the assembler, but glibc makes this happen)

If we want to fix F13, we have a number of options available:
 - build glibc for target arch i586
 - hack glibc build system to use -Wa,-mtune=i586 (i.e. we ask all parts of the build chain to optimize for i686, except for the assembler which we ask to optimize for i586)
 - hack glibc build system to use -Wa,-mtune=i686 -Wa,-march=i586 (i.e. ask the assembler to optimize for i686, but never going outside of the instruction set supported by i586 processes)
 - hack glibc build system so that we don't ask assembler to do any optimizations (like the rest of the world)

In the FESCO meeting, we decided that we should gain a full understanding of this issue before coming up with a decision (do we hack glibc in F13 to fix this? Do we change target arch for F14? or both? or...?). I think with my analysis we have now gained an understanding.