on 11/05/2012 11:09 Konstantin Belousov said the following:
> On Fri, May 11, 2012 at 09:37:10AM +0300, Andriy Gapon wrote:
>> on 09/05/2012 15:09 Alfred Bartsch said the following:
>>> Am 09.05.2012 12:42, schrieb Andriy Gapon:
>>>> on 09/05/2012 12:29 Alfred Bartsch said the following:
>>>>> This behavior is restricted to 32-bit servers (i386), all 64-bit
>>>>> servers (amd64) work without any problem, as expected.
>>>>> After some analyzing, it seems to me that the actual size of
>>>>> gptboot does matter (16723 bytes, >16kB). In amd64 environment
>>>>> (same source version) the actual size of /boot/gptboot is only
>>>>> 15443 bytes.
>>>> Weird. Both amd64 and i386 builds should produce the same binaries
>>>> as the boot code is built with -m32 -march=i386 on amd64. But I can
>>>> reproduce this, so it seems that the compilation is indeed done
>>>> Heh, it seems that it is -march=i386 flag that makes all the
>>>> difference. Maybe we should use this flag even when doing native i386
>>> after adding "-march=i386" to CFLAGS in Makefile everything looks ok
>>> (filesize: 15443, as you predicted), so I would opt for using this flag
>>> in the future.
>> Here is a small investigation into the -march flag. Not sure if it is of
>> any practical significance, I just was curious.
>> First, seems that neither of i386/i486/i586/i686 values for this flag
>> nor absence of it implies features like MMX, SSE, and so on. (Saying
>> this because of some assumptions about i686)
>> For the base GCC specifying -march with the above values is equivalent
>> to specifying -mtune with the same values, when mtune is not explicitly
>> set. Using "i686" or omitting the flag is equivalent to -mtune=generic.
>> Note that this happens despite a FreeBSD-specific change to (base) GCC
>> that makes i486 a default arch. Derivation of the tune value from the
>> arch value, if any, or defaulting it otherwise is done earlier than
>> defaulting of the arch value. Specifically I am talking about the block
>> that deals with ix86_tune_string that precedes the block for
>> So it seems that at the moment our sys/boot code is effectively compiled
>> with -mtune=generic for i386 target (amd64 target has an explicit
>> -march=i386 - I wonder why not i486).
>> I think that in terms of instructions repertoire the difference is only
>> in availability of cmpxchg, cmpxchg8b, and xadd instructions (ignoring
>> the "system" instructions that should not be generated by a compiler from
>> C code). And I guess that the sys/boot code is simple enough to not
>> require these instructions? Otherwise, mtune seems to affect layout of
>> the generated code and preference for some instructions over others.
>> Again, not sure what conclusions can be made...
> -march=i686 also turns on use of cmov*.
So, this is the important thing that I missed.
Then, it seems our default gcc behavior is -march=i486 -mtune=generic after all.