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

2017-01-29 Thread Matthias Klumpp via D.gnu

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



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

2017-01-29 Thread Matthias Klumpp via D.gnu
Btw, the full build matrix with logs for all architectures can be 
viewed at https://buildd.debian.org/status/package.php?p=dustmite




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

2017-01-29 Thread Matthias Klumpp via D.gnu

On Sunday, 29 January 2017 at 18:13:25 UTC, Iain Buclaw wrote:
On 29 January 2017 at 19:12, Iain Buclaw 
 wrote:
On 29 January 2017 at 17:59, Matthias Klumpp via D.gnu 
 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.


Re: Hello world in AAarch64 Debian Buster

2019-08-31 Thread Matthias Klumpp via D.gnu

On Thursday, 8 August 2019 at 01:17:53 UTC, Cecil Ward wrote:

On Wednesday, 7 August 2019 at 05:48:49 UTC, Iain Buclaw wrote:


You could raise a Debian bug report, saying that aarch64 is in 
the libphobos supported list.


Thanks Iain, I went through the prompts in the Debian bug 
report program and I hope that that has emailed a report to 
them which makes some kind of sense.


Probably not, you need to send an email to submit abug and if you 
didn't have a fully configured MTA installed or reportbug 
configured to use some other means to send the mail, it wouldn't 
have been sent.
See https://www.debian.org/Bugs/Reporting on how to create such a 
mail.
In any case, GCC in Buster won't be changed, while in Bullseye 
(current Testing) it is already adjusted for GDC 9.


So, you could potentially fetch gdc-9 from bullseye for buster, 
or actually just switch to using the Debian Bullseye development 
version. Depending on what you want to achieve, using Bullseye 
may be the easiest way to achieve your goal.




Re: GDC bug? duplicates symbols when using mixin and interface

2019-11-18 Thread Matthias Klumpp via D.gnu

On Tuesday, 29 October 2019 at 13:23:33 UTC, Daniel Kozak wrote:
On Thursday, 24 October 2019 at 11:05:21 UTC, Daniel Kozak 
wrote:


ld: c.o: in function `_DT16_D1b1B8__mixin24getSMFZPv':
c.d:(.text+0x27): multiple definition of 
`_DT16_D1b1B8__mixin24getSMFZPv'; b.o:b.d:(.text+0x38): first 
defined here


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92216


Thank you for reporting this!
This error is also a major pain for us at Debian: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944380


Re: gdc broken by ldc-phobos-devel on Fedora

2019-11-21 Thread Matthias Klumpp via D.gnu

On Wednesday, 20 November 2019 at 21:51:58 UTC, mipri wrote:

Howdy,

This was the case in Fedora 30, and is now the case in Fedora 
31.

RPMs are available for gdc and for ldc2, but when both are
installed gdc can't compile anything as it tries to load a 
version

of phobos installed by ldc2 which has features gdc doesn't yet
support. For someone who's decided to just use gdc for a 
project,

they have the easy fix of just uninstalling ldc2, but I'd expect
that someone evaluating D as a language will be interested in
comparing the different compilers, so all the compilers will be
installed--and then only dmd and ldc will be functional.


That's why we explicitly set the LDC include path in Debian: 
https://salsa.debian.org/d-team/ldc/blob/master/debian/rules#L15
This is a bug in Fedora, you could file an issue with the package 
at Fedora and ask them to do the same as Debian for include paths.
(we do set the path explicitly as linked, and also apply this 
patch: 
https://salsa.debian.org/d-team/ldc/blob/master/debian/patches/02_ldc_include_path.diff


Cheers,
Matthias