Re: lto bootstrap fails.
On Mon, 13 Apr 2015, Jakub Jelinek wrote: > On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: > > [ Patch elided ] > > > > The patch applied cleanly - this is what I got as a result: > > > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html > > > > I hope this is useful. > > Looks like the http://gcc.gnu.org/ml/gcc-patches/2014-08/msg01014.html > patch is bad, including a header of one particular FE in the middle-end > is just wrong. > > #define TYPE_PTR_P(NODE)\ > (TREE_CODE (NODE) == POINTER_TYPE) > > #define TYPE_OBJ_P(NODE)\ > (TREE_CODE (NODE) != REFERENCE_TYPE \ >&& !VOID_TYPE_P (NODE) \ >&& TREE_CODE (NODE) != FUNCTION_TYPE \ >&& TREE_CODE (NODE) != METHOD_TYPE) > > #define TYPE_PTROB_P(NODE) \ > (TYPE_PTR_P (NODE) && TYPE_OBJ_P (TREE_TYPE (NODE))) > > is nothing that one couldn't just open-code in the middle-end, > like > if (TREE_CODE (scev) == SSA_NAME > && TREE_CODE (TREE_TYPE (scev)) == POINTER_TYPE > && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != REFERENCE_TYPE > && !VOID_TYPE_P (TREE_TYPE (TREE_TYPE ((scev > && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != FUNCTION_TYPE > && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != METHOD_TYPE) > but it is unclear why you want this check. For the middle-end, most pointer > conversions are useless, so the distinction between pointers to objects and > pointers to something different, might be long time lost. > Don't you want just > if (TREE_CODE (scev) == SSA_NAME && POINTER_TYPE_P (TREE_TYPE (scev))) > instead (i.e. just give up on all pointers/references)? That is what the > middle-end usually tests... I am testing the following. Richard. 2015-04-14 Richard Biener * graphite-scop-detection.c: Do not include cp/cp-tree.h. (graphite_can_represent_scev): Use POINTER_TYPE_P. Index: gcc/graphite-scop-detection.c === --- gcc/graphite-scop-detection.c (revision 222076) +++ gcc/graphite-scop-detection.c (working copy) @@ -70,7 +70,6 @@ along with GCC; see the file COPYING3. #include "tree-pass.h" #include "sese.h" #include "tree-ssa-propagate.h" -#include "cp/cp-tree.h" #ifdef HAVE_isl #include "graphite-poly.h" @@ -239,7 +238,7 @@ graphite_can_represent_scev (tree scev) the only nodes, which are disabled in case they are pointers to object types, but this can be changed. */ - if (TYPE_PTROB_P (TREE_TYPE (scev)) && TREE_CODE (scev) == SSA_NAME) + if (POINTER_TYPE_P (TREE_TYPE (scev)) && TREE_CODE (scev) == SSA_NAME) return false; switch (TREE_CODE (scev))
Re: lto bootstrap fails.
On 04/13/2015 06:00 PM, Trevor Saunders wrote: On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: On 04/11/2015 01:33 AM, Jan Hubicka wrote: On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like this: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html ODR rears its head again ... huh, why is c/c-lang.h getting included in files linked into cc1plus? that seems strange. readelf -wl cc1plus | grep c-lang.h doesn't show anything. I tried to reproduce it and my bootstrap passes with same options as Toon's The following patch ought to be able to tell the particular translation unit causing the conflict. [ Patch elided ] The patch applied cleanly - this is what I got as a result: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html I hope this is useful. ok, so the problem would seem to be graphite-scop-detection.c is including front end specific headers. Can you put a #error in cp-tree.h and recompile graphite-scop-detection.o to see what the path to including it is? Trev I get this: In file included from /home/toon/compilers/trunk/gcc/graphite-scop-detection.c:73:0: /home/toon/compilers/trunk/gcc/cp/cp-tree.h:52:2: error: #error #error ^ (See https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01493.html) -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: lto bootstrap fails.
On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: > [ Patch elided ] > > The patch applied cleanly - this is what I got as a result: > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html > > I hope this is useful. Looks like the http://gcc.gnu.org/ml/gcc-patches/2014-08/msg01014.html patch is bad, including a header of one particular FE in the middle-end is just wrong. #define TYPE_PTR_P(NODE)\ (TREE_CODE (NODE) == POINTER_TYPE) #define TYPE_OBJ_P(NODE)\ (TREE_CODE (NODE) != REFERENCE_TYPE \ && !VOID_TYPE_P (NODE) \ && TREE_CODE (NODE) != FUNCTION_TYPE \ && TREE_CODE (NODE) != METHOD_TYPE) #define TYPE_PTROB_P(NODE) \ (TYPE_PTR_P (NODE) && TYPE_OBJ_P (TREE_TYPE (NODE))) is nothing that one couldn't just open-code in the middle-end, like if (TREE_CODE (scev) == SSA_NAME && TREE_CODE (TREE_TYPE (scev)) == POINTER_TYPE && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != REFERENCE_TYPE && !VOID_TYPE_P (TREE_TYPE (TREE_TYPE ((scev && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != FUNCTION_TYPE && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != METHOD_TYPE) but it is unclear why you want this check. For the middle-end, most pointer conversions are useless, so the distinction between pointers to objects and pointers to something different, might be long time lost. Don't you want just if (TREE_CODE (scev) == SSA_NAME && POINTER_TYPE_P (TREE_TYPE (scev))) instead (i.e. just give up on all pointers/references)? That is what the middle-end usually tests... Jakub
Re: lto bootstrap fails.
On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: > On 04/11/2015 01:33 AM, Jan Hubicka wrote: > > >>On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: > >>>On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: > Like this: > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html > > ODR rears its head again ... > >>> > >>> huh, why is c/c-lang.h getting included in files linked into cc1plus? > >>> that seems strange. > >> > >>readelf -wl cc1plus | grep c-lang.h > >>doesn't show anything. > > > >I tried to reproduce it and my bootstrap passes with same options as Toon's > >The following patch ought to be able to tell the particular translation unit > >causing the conflict. > > [ Patch elided ] > > The patch applied cleanly - this is what I got as a result: > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html > > I hope this is useful. ok, so the problem would seem to be graphite-scop-detection.c is including front end specific headers. Can you put a #error in cp-tree.h and recompile graphite-scop-detection.o to see what the path to including it is? Trev > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: lto bootstrap fails.
On 04/11/2015 01:33 AM, Jan Hubicka wrote: On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like this: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html ODR rears its head again ... huh, why is c/c-lang.h getting included in files linked into cc1plus? that seems strange. readelf -wl cc1plus | grep c-lang.h doesn't show anything. I tried to reproduce it and my bootstrap passes with same options as Toon's The following patch ought to be able to tell the particular translation unit causing the conflict. [ Patch elided ] The patch applied cleanly - this is what I got as a result: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html I hope this is useful. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: lto bootstrap fails.
> On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: > > On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: > > > Like this: > > > > > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html > > > > > > ODR rears its head again ... > > > > huh, why is c/c-lang.h getting included in files linked into cc1plus? > > that seems strange. > > readelf -wl cc1plus | grep c-lang.h > doesn't show anything. I tried to reproduce it and my bootstrap passes with same options as Toon's The following patch ought to be able to tell the particular translation unit causing the conflict. Index: tree.c === --- tree.c (revision 221977) +++ tree.c (working copy) @@ -4679,6 +4679,8 @@ build_translation_unit_decl (tree name) tree tu = build_decl (UNKNOWN_LOCATION, TRANSLATION_UNIT_DECL, name, NULL_TREE); TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.name; + if (main_input_filename) +DECL_NAME (tu) = get_identifier (main_input_filename); vec_safe_push (all_translation_units, tu); return tu; } Index: ipa-devirt.c === --- ipa-devirt.c(revision 221977) +++ ipa-devirt.c(working copy) @@ -979,6 +979,21 @@ warn_odr (tree t1, tree t2, tree st1, tr return; inform (DECL_SOURCE_LOCATION (decl2), reason); + tree name = TYPE_NAME (t1); + tree name1 = decl2; + /* See if we have info about the translation unit. It may not be around + if types was already merged. */ +while (TREE_CODE (name) != TRANSLATION_UNIT_DECL) + name = TYPE_P (name) ? TYPE_CONTEXT (name) : DECL_CONTEXT (name); +while (TREE_CODE (name1) != TRANSLATION_UNIT_DECL) + name1 = TYPE_P (name1) ? TYPE_CONTEXT (name1) : DECL_CONTEXT (name1); +name = DECL_NAME (name); +name1 = DECL_NAME (name1); +if (name != name1 && name && name1) + inform (UNKNOWN_LOCATION, "Conflicting compilation units: %s and %s", + IDENTIFIER_POINTER (name), + IDENTIFIER_POINTER (name1)); + if (warned) *warned = true; }
