www.digitalmars.com         C & C++   DMDScript  

D.gnu - (Token t) is not callable using argument types (Token): GDC bug or

reply Matthias Klumpp <mak debian.org> writes:
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
Jan 29
next sibling parent Matthias Klumpp <mak debian.org> writes:
Btw, the full build matrix with logs for all architectures can be 
viewed at https://buildd.debian.org/status/package.php?p=dustmite
Jan 29
prev sibling next sibling parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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.
Jan 29
prev sibling parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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.
Jan 29
parent reply Matthias Klumpp <mak debian.org> writes:
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.
Jan 29
next sibling parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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.
Jan 29
prev sibling next sibling parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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.
Jan 29
prev sibling next sibling parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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. ---
Jan 30
prev sibling parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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. :-)
Jan 30