[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Handle macros like TARGET_OS_CPP_BUILTINS for non C-family frontends
From:       "Joseph S. Myers" <joseph () codesourcery ! com>
Date:       2010-09-26 14:37:39
Message-ID: Pine.LNX.4.64.1009261427220.1101 () digraph ! polyomino ! org ! uk
[Download RAW message or body]

On Sun, 26 Sep 2010, FX wrote:

> 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?

If you're redesigning these macros, you ought to be designing things to 
use hooks instead anyway, though these macros probably aren't that easy to 
replace by hooks.

You could I suppose define the hooks to take a structure of callbacks that 
they use in place of directly calling builtin_define or testing 
flag_isoc99 - or if you set up s separate hooks structure that is at least 
only used in front ends that link with libcpp, then you might reduce the 
number of callbacks needed.  Or you could fully split things up as you 
suggest - put C-family-only hooks in targetcm, and libcpp-using hooks in a 
new structure.  Splitting things up is probably cleaner than having a lot 
of callbacks.

Whatever you do, you probably want to arrange for the code that is common 
between c-family/c-cppbuiltin.c and fortran/cpp.c (defining various 
language-independent macros) to be genuinely shared between front ends 
using libcpp, instead of duplicated.

-- 
Joseph S. Myers
joseph@codesourcery.com
[prev in list] [next in list] [prev in thread] [next in thread]