Is __declspec a core language extension?

[Artem Belevich]

On Thu, May 21, 2015 at 7:56 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> 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
>
>
Looks good.
Considering that cuda_builtin_vars.h is a borderline abuse of MS
extensions, I'd be fine requiring explicit -fms-extensions in order to use
that header, though I do like your approach of only enabling limited subset
of MS extensions for CUDA better.

--Artem



> ~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
> >>
> >>
> >
>



-- 
--Artem Belevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150521/f9d3c86a/attachment.html>