This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Feature request - a macro defined for GCC


[Adding the Sparse mailing list to CC.]

On Thu, 2008-07-03 at 09:37 -0700, Chris Lattner wrote:
> IMO, the whole notion of a compiler-specific macro has pretty limited  
> usefulness.  Why not add macros for specific *features* offered by the  
> compiler.  For example:
> 
> #ifdef __SUPPORTS_NESTED_FUNCTIONS__
> 
> is much better than some mismash of version checking, which isn't  
> guaranteed to be right in the future.  One disadvantage of this is  
> that it will put even more burden on the already overloaded  
> preprocessor.  It would be much nicer to have a feature query system  
> that doesn't rely on one macro per system.  Perhaps something like:
> 
> #if __feature_supported(nested_functions) &&  
> __feature_supported(transparent_union) &&  
> __feature_supported(attribute_aligned)
> ...
> 
> Taking an approach reduces startup time of the preprocessor, because  
> it doesn't have to populate the identifier table with tons of  
> predefines.

ïSpeaking as the maintainer of Sparse, I would love to see GCC adopt
such an approach.  I don't like that Sparse currently has to define GNUC
and other such macros, and impersonate a GCC version that implies
support for the GCC extensions it has.  While that support probably
needs to stick around for backward compatibility, I'd much rather have
Sparse support some new feature-testing construct.

I'd suggest defining exactly one new preprocessor symbol, to advertise
the support for the feature-testing mechanism.  For instance,
__HAVE_EXTENSION_SUPPORTED__, or __FEATURE_SUPPORTED_SUPPORTED__. :)
The rest could use syntax like you suggest above.  For instance:

#ifdef __HAVE_EXTENSION_SUPPORTED__
#if __have_extension__(noreturn)
#define ATTR_NORETURN __extension__((noreturn))
#endif
ï#if __have_extension__(sentinel)
#define ATTR_SENTINEL __extension__((sentinel))
#endif
#endif
#ifndef ATTR_NORETURN
#define ATTR_NORETURN
#endif
ï#ifndef ATTR_SENTINEL
#define ATTR_SENTINEL
#endif

The same thing would work for Sparse extensions:

ï#ifdef __HAVE_EXTENSION_SUPPORTED__
#if __have_extension__(address_space) && __have_extension__(noderef)
#define __user __extension__((address_space(1),noderef))
#endif
#endif
#ifndef __user
ï#define __user
#endif

The only problem then becomes maintaining the canonical list of
extension names.  We could use the ugly approach of names like
"org.gnu.gcc.extension.sentinel" and "org.kernel.sparse.address_space",
but that seems entirely too ugly.  The other alternative seems like a
central registry of extension names; I'd happily help maintain such a
registry.

Thoughts?

- Josh Triplett



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]