On Fri, Nov 20, 2015 at 10:43 AM, David Edelsohn <dje....@gmail.com> wrote: > On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop <seb...@gmail.com> wrote: >> Thanks David for reporting these problems. >> >> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn <dje....@gmail.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 >>> >>> or >>> >>> #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. > > https://gcc.gnu.org/ml/gcc-patches/2001-03/msg00484.html > > 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.
