Is __declspec a core language extension?
rnk at google.com
Wed May 20 17:13:55 PDT 2015
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>
> 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.
> On Wed, May 20, 2015 at 5:54 PM, Aaron Ballman <aaron at aaronballman.com>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits