[cfe-dev] linux build fix

[Sean Middleditch]

On Sun, 2007-12-09 at 10:05 -0800, Chris Lattner wrote:
> The problem with this approach is that it requires dumping a ton of  
> macros into the compiler when it starts up, which is suboptimal.   
> Instead of having the current grab-bag of pre-defined macros, I'd like  
> to move to a more consistent set of extension points.  Specifically, I  
> think we should extend the grammar to support a new builtin, and use  
> this query for properties of the machine.  For example, we could use:
> 
> #define CHAR_BIT  __builtin_config_info("target_char_bit")
> #define SCHAR_MAX __builtin_config_info("target_schar_max")
> ...
> 
> This should be parsed as a "builtin" builtin like  
> __builtin_type_compatible_p, which has its own parsing logic and  
> builds its own explicit AST.  The nice thing about this is that it  
> preserves some amount of target parameterization in the AST, reduces  
> the amount of stuff we have to slam into the macro table at startup,  
> reduces pressure on the identifier table, and is nicely extensible to  
> other things in the future.

I like it.  Anything that removes the giant nest of #if tests and cutesy
math in headers is a good thing in my book, especially having dug
through those headers.  Whether they're defined by a standard or not,
it's still nice to have clean, well-commented, easy-to-read headers
shipped with your development environment.

> 
> Getting this right will require updating the code to be able to handle  
> __builtin_config_info as an [integer] constant expression, handle its  
> use in the preprocessor conditional, etc.
>
> The 'risk' to this is that it will change the preprocessed output of  
> the compiler vs GCC.  For example, something silly like this will  
> expand differently.
> 
> #define foo(x) # x
> 
> foo(CHAR_BIT);
> 
> However, anything that relies on that is dangerously non-conformant  
> anyway, so I don't feel too bad about breaking it :)

Hmm.  Wouldn't it be better to have those kinds of builtins evaluated at
pre-processing time anyway, both to avoid special-casing support for it
in #if macros as well as making end-user debugging of pre-processed code
a tiny bit easier?  Leaking compiler magic into pre-processed code might
not be the coolest idea.