This is the mail archive of the
mailing list for the GCC project.
Re: Graphite header order
- From: Sebastian Pop <sebpop at gmail dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: Sebastian Pop <s dot pop at samsung dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 20 Nov 2015 10:48:51 -0600
- Subject: Re: Graphite header order
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvny=BkUVoJkv8hzkCpQfUeuuOxjBCHLVBuHkgAfYS3FNwwQ at mail dot gmail dot com> <CAFk3UF_3MCMQGGAfr7_tzfFWCzB9NEQm9m41+E2MZMwtfX5fRA at mail dot gmail dot com> <CAGWvnymFssg0vi-QLZUjRZBMz_a9t4GTpKaHDp+mVN6wqZppdg at mail dot gmail dot com>
On Fri, Nov 20, 2015 at 10:43 AM, David Edelsohn <email@example.com> wrote:
> On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop <firstname.lastname@example.org> wrote:
>> Thanks David for reporting these problems.
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn <email@example.com> wrote:
>>> (2) All of the graphite*.c files include ISL headers first. This
>>> order is not supported by GCC development and creates conflicts for
>>> types and definitions provided / overridden by GCC headers, especially
>>> system.h and its dependent headers like hwint.h.
>>> I presume that ISL headers are included first is they use calloc() and
>>> strdup(), which are poisoned by GCC in system.h.
>> Yes, I do remember we had problems including the isl headers after system.h.
>>> I am uncertain of the exact header dependencies, but the primary
>>> dependency seems to be that the ISL headers must be included before
>>> graphite-poly.h. The identifier poisoning problem needs to be
>>> addressed by not poisoning the identifiers for files that include ISL
>>> headers. The Graphite files need some sort of a macro like
>>> #define IN_GRAPHITE
>>> #define IN_ISL
>>> and system.h must not poison the identifiers when that macro is present.
>>> I am going to try with a hack of bracketing system.h with #undef
>>> IN_GCC / #define IN_GCC in the graphite files.
>> I don't understand why these symbols are poisoned in GCC.
>> If there is a good reason to poison these functions, why would they
>> be fine to be used in Graphite and ISL?
>> Would it be possible to relax these constraints and remove the
>> poisoning of these functions in GCC?
> GCC should use xmalloc, xcalloc, xstrdup, etc.
> We cannot change ISL, so the poisoning should be lifted for those
> files instead of including headers in the wrong order.
Thanks for the explanation, that makes sense now.