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

[Iain Buclaw via D.gnu]

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.
---