This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: include tree.h instead of tree-core.h in expr.h
- From: Diego Novillo <dnovillo at google dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>, gcc <gcc at gcc dot gnu dot org>
- Date: Wed, 18 Dec 2013 08:24:34 -0500
- Subject: Re: include tree.h instead of tree-core.h in expr.h
- Authentication-results: sourceware.org; auth=none
- References: <CAJXstsBf2SwFfiOQLrqrdfiEm6oYk1HBn+c2pOZFM57awdhqGA at mail dot gmail dot com> <CAD_=9DQxa3GMc986-1AZOgdtHM-XxwXyyv3L9b1C2TDmpu6q3A at mail dot gmail dot com> <52B1A137 dot 4030903 at redhat dot com>
On Wed, Dec 18, 2013 at 8:20 AM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 12/18/2013 08:08 AM, Diego Novillo wrote:
>>
>> On Wed, Dec 18, 2013 at 6:57 AM, Prathamesh Kulkarni
>> <bilbotheelffriend@gmail.com> wrote:
>>
>>> Would it be better to include tree.h instead of tree-core.h (tree.h
>>> includes tree-core.h anyway), or shall I leave these macros untouched
>>> ?
>>
>> Better leave these macros intact for now. We are trying to flatten out
>> the #include tree. Adding tree.h to another header goes in the
>> opposite direction.
>>
>> Please add a note describing the conflict.
>>
>>
>>
> Looks like function.c is the primary user of {ADD,SUB}_PARM_SIZE, with a
> single use of ADD_PARM_SIZE in calls.c I'd suggest moving both new
> functions to function.c and exporting the protoype for add_parm_size() in
> function.h. calls.c already include function.h.
>
> I can't imagine that call to ADD_PARM_SIZE in calls.c having much impact on
> compile time...
Ah, yes, if the usage pattern of these macros is so simple, that's a
better option.
Diego.