(Token t) is not callable using argument types (Token): GDC bug or not?

Iain Buclaw via D.gnu d.gnu at puremagic.com
Mon Jan 30 01:35:06 PST 2017


On 30 January 2017 at 10:12, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> On 29 January 2017 at 22:45, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
>> On 29 January 2017 at 22:09, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
>>> On 29 January 2017 at 21:05, Matthias Klumpp via D.gnu
>>> <d.gnu at 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 <ibuclaw at gdcproject.org> wrote:
>>>>>>
>>>>>> On 29 January 2017 at 17:59, Matthias Klumpp via D.gnu
>>>>>> <d.gnu at 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. :-)


More information about the D.gnu mailing list