On 30 January 2017 at 10:12, Iain Buclaw <ibuc...@gdcproject.org> wrote: > On 29 January 2017 at 22:45, Iain Buclaw <ibuc...@gdcproject.org> wrote: >> On 29 January 2017 at 22:09, Iain Buclaw <ibuc...@gdcproject.org> wrote: >>> On 29 January 2017 at 21:05, Matthias Klumpp via D.gnu >>> <d.gnu@puremagic.com> wrote: >>>> On Sunday, 29 January 2017 at 18:13:25 UTC, Iain Buclaw wrote: >>>>> >>>>> On 29 January 2017 at 19:12, Iain Buclaw <ibuc...@gdcproject.org> wrote: >>>>>> >>>>>> On 29 January 2017 at 17:59, Matthias Klumpp via D.gnu >>>>>> <d.gnu@puremagic.com> wrote: >>>>>>> >>>>>>> Hi! >>>>>>> When compiling Dustmite on Debian with GDC, the build runs into the >>>>>>> following error on i386: >>>>>>> ``` >>>>>>> splitter.d:875:15: error: function >>>>>>> splitter.DSplitter.postProcessBlockStatements.consume (Token t) is not >>>>>>> callable using argument types (Token) >>>>>>> if (consume(tokenLookup["if"]) || consume(tokenLookup["static if"])) >>>>>>> ^ >>>>>>> debian/rules:9: recipe for target 'override_dh_auto_build' failed >>>>>>> ``` >>>>>>> This only happens on i386 and other 32bit architectures, amd64 and even >>>>>>> x32 >>>>>>> are fine. >>>>>>> >>>>>>> Looking at the source code at >>>>>>> https://github.com/CyberShadow/DustMite/blob/master/splitter.d#L875 , I >>>>>>> can't find any obvious programming issue, so I currently assume that >>>>>>> this is >>>>>>> a GDC bug. >>>>>>> Or am I missing something? >>>>>>> In the former case, I'd file a bug against GDC. >>>>>>> Cheers, >>>>>>> Matthias >>>>>>> >>>>>> >>>>>> Whatever it is, it would be frontend-related (the error is semantic >>>>>> related, not codegen). I don't have any 32bit boxes to try out, unless >>>>>> I am >>>>>> able to reproduce this in a container or debootstrap-chroot. >>>>> >>>>> >>>>> And I can't reproduce using -m32 with current git head either, nor the >>>>> gdc-5 package that I have readily available on my laptop. >>>> >>>> >>>> Crazy... It's definitely not a frontend issue, since this compiles fine >>>> with >>>> DMD apparently.... I need to attempt a build of the package in a local >>>> 32bit >>>> chroot and see if that reproduces the issue. >>>> Alternatively I could also compile with LDC, but I deliberately picked GDC >>>> here to have Dustmite available on more architectures. >>>> Btw, while Debian has GDC on a lot of architectures, it seems to only be >>>> working on very few. >>> >>> Asking for port boxes is something I occasionally do for testing >>> building the library. The compiler should be portable, but >>> druntime+phobos less so. There are patches in druntime for C >>> bindings of PPC, MIPS, SuperH, etc. Without the hardware, I can't >>> verify how close it is to being complete. >> >> In any case, I can reproduce using a debug build build of gdc-6 on >> i386. But it seems that it is now gone in gdc-7. >> >> And the following change to the code fixes the compile time error. >> >> diff --git a/splitter.d b/splitter.d >> index 4f2220f..075e41e 100644 >> --- a/splitter.d >> +++ b/splitter.d >> @@ -872,7 +872,10 @@ struct DSplitter >> return false; >> } >> >> - if (consume(tokenLookup["if"]) || >> consume(tokenLookup["static if"])) >> + if (consume(tokenLookup["if"])) >> + consume(tokenLookup["else"]); >> + else >> + if (consume(tokenLookup["static if"])) >> consume(tokenLookup["else"]); >> else >> if (consume(tokenLookup["do"])) >> >> >> So maybe the frontend has some uninitialized data bug in handling OrOr >> expressions. > > > Then on the compiler side, there's something funny going on. > > In the resolveFuncCall handler, it seems that the first attempt at > resolving the function fails, try the same action again and it passes. > This is despite (to the best of my knowledge) there being no change of > state in functionResolve. > > I hope I'm wrong on that, because the alternative would be a C++ bug - maybe. > > --- > Match m; > memset(&m, 0, sizeof(m)); > m.last = MATCHnomatch; > functionResolve(&m, s, loc, sc, tiargs, tthis, fargs); // First > finds no match. > > memset(&m, 0, sizeof(m)); > m.last = MATCHnomatch; > functionResolve(&m, s, loc, sc, tiargs, tthis, fargs); // Second > finds match? This should not happen if the first failed. > ---
The bug also does not happen if I turn on debug AST tree printing, which only furthers my fears. :-)
