Re: -march=native and build failures

Hm..
  how about only enabling it on 32-bit builds and testing it out?
If Large Rock needs it, then removing it altoghether is not a viable option.

On Sun, Aug 25, 2013 at 10:04 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 08/25/2013 01:08 PM, Kinkie wrote:
>
>> I've traced down at least some build failures to our use of -march=native.
>> What apparently happens is that in some ocasions gcc emits some mmx
>> instructions which fail with a SIGILL.
>>
>> We have a few choices:
>> 1- leave the builds broken for now and try rework the code
>> 2- add an --enable-extra-compiler-optimizations configure switch to
>> optionally enable -march=native instead of unconditionally.
>> 3- work around this on the broken nodes and on those only by using
>> build trickery.
>>
>> Thoughts?
>> I'd favor option 2'; we can then leave a specifically-broken build job
>> so that when some change we make helps fix the build, we will know.
>
> IIRC, -march=native or similar was needed to build Squid on some 32-bit
> systems. Without it, the build (linking) failed due to the lack of
> 64-bit atomic operations if compiler assumes it needs to preserve
> compatibility with much older 32 bit systems.
>
> Current trunk does not use such operations, but the pending Large Rock
> and Collapsed Forward code do (because swap_file_sz that they need to
> keep in sync across Squid kids is 64 bits).
>
> I hope this info helps you make the right decision but I do not know
> enough about the related compiler options to pick the right choice among
> the three offered.
>
>
> Thank you,
>
> Alex.
>

-- 
    /kinkie