svn commit: r247166 - head/contrib/llvm/tools/clang/lib/Driver

[Konstantin Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20130223/ff31f719/attachment.sig>