This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] consolidate some includes into coretypes.h
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 2 Jun 2015 15:30:21 +0200
- Subject: Re: [patch] consolidate some includes into coretypes.h
- Authentication-results: sourceware.org; auth=none
- References: <556CC87F dot 2090305 at redhat dot com> <CAFiYyc0Pu0x7WxjxeXPeZkxMeSm8n_Q_bM6My02DFHoA3ocf5g at mail dot gmail dot com> <556DA2C2 dot 4010704 at redhat dot com>
On Tue, Jun 2, 2015 at 2:34 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 06/02/2015 04:26 AM, Richard Biener wrote:
>>
>> On Mon, Jun 1, 2015 at 11:02 PM, Andrew MacLeod <amacleod@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
>