On Sat, Feb 23, 2013 at 12:58:14PM +0100, Dimitry Andric wrote: > 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.
Let me rephrase my question. What is the processor targeted by the cc on i386, when no -march flag is specified, for cc coming from clang, for both .c and .s files. Lets ignore known bugs, like long nops or cmovs.
pgp1LXfrJknLn.pgp
Description: PGP signature
