[PATCH] MC: Don't emit min version directives when -fno-integrated-as is on

[Rafael Espíndola]

That is not as horrible as supporting cctools, but if we can avoid it
is would still be better. Can we just have a script that when run with

assemble-with-clang.py -as-option1 -as-option2 .... test.s

will run

clang -c -Wa,as-option1 -Wa,-as-option2 ....test.s?



On 22 January 2015 at 14:03, Filipe Cabecinhas <filcab at gmail.com> wrote:
> What would be the difference between shelling out to clang -cc1as or simply
> doing a no-op on -no-integrated-as?
>
> We could also start not allowing clang (on OS X) to emit directives by
> default if the latest Xcode-shipped clang doesn't handle them. That is:
> Maybe we should say what the “ground truth” for MachO/OSX is, and which
> tools outside of llvm we should try to be compatible with.
>
> This whole problem is due to clang emitting ".macosx_version_min" and other
> directives by default, and the latest Xcode-provided clang/as -q not
> handling them.
>
> Rafael: Yes, AFAICT that is the only case that is broken (and without the
> -c, but that's basically the same case).
>
>   Filipe
>
> On Thu, Jan 22, 2015 at 10:56 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> > If cctools as isn't supported, perhaps we should make -no-integrated-as
>> > shell out to `clang -cc1as` on Darwin. Users may be relying on
>> > -no-integrated-as implying cctools as quirks, though.
>>
>> It is probably a good idea. Since cctools' as can't handle clang
>> output, the only use case that might be broken by the change is "clang
>> -c -no-integrated-as foo.s", no?
>>
>> Cheers,
>> Rafael
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>