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

Btw, the full build matrix with logs for all architectures can be viewed at https://buildd.debian.org/status/package.php?p=dustmite

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.

On 29 January 2017 at 19:12, Iain Buclaw <ibuclaw@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.

On Sunday, 29 January 2017 at 18:13:25 UTC, Iain Buclaw wrote:
> On 29 January 2017 at 19:12, Iain Buclaw <ibuclaw@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.

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

On 29 January 2017 at 22:09, Iain Buclaw <ibuclaw@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 <ibuclaw@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.

On 29 January 2017 at 22:45, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 29 January 2017 at 22:09, Iain Buclaw <ibuclaw@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 <ibuclaw@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.
---

On 30 January 2017 at 10:12, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 29 January 2017 at 22:45, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>> On 29 January 2017 at 22:09, Iain Buclaw <ibuclaw@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 <ibuclaw@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. :-)