Is __declspec a core language extension?

[Aaron Ballman]

It sounds like there are not major objections to making __declspec
controlled by -fms-extensions. Here's the patch I am proposing, with a
few things called out.

* __declspec is also a Borland extension in addition to an MS one
* supporting __declspec under CUDA, but not the full set of ms extensions

~Aaron

On Wed, May 20, 2015 at 8:17 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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 --------------
A non-text attachment was scrubbed...
Name: declspec_ms_ext.patch
Type: application/octet-stream
Size: 35076 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150521/6d0a33e0/attachment.obj>