On Thu, May 21, 2015 at 7:56 AM, Aaron Ballman <[email protected]> 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 <[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 > >> > >> > > > -- --Artem Belevich
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
