<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 24, 2014 at 7:29 PM, Saleem Abdulrasool <span dir="ltr"><<a href="mailto:compnerd@compnerd.org" target="_blank">compnerd@compnerd.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra">But I agree with others that "integrated assembler" isn't a feature which should be observable in source code.</div><div class="gmail_extra"><div><br><div class="gmail_quote">

On Sun, Feb 23, 2014 at 4:27 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">On a higher level, there's the quality issue. People should test for<br>

*behaviour* and *standards* not *tools* or *versions*. So, if my code<br>
only works on ARM UAL syntax, I should ifdef UAL, not ifdef<br>
MY_OWN_ASM_VERSION_7.34+. ARM is historically polluted with such<br>
flags, and they've now created the ACLE (ARM C Language Extensions),<br>
which moves from architecture version to feature support macros and<br>
extensions, which means it doesn't really matter what tool you're<br>
using, if that tool supports feature A, you can use it.</div></blockquote></div><br></div>Very much. If we have specific assembler features, we should expose them through __has_feature, but they should be source code visible features rather than "my code compiles faster with fewer temporary files" features.</div>


</div>
</blockquote></div></div></div><br>Unfortunately, its not that simple.  The IAS is not a perfect drop in replacement.  As a concrete example, on ARM, the IAS does not support pre-UAL syntax (which the Linux kernel uses in some cases).  This is more of a philosophical limitation rather than technical AFAIK.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Having the ability to detect what assembler is being targeted is useful.  I might be overlooking something, but I dont see why this would be any more dangerous than exposing the size of long or long long via the preprocessor.</div>
</blockquote></div><br>But you've just said: "the IAS does not support pre-UAL syntax". I think this precisely answers the question. Add "__has_feature(some_spelling_of_what_UAL_stands_for)" which says specifically that the UAL syntax is supported. And/or, __has_extension(...) for the name of the pre-UAL syntax which could hypothetically be supported as an extension, but isn't in Clang. And/or have the UAL-syntax specify a name of a preprocessor macro that all conforming compilers that support this syntax are required to define.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Again, here we have a concrete behavioral feature that we can and should support testing for. This isn't about whether the assembler is integrated or not, it is about whether the assembler supports a particular syntax on a particular platform.</div>
</div>