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 <[email protected]> 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
