D.gnu - (Token t) is not callable using argument types (Token): GDC bug or
- Matthias Klumpp (20/20) Jan 29 2017 Hi!
- Matthias Klumpp (2/2) Jan 29 2017 Btw, the full build matrix with logs for all architectures can be
- Iain Buclaw via D.gnu (6/27) Jan 29 2017 Whatever it is, it would be frontend-related (the error is semantic
- Iain Buclaw via D.gnu (3/32) Jan 29 2017 And I can't reproduce using -m32 with current git head either, nor the
- Matthias Klumpp (9/50) Jan 29 2017 Crazy... It's definitely not a frontend issue, since this
- Iain Buclaw via D.gnu (7/54) Jan 29 2017 Asking for port boxes is something I occasionally do for testing
- Iain Buclaw via D.gnu (22/78) Jan 29 2017 In any case, I can reproduce using a debug build build of gdc-6 on
- Iain Buclaw via D.gnu (18/97) Jan 30 2017 Then on the compiler side, there's something funny going on.
- Iain Buclaw via D.gnu (3/106) Jan 30 2017 The bug also does not happen if I turn on debug AST tree printing,
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 2017
Matthias Klumpp <mak debian.org> 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 2017
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 2017
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: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.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, MatthiasWhatever 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 2017
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: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 17:59, Matthias Klumpp via D.gnu <d.gnu puremagic.com> wrote: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.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, MatthiasWhatever 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 2017
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: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 19:12, Iain Buclaw <ibuclaw gdcproject.org> wrote: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 17:59, Matthias Klumpp via D.gnu <d.gnu puremagic.com> wrote: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.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, MatthiasWhatever 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 2017
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: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 Sunday, 29 January 2017 at 18:13:25 UTC, Iain Buclaw wrote: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 19:12, Iain Buclaw <ibuclaw gdcproject.org> wrote: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 17:59, Matthias Klumpp via D.gnu <d.gnu puremagic.com> wrote: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.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, MatthiasWhatever 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 2017
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: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 29 January 2017 at 21:05, Matthias Klumpp via D.gnu <d.gnu puremagic.com> wrote: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 Sunday, 29 January 2017 at 18:13:25 UTC, Iain Buclaw wrote: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 19:12, Iain Buclaw <ibuclaw gdcproject.org> wrote: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 17:59, Matthias Klumpp via D.gnu <d.gnu puremagic.com> wrote: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.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, MatthiasWhatever 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 30 2017
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:The bug also does not happen if I turn on debug AST tree printing, which only furthers my fears. :-)On 29 January 2017 at 22:09, Iain Buclaw <ibuclaw gdcproject.org> wrote: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 29 January 2017 at 21:05, Matthias Klumpp via D.gnu <d.gnu puremagic.com> wrote: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 Sunday, 29 January 2017 at 18:13:25 UTC, Iain Buclaw wrote: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 19:12, Iain Buclaw <ibuclaw gdcproject.org> wrote: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 17:59, Matthias Klumpp via D.gnu <d.gnu puremagic.com> wrote: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.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, MatthiasWhatever 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 30 2017