Re: LTO ICE in D Frontend
On 10 July 2014 11:54, Richard Biener wrote: > On Thu, Jul 10, 2014 at 12:52 PM, Richard Biener > wrote: >> On Thu, Jul 10, 2014 at 11:52 AM, Iain Buclaw wrote: >>> On 10 July 2014 10:01, Richard Biener wrote: On Thu, Jul 10, 2014 at 10:51 AM, Iain Buclaw wrote: > On 10 July 2014 08:26, Richard Biener wrote: >> On July 10, 2014 8:31:54 AM CEST, Iain Buclaw >> wrote: >>>Hi, >>> >>>I'm trying to get to the bottom of a bug when using the D front-end >>>with -flto. >>> >>>When compiling anything, it always ICEs at in >>>streamer_get_pickled_tree, at tree-streamer-in.c. >>> >>>The of it appears to be that the LTO frontend seems to never retrieve >>>what it is expected to find. But I don't know what could be missing >>>from the code generation on my side to sort that out. >>> >>> >>>The following minimal test that yields an ICE. >>>--- >>>extern(C) int test = void; >>> >>> >>>I had set a breakpoint at hash_tree and looked at debug_tree output >>>from an equivalent program in C++, but nothing stands out as wrong >>>here to me. >>> >>>Any insight would be helpful. >>> >>> >>>// D >>>DECL_NAME: >>> >>> >>>DECL_CONTEXT: (null_tree) >> >> This should have a translation unit decl here. >> >> Richard. > > > I've been avoiding doing that for the last few years. Doesn't > progress any further the problem though. It looks like the LTO > front-end ICE's before it even attempts to read the decl context. > > Getting an ERROR_MARK when expecting an IDENTIFIER_NODE. > > Something not right with the DECL_NAME? It rather sounds like sth out-of-sync somewhere. Typical fronend issues are lang-specific tree codes leaking into LTO but that usually has a different kind of fallout. How is the D frontend integrated? Is it done "regularly", that is, in-tree? It's important that the all-tree.def generated at build time is consistent when building the D and the lto frontend. >>> >>> Yep, all-tree.def should be consistent between the two. d/d-tree.def >>> is included in the generated all-tree.def file. In my example though, >>> only core tree codes are used, and I would have thought that they >>> should be unaffected by the language tree codes (that have higher code >>> numbers). >> >> Yeah. I have no clue what goes wrong then, you have to debug it :/ >> (the testcase is small, so see where it writes the corresponding >> pieces in tree-streamer-out.c and try to match-up with the LTO read >> side in two parallel gdb sessions) > > Oh, another common source of issues is that the trees the streamer > cache is seeded with in preload_common_nodes is inconsistent > between D and LTO. In fact I bet it is that (you can simply add > some printfs and try to match entries). > It seems that I have got it working! Though I must admit it seems by complete accident rather than intent of my doing. There's some old (pre-2007, before I took over) backend initialisation of wint, pid, intmax... all of which are types not used by the D frontend but a necessity to flesh out GCC builtins to the language. I just did some clean-ups (120 odd line deletions) around it and aligned it up with what the LTO frontend does and... it works! Still, no clue how this could affect whether or not the LTO frontend ICE's, but it does. https://github.com/D-Programming-GDC/GDC/commit/28d98308.diff Regards Iain
Re: GCC 4.9.1 Status Report (2014-07-10)
On Fri, Jul 11, 2014 at 07:52:06PM +0100, Franzi Edo. wrote: > Hi All, > Thank you for your suggestions. > Unfortunately, no way! > > 4. I can generate my cross compiler based on the "gcc 4.8.3” without problem > (using both the apple-gcc4.2 or the XCode llvm) So, what has changed of > fundamental between the 4.8.3 and the 4.9 versions? (Sorry for any duplicate mails, my mailer is having difficulty with certain symbols in the body of the mail). The fundamental change was a patch I put in to 4.9 in October of 2013 [1]. In this patch, we use a large define_attr to group together all of the Neon types used for (set_attr "type") expressions in the ARM backend in the "is_neon_type" attribute, which we use later to decide if an instruction is predicable. We end up with a define_attr with around 290 elements for the "yes" case. As you can see in the preprocessed source on the LLVM bug [2], each element in the define_attr is expanded as ((cached_type == TYPE_NEON_FOO) || ... ) So after three elements we have 3 levels of nesting. After six, we have 6. After around 290 we have 290 levels of bracket nesting, and Clang errors. If there is a better way for me to write the "is_neon_type" attribute, I'll happily spin a patch for it. Certainly, I don't like the size of that generated "if" statement. Alternatively, perhaps the code which generates the if statement could be rewritten to build a switch rather than the large "||" expression. I don't know anything about the gen* programs and how define_attr can be used in the general case to say how feasible that change would be. None of this solves your problem in the interim, for that I think your best bet is to set -fbracket-depth=1024 in your BUILD_CFLAGS, as suggested by Chris. Thanks, James [1] https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_9-branch/gcc/config/arm/arm.md?r1=203059&r2=203613 [2] http://llvm.org/bugs/show_bug.cgi?id=19650 > > So, I am a bit without ideas > Cheers, >Edo > > > On 11 Jul 2014, at 00:29, Joel Sherrill wrote: > > > > > On 7/10/2014 5:14 PM, pins...@gmail.com wrote: > >> > >>> On Jul 10, 2014, at 3:13 PM, Ian Lance Taylor wrote: > >>> > On Thu, Jul 10, 2014 at 11:40 AM, Franzi Edo. wrote: > > As for the version 4.9.0, on OSX stil remain a problem. > I cannot build an ARM a cross compiler! > Here is the message (same as for the 4.9.0) > >>> You did not include enough context to be sure, but I don't think that > >>> error message is coming from GCC. At least, I don't see that error > >>> message in the GCC sources. > >>> > >>> I think that error message is coming from the host compiler you are > >>> using, in which case, based on the error message, the solution would > >>> seem to be > >> Also i thought we did not support cross building with anything besides > >> gcc. > > The RTEMS community sees this when using clang/llvm on FreeBSD. > > > > Franzi.. did the suggestion from Chris Johns to increase the limit > > to 1024, not work? > > > > https://gcc.gnu.org/ml/gcc/2014-05/msg00018.html > > > > This ended up being reported at http://llvm.org/bugs/show_bug.cgi?id=19650 > > > > --joel > >> Thanks, > >> Andrew > >> > >>> Ian > >
Re: GCC 4.9.1 Status Report (2014-07-10)
Hi James (all), Thank you for all of your suggestions. I tried everything unsuccessfully. Unfortunately, the make CFLAGS="-g -O2 -fbracket-depth=1024” and the make BUILD_CFLAGS="-g -O2 -fbracket-depth=1024” do not solve the problem. Well, at this point, I have to admit that I am a bit lost. So, if you have other suggestions, I will check them with pleasure. Thanks Edo On 12 Jul 2014, at 11:41, James Greenhalgh wrote: > On Fri, Jul 11, 2014 at 07:52:06PM +0100, Franzi Edo. wrote: >> Hi All, >> Thank you for your suggestions. >> Unfortunately, no way! >> >> 4. I can generate my cross compiler based on the "gcc 4.8.3” without problem >> (using both the apple-gcc4.2 or the XCode llvm) So, what has changed of >> fundamental between the 4.8.3 and the 4.9 versions? > (Sorry for any duplicate mails, my mailer is having difficulty with > certain symbols in the body of the mail). > > The fundamental change was a patch I put in to 4.9 in October of 2013 [1]. > > In this patch, we use a large define_attr to group together all of the Neon > types used for (set_attr "type") expressions in the ARM backend in the > "is_neon_type" attribute, which we use later to decide if an instruction is > predicable. We end up with a define_attr with around 290 elements for the > "yes" case. > > As you can see in the preprocessed source on the LLVM bug [2], each element > in the define_attr is expanded as > > ((cached_type == TYPE_NEON_FOO) || ... ) > > So after three elements we have 3 levels of nesting. After six, we have 6. > After around 290 we have 290 levels of bracket nesting, and Clang errors. > > If there is a better way for me to write the "is_neon_type" attribute, I'll > happily spin a patch for it. Certainly, I don't like the size of that > generated "if" statement. > > Alternatively, perhaps the code which generates the if statement could be > rewritten to build a switch rather than the large "||" expression. I don't > know anything about the gen* programs and how define_attr can be used in > the general case to say how feasible that change would be. > > None of this solves your problem in the interim, for that I think your best > bet is to set -fbracket-depth=1024 in your BUILD_CFLAGS, as suggested by > Chris. > > Thanks, > James > > [1] > https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_9-branch/gcc/config/arm/arm.md?r1=203059&r2=203613 > [2] http://llvm.org/bugs/show_bug.cgi?id=19650 > >> >> So, I am a bit without ideas >> Cheers, >> Edo >> >> >> On 11 Jul 2014, at 00:29, Joel Sherrill wrote: >> >>> >>> On 7/10/2014 5:14 PM, pins...@gmail.com wrote: > On Jul 10, 2014, at 3:13 PM, Ian Lance Taylor wrote: > >> On Thu, Jul 10, 2014 at 11:40 AM, Franzi Edo. wrote: >> >> As for the version 4.9.0, on OSX stil remain a problem. >> I cannot build an ARM a cross compiler! >> Here is the message (same as for the 4.9.0) > > You did not include enough context to be sure, but I don't think that > error message is coming from GCC. At least, I don't see that error > message in the GCC sources. > > I think that error message is coming from the host compiler you are > using, in which case, based on the error message, the solution would > seem to be > Also i thought we did not support cross building with anything besides gcc. >>> The RTEMS community sees this when using clang/llvm on FreeBSD. >>> >>> Franzi.. did the suggestion from Chris Johns to increase the limit >>> to 1024, not work? >>> >>> https://gcc.gnu.org/ml/gcc/2014-05/msg00018.html >>> >>> This ended up being reported at http://llvm.org/bugs/show_bug.cgi?id=19650 >>> >>> --joel Thanks, Andrew > Ian >>> >
