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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >
declspec_ms_ext.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
