On Dec 9, 2007, at 2:04 PM, Sean Middleditch wrote: > On Sun, 2007-12-09 at 10:05 -0800, Chris Lattner wrote: >> 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.
Yep, the other big win is that with one binary you'd be able to do: clang foo.c -triple sparc-sun-solaris8 clang foo.c -triple i386-pc-linux-gnu or whatever. This requires installing headers for all targets in and making them work in place. > 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. As Neil mentioned, I don't think this is an issue. -Chris _______________________________________________ cfe-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
