Preprocessor symbols in non-C languages

Preprocessor symbols in non-C languages

[Waldek Hebisch]

What is current policy concerning use of predefined preprocessors
symbols in non-C languages? Currently GNU Pascal contains a preprocessor
which used to predefine all symbols which C preprocessor predefine
(via CPP_PREDEFINES). For 3.3 backend and above I am trying to use 
TARGET_CPU_CPP_BUILTINS and TARGET_OS_CPP_BUILTINS. But the new macros
despite beeing defined in language independent header tend to hook 
more and more into C frontend. ATM GNU Pascal to work around the problem
provides stubs for missing C symbols, but I am asking for long-term 
solution.

If TARGET_CPU_CPP_BUILTINS and TARGET_OS_CPP_BUILTINS are deemed C
specific, then how is a frontend supposed to collect target information
needed by user programs? Will patches to remove C dependency in
TARGET_CPU_CPP_BUILTINS and TARGET_OS_CPP_BUILTINS be accepted?

Note that lack of target predefines was the main regression in 
GNU Pascal when using 3.3 and newer backends.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

Re: Preprocessor symbols in non-C languages

[Joseph S. Myers]

On Sat, 14 Aug 2004, Waldek Hebisch wrote:

> What is current policy concerning use of predefined preprocessors
> symbols in non-C languages? Currently GNU Pascal contains a preprocessor
> which used to predefine all symbols which C preprocessor predefine
> (via CPP_PREDEFINES). For 3.3 backend and above I am trying to use 
> TARGET_CPU_CPP_BUILTINS and TARGET_OS_CPP_BUILTINS. But the new macros
> despite beeing defined in language independent header tend to hook 
> more and more into C frontend. ATM GNU Pascal to work around the problem
> provides stubs for missing C symbols, but I am asking for long-term 
> solution.

The documentation of these macros lists the interface as three main 
functions (or macros) they may call, builtin_define, builtin_define_std 
and builtin_assert, along with

c_language
clk_c (which includes assembler)
clk_cplusplus
clk_objective_c
preprocessing_asm_p
flag_iso
preprocessing_trad_p

which you can define appropriately for GNU Pascal.  Note that 
c-cppbuiltin.c defines some of these names as macros to call cpplib 
functions; there is no direct target dependence on cpplib, the interface 
allows for non-C and non-cpplib front ends.

  /* A straightforward target hook doesn't work, because of problems
     linking that hook's body when part of non-C front ends.  */
# define preprocessing_asm_p() (cpp_get_options (pfile)->lang == CLK_ASM)
# define preprocessing_trad_p() (cpp_get_options (pfile)->traditional)
# define builtin_define(TXT) cpp_define (pfile, TXT)
# define builtin_assert(TXT) cpp_assert (pfile, TXT)
  TARGET_CPU_CPP_BUILTINS ();
  TARGET_OS_CPP_BUILTINS ();
  TARGET_OBJFMT_CPP_BUILTINS ();

(While builtin_define_std is a real function.)

Now, it seems the documentation is out of date and the headers now use 
c_dialect_cxx and c_dialect_objc, which means the documentation needs 
updating; you can just define those function-like macros to false for GNU 
Pascal.  mips/iris6.h also uses flag_isoc99, which is not in the 
documented interface; this would be another bug in the documentation, and 
you can define flag_isoc99 for your front end as well.  In general, this 
is meant to be a documented interface, and the problems with the 
documentation should be fixable.

The rationale for this approach replacing specs is that when predefines 
depended on command-line options, and were meant to express some part of 
the internal state of the compiler, there were two different 
implementations of the logic for arriving at that state, one in the specs 
and one that parsed the command line options in the internal compiler 
executables such as cc1, and keeping these in sync was very error-prone. 
The transition is as yet incomplete: there are still macros defined in 
specs that should migrate to the new system.

As for C dependencies accidentally entering target headers, I must urge 
again the inclusion of GNU Pascal in GCC CVS as the best way of ensuring 
that it is not accidentally broken by changes to GCC.  Compiler testing 
uses those included front ends that are enabled by default, and global 
cleanups take account of those features that are being used in GCC CVS; 
features are not kept in the tree for the sake of front ends (or target 
CPU architectures) that are not in CVS.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)