On Tue, Jun 2, 2015 at 4:19 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 06/02/2015 09:30 AM, Richard Biener wrote: >> >> On Tue, Jun 2, 2015 at 2:34 PM, Andrew MacLeod <amacl...@redhat.com> >> wrote: >>> >>> On 06/02/2015 04:26 AM, Richard Biener wrote: >>>> >>>> On Mon, Jun 1, 2015 at 11:02 PM, Andrew MacLeod <amacl...@redhat.com> >>>> wrote: >>>>> >>>>> >>>>> Bootstraps from scratch on x86_64-unknown-linux-gnu with no new test >>>>> regressions. I also built it on all the config-list.mk targets with no >>>>> additional compilation errors. >>>>> >>>>> OK for trunk? >>>> >>>> Generally the idea is sound (amend coretypes.h), but I don't like the >>>> GCC_CONFIG_H guard, why does !GENERATOR_FILE not work? >>> >>> Target files also use coretypes.h. In particular, libgcc includes it and >>> does not have GENERATOR_FILE set. Rather than checking for GCC_CONFIG_H >>> we >>> could check >>> >>> #if !defined (GENERATOR_FILE) && !defined (USED_FOR_TARGET) >>> >>> I think that should work OK. >>>> >>>> Furthermore I don't like the special-casing in rtl.h, instead have >>>> coretypes.h contain sth like >>>> >>>> #ifdef GENERATOR_FILE >>>> ... rtl.h special-case >>>> #else >>>> ... GCC_CONFIG_H stuff >>>> #endif >>>> >>>> Thanks, >>>> Richard. >>> >>> >>> This one is harder. I don't like the special case either, but you cant >>> really figure it out in coretypes.h. The problem comes from some >>> generator >>> files which compile rtl.c and and a couple of other files, and thus have >>> GENERATOR_FILE set... These run after the initial set of generators so >>> insn-modes.h and friends have been created, and these includes are now >>> required. the presence of rtl.h seems to be the the litmus test and if >>> it >>> occurs in the include chain after coretypes.h, then we'll need these >>> files. >>> >>> I suppose you could just include those files in rtl.h directly without >>> the >>> guard... it is probably the cleanest solution. Otherwise we'd either >>> have >>> to add a new identifying macro to a dozen generator files, or include >>> these >>> headers there, or some other such thing. >> >> Well, then include the requirements in the generator files instead? It >> looks >> backwards to add to the includes in rtl.h. >> >> Richard. > > Except that it is rtl.h that actually has the compilation requirement. I > could put those includes in each of the generator files which require it, > but the list is non-trivial: > Each of these files can be compiled with bconfig.h instead of config.h, and > they each include rtl.h which requires these headers: > genattr.c > genattr-common.c > genattrtab.c > genautomata.c > gencodes.c > genconditions.c > genconfig.c > genemit.c > genextract.c > genflags.c > genmddump.c > genopinit.c > genoutput.c > genpeep.c > genpreds.c > genrecog.c > gensupport.c > print-rtl.c > read-rtl.c > rtl.c > > > so there are 20 files which require these headers, and there are 11 others > which do not require rtl.h nor the headers (and will fail compile if they > are included) > gencheck.c > genconstants.c > genenums.c > genmatch.c > genmddeps.c > genmodes.c > ggc-none.c > hash-table.c > inchash.c > read-md.c > vec.c > > > I suppose one could add something like: > #define EARLY_GENERATOR > in each of the 11 and check for that macro in coretypes.h instead of > GENERATOR file. ThIs appears to work fine:
I don't like that either ... which of the includes are the problematic ones? I guess only machmode.h (and thus wide-int.h?) Can't we just guard parts of rtl.h / wide-int.h properly? As a transitional measure the variant with the rtl.h includes dependent on GENERATOR_FILE is ok. Thanks, RIchard. > Andrew > >
