<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 21, 2015 at 11:56 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, May 21, 2015 at 2:11 PM, David Majnemer<br>
<<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, May 20, 2015 at 2:54 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> While refactoring some attribute parsing code, I noticed that we do<br>
>> not guard __declspec as being a Microsoft-specific extension that we<br>
>> support. This is consistent with the behavior we have for<br>
>> __attribute__. In both cases, the keyword is available everywhere, and<br>
>> specific attributes determine their target requirements. However, I<br>
>> wonder if that's the behavior we want.<br>
>><br>
>> With __attribute__, it makes some degree of sense that we support it<br>
>> everywhere and own it as a core language extension. For instance, we<br>
>> allow users to add GNU-style attribute spellings that GCC does not<br>
>> support and no one takes issue.<br>
>><br>
>> Do we want the same level of ownership over __declspec? If someone<br>
>> wants to add a new attribute with a __declspec spelling that is not<br>
>> supported by MSVC, will we allow it? I struggle to imagine us allowing<br>
>> that as it can cause future compatibility issues if Microsoft were to<br>
>> use the same attribute name with different semantics.<br>
><br>
><br>
> I think we should be free to add stuff to __declspec if we don't think it is<br>
> likely that MSVC would repurpose the same attribute for a different purpose.<br>
<br>
</span>I disagree, unless we get strong supporting murmurs from Microsoft on<br>
the given attribute's likelihood (or not) of being included in Visual<br>
Studio. __declspec is Microsoft's conforming language extension. It<br>
seems to me like we'd be acting in bad faith if we co-opted that for<br>
our own attributes when we have existing mechanisms that are not tied<br>
to a proprietary compiler's language extension (like C++11 style<br>
attributes which have an explicit scoping mechanism, or even<br>
__attribute__, sub-optimally).<br></blockquote><div><br></div><div>I fail to see how this is materially different from us adding stuff to __attribute__.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> Microsoft seems to be aware that others build tools with command lines and<br>
> attributes compatible with their tooling. For example, they reused ICC's<br>
> /Qvec-report flag for MSVC 2012.<br>
<br>
</span>If we were to start supporting compatibility with ICC, I would not be<br>
opposed to adding ICC-specific __declspec spellings, to be clear. I'm<br>
more against the idea of adding something like<br>
__declspec(no_sanitize("address")) as an example.<br></blockquote><div><br></div><div>I also think it makes sense for us to add ICC-specific __declspec spellings.  Could we make our support for align_value symmetric? We support the GNU spelling but not the __declspec.</div><div><br></div><div>How is adding support for an ICC-specific __declspec different from us adding our own?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
~Aaron<br>
</font></span><div><div><br>
><br>
>><br>
>> For that reason,<br>
>> I think __declspec should be guarded by -fms-extensions, but I wanted<br>
>> to get community feedback before making such a change.<br>
>><br>
>> Thanks!<br>
>><br>
>> ~Aaron<br>
><br>
><br>
</div></div></blockquote></div><br></div></div>