From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14626 invoked by alias); 14 Aug 2004 14:52:44 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14619 invoked from network); 14 Aug 2004 14:52:43 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sourceware.org with SMTP; 14 Aug 2004 14:52:43 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Bvztj-0001xF-2S for gcc@gnu.org; Sat, 14 Aug 2004 10:52:43 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BvztC-0002zB-58 for gcc@gnu.org; Sat, 14 Aug 2004 10:52:11 -0400 Received: from [193.111.201.132] (helo=lon-mail-6.gradwell.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1BvztB-0002wL-A3 for gcc@gnu.org; Sat, 14 Aug 2004 10:52:09 -0400 Received: (qmail 5464 invoked from network); 14 Aug 2004 14:52:03 -0000 Received: from digraph.polyomino.org.uk (postmaster%pop3.polyomino.org.uk@81.187.227.50) by lon-mail-6.gradwell.net with SMTP; 14 Aug 2004 14:52:03 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.41) id 1Bvzt5-0000Fa-6q; Sat, 14 Aug 2004 14:52:03 +0000 Date: Sat, 14 Aug 2004 15:15:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Waldek Hebisch cc: gcc@gnu.org Subject: Re: Preprocessor symbols in non-C languages In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-SW-Source: 2004-08/txt/msg00621.txt.bz2 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)