Date: Sat, 23 Feb 2013 12:58:14 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r247166 - head/contrib/llvm/tools/clang/lib/Driver Message-ID: <5128AED6.2020906@FreeBSD.org> In-Reply-To: <20130222235332.GB2454@kib.kiev.ua> References: <201302222240.r1MMeAsu042087@svn.freebsd.org> <20130222235332.GB2454@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-02-23 00:53, Konstantin Belousov wrote: > On Fri, Feb 22, 2013 at 10:40:10PM +0000, Dimitry Andric wrote: ... >> This should fix the long nops that still occurred in crt*.o, and >> possibly other object files, if the system was compiled for a CPU that >> does not support those, such as Geode. >> >> Note that gcc on i386 also does not pass through any -march, -mcpu or >> -mtune setting to gas, but this has not caused any trouble yet, because >> gas defaults to i386. > > Are you saying that assembler (in the 'cc' invocation) miscompiles > the .s files on i386 ? Why does it use instructions by default which > are not supported on the i486 architecture, implicitely ? The x86 backend always used to emit long nops, until upstream r164132, where this was fixed for the .c -> .o phase (-cc1 mode). This fix is also in 3.2 release, and in our tree. The .s -> .o phase (-cc1as mode) did not get passed the target CPU though, so it still defaulted to long nops. This was simply the default chosen by upstream. After upstream r175919, that problem should also be fixed. As far as I can see, the only remaining issue now is the emission of cmov instructions on CPUs that do not support them, and a fix for that is being worked on now. -Dimitry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5128AED6.2020906>