Is __declspec a core language extension?

[Richard Smith]

Can we just enable __declspec for CUDA rather than all of -fms-extensions?

Long-term, we should probably have some syntax for this CUDA evilness
that's not the MS __declspec extension...

On Wed, May 20, 2015 at 5:13 PM, Reid Kleckner <rnk at google.com> wrote:

> That's Art's fault. Probably the easiest thing to do is enable
> fms-extensions for cuda and let it go at that.
>
> On Wed, May 20, 2015 at 4:09 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>
>> This has one interesting ramification which I wasn't quite expecting.
>> cuda_builtin_vars.h uses __declspec(property), and it seems strange to
>> me that someone who wishes to use CUDA should have to also use
>> -fms-extensions. I'm not certain what the correct answer is for this
>> particular case.
>>
>> ~Aaron
>>
>> On Wed, May 20, 2015 at 5:54 PM, Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>> > While refactoring some attribute parsing code, I noticed that we do
>> > not guard __declspec as being a Microsoft-specific extension that we
>> > support. This is consistent with the behavior we have for
>> > __attribute__. In both cases, the keyword is available everywhere, and
>> > specific attributes determine their target requirements. However, I
>> > wonder if that's the behavior we want.
>> >
>> > With __attribute__, it makes some degree of sense that we support it
>> > everywhere and own it as a core language extension. For instance, we
>> > allow users to add GNU-style attribute spellings that GCC does not
>> > support and no one takes issue.
>> >
>> > Do we want the same level of ownership over __declspec? If someone
>> > wants to add a new attribute with a __declspec spelling that is not
>> > supported by MSVC, will we allow it? I struggle to imagine us allowing
>> > that as it can cause future compatibility issues if Microsoft were to
>> > use the same attribute name with different semantics. For that reason,
>> > I think __declspec should be guarded by -fms-extensions, but I wanted
>> > to get community feedback before making such a change.
>> >
>> > Thanks!
>> >
>> > ~Aaron
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150520/39d7f833/attachment.html>