Handle macros like TARGET_OS_CPP_BUILTINS for non C-family frontends

FX fxcoudert@gmail.com
Mon Sep 27 04:38:00 GMT 2010


Hi all,

I'm trying to see a way forward for PR 42954: when preprocessing Fortran source files, we used to call the C preprocessor and run the Fortran compiler on the generated file. We now use libcpp directly, but by doing so, we have lost a good number of target-dependent CPP builtins that are defined via TARGET_OS_CPP_BUILTINS and TARGET_CPU_CPP_BUILTINS macros. These macros were used in real-life code (including mine!) for conditional compilation, and the new behaviour is a regression.


The reason these macros can't be used directly can be seen on the example of config/sol2.h:

#define TARGET_OS_CPP_BUILTINS()                        \
    do {                                                \
        builtin_define_std ("unix");                    \
        builtin_define_std ("sun");                     \
        /* For C++ we need to add some additional macro \
           definitions required by the C++ standard     \
           library.  */                                 \
        if (c_dialect_cxx ())                           \
          {                                             \
            builtin_define ("__STDC_VERSION__=199901L");\
            builtin_define ("_XOPEN_SOURCE=600");       \
          }                                             \
        TARGET_SUB_OS_CPP_BUILTINS();                   \
    } while (0)

(I've removed a few lines, but you get the idea.)

Calling c_dialect_cxx() is not going to work in the Fortran front-end, as this is a function defined in c-family/c-common.h, which we don't include (and don't want to include!). Other such problematic functions or variables include flag_isoc99, flag_iso, flag_leading_underscore (see full list at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954).



How can we fix this? The only way I see would be to have two macros instead of TARGET_OS_CPP_BUILTINS: one that will be used for source-preprocessing in all languages (maybe keeping the name TARGET_OS_CPP_BUILTINS), and one that will be used only for C-family languages (TARGET_OS_CPP_BUILTINS_CFAMILY). It seems like a bit of work, to get everything in the right place. However, I don't really see an alternative solution, which is why I'm writing here: would there be any easier solution? Or one that makes more sense to you?

As this is a major change, I'd like to get this in before the end of stage1, probably submitting it next week-end, if we can agree on a path for me to implement.

Thanks for the help!
FX



More information about the Gcc mailing list