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. > The following tweak to the 2 files address both issues. how does that seem? > > Andrew >
