On Mon, 6 Jun 2011, Rainer Orth wrote: > Paolo Bonzini <bonz...@gnu.org> writes: > > >> * Except for Darwin, the code uses TRAMPOLINE_SIZE. This only exists in > >> the backend headers. While it could be duplicated somewhere in the > >> libgcc configury, I'd rather propose that gcc define > >> __TRAMPOLINE_SIZE__ (in gcc/c-family/c-cppbuiltin.c (c_cpp_builtins) > >> to avoid this. On PowerPC Darwin, one cannot use TRAMPOLINE_SIZE > >> definition right now since the macro calls the rs6000_trampoline_size > >> function in rs6000/rs6000.c. This would be solved nicely by > >> __TRAMPOLINE_SIZE__. > > > > Good idea. > > Included in the revised patch below. This part will need Joseph's approval.
Is this definition ever going to be of use to user code, or even to system headers? It looks purely like an implementation detail rather than something meaningful for users. That would tend to suggest conditioning it on the proposed new -fbuilding-libgcc option that I suggested in <http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01206.html>. (There are a *lot* of target macros that are in a similar position - see the list under "used by the compiler itself and libgcc" in <http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration>. Even if we could define and document public semantics for corresponding predefined macros, I don't think they would be of practical use to users of GCC, so for most of them I expect defining __LIBGCC_<macro>, only if -fbuilding-libgcc, is the best way of eliminating the dependence on host tm.h without making implementation details visible to users of GCC.) So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if -fbuilding-libgcc. -- Joseph S. Myers jos...@codesourcery.com
