Re: Help needed: banishing RTL from the front ends

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

On Tue, May 25, 2010 at 9:56 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 05/25/2010 09:55 AM, Steven Bosscher wrote:
>>
>> 1) Group front end objects in Makefile.in under e.g.
>> ALL_HOST_FRONTEND_OBJS
>> 2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND
>> 3) Conditionally poison symbols in system.h
>>
>> For the last step, that would be e.g.:
>> #ifdef IN_GCC_FRONTEND
>> #pragma GCC poison GCC_RTL_H GCC_REGS_H ...
>> #endif
>>
>> Unfortunately, my Makefile-fu is insufficient to do step 2. There is
>> an implicit rule ".c.o:" that triggers no matter what I try, and I
>> don't want to add explicit $(COMPILER) rules for all the front end
>> objects.
>
> $(ALL_HOST_FRONTEND_OBJS): ALL_CFLAGS += -DIN_GCC_FRONTEND
>
> ?

Hmm, the following *almost* works...

--------------------- 8< --------------------
Index: Makefile.in
===================================================================
--- Makefile.in (revision 159808)
+++ Makefile.in (working copy)
@@ -1445,12 +1445,18 @@ OBJS = $(OBJS-common) $(OBJS-md) $(OBJS-

 OBJS-onestep = libbackend.o $(OBJS-archive)

+# This lists all host objects for the front ends.  Extra defines are passed
+# to the compiler for these objects.
+ALL_HOST_FRONTEND_OBJS = $(C_OBJS)
+  $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
+
+$(ALL_HOST_FRONTEND_OBJS): ALL_CFLAGS += -DIN_GCC_FRONTEND
+
 # This lists all host object files, whether they are included in this
 # compilation or not.
-ALL_HOST_OBJS = $(GCC_OBJS) $(C_OBJS) $(OBJS) libbackend.o \
+ALL_HOST_OBJS = $(GCC_OBJS) $(OBJS) libbackend.o \
   @TREEBROWSER@ main.o gccspec.o version.o intl.o prefix.o cppspec.o \
-  $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) \
-  $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \
+  $(ALL_HOST_FRONTEND_OBJS) $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \
   mips-tfile.o mips-tdump.o \
   $(GCOV_OBJS) $(GCOV_DUMP_OBJS)
--------------------- 8< --------------------


But  for some reason I get -DIN_GCC_FRONTEND also on some of the gen*
files, libiberty, and gcov-io.o, like so:

gcc -c  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -DIN_GCC_FRONTEND -DGENERATOR_FILE -I. -Ibuild
-I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4/include
-I/opt/cfarm/mpfr-2.4.1/include -I/opt/cfarm/mpc-0.8/include
-I../../trunk/gcc/../libdecnumber
-I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber
-I/opt/cfarm/libelf-0.8.12//include
-I/opt/cfarm/libelf-0.8.12//include/libelf  \
                -o build/genmodes.o ../../trunk/gcc/genmodes.c


The -DIN_GCC_FRONTEND is not passed to middle-end objects, so there
must somehow be a dependency on the generator files from the front
ends, that I don't see here.

I configured with "--enable-languages=c,objc,fortran". I don't see any
dependencies in the front end files:

# Target specific, C specific object file
C_TARGET_OBJS=@c_target_objs@

# Language-specific object files for C and Objective C.
C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o \
  c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \
  c-ppoutput.o c-cppbuiltin.o \
  c-objc-common.o c-dump.o c-pch.o c-parser.o $(C_TARGET_OBJS) \
  c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o

# Language-specific object files for C.
C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS)


# Language-specific object files for Objective C.
OBJC_OBJS = objc/objc-lang.o objc/objc-act.o


# These are the groups of object files we have.  The F95_PARSER_OBJS are
# all the front end files, the F95_OBJS are the files for the translation
# from the parse tree to GENERIC

F95_PARSER_OBJS = fortran/arith.o fortran/array.o fortran/bbt.o \
    fortran/check.o fortran/class.o fortran/constructor.o fortran/cpp.o \
    fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o \
    fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o \
    fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o \
    fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o \
    fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o \
    fortran/st.o fortran/symbol.o fortran/target-memory.o

F95_OBJS = $(F95_PARSER_OBJS) $(FORTRAN_TARGET_OBJS) \
    fortran/convert.o fortran/dependency.o fortran/f95-lang.o \
    fortran/trans.o fortran/trans-array.o fortran/trans-common.o \
    fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o \
    fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o \
    fortran/trans-stmt.o fortran/trans-types.o

I am guessing this comes in from the $C_TARGET_OBJS and other language
target objects. In the Makefile in the build directory I have this
dependency:

 Target specific, C specific object file
C_TARGET_OBJS=i386-c.o

But unfortunately I cannot find the rule for this object.

Anyway, I don't think that having a dependency on C_TARGET_OBJS should
introduce a dependency on the generator files. Sure, the C_TARGET_OBJS
files may be generated, but that should just mean that the gen*.o
files must be compiled first. Now, somehow, they end up in the list of
front-end files.

Any suggestions how to debug this?

Ciao!
Steven