Jump to page: 1 2 3
Thread overview
D Compiler Bug?
Jan 28, 2019
Bottled Gin
Jan 28, 2019
Bottled Gin
Jan 28, 2019
Adam D. Ruppe
Jan 28, 2019
Nemanja Borić
Jan 28, 2019
Bottled Gin
Jan 29, 2019
Adam D. Ruppe
Jan 30, 2019
Nemanja Boric
Jan 30, 2019
Bottled Gin
Jan 31, 2019
FeepingCreature
Jan 31, 2019
Bottled Gin
Feb 01, 2019
Seb
Feb 01, 2019
Adam D. Ruppe
Feb 02, 2019
Bottled Gin
Feb 06, 2019
Bottled Gin
Feb 12, 2019
Bottled Gin
Feb 12, 2019
Bottled Gin
Feb 12, 2019
Bottled Gin
Feb 12, 2019
H. S. Teoh
Feb 13, 2019
Bottled Gin
Feb 13, 2019
H. S. Teoh
Feb 13, 2019
Bottled Gin
Feb 20, 2019
Bottled Gin
January 28, 2019
I am using LDC-1.14-beta1, but tried with LDC-1.12 as well. This bug totally freaked me out. It took me over a week to reduce to this level from my forty thousand line project (thanks dustmite).

I am compiling a static library and then linking to the file having main function. I get assert for a class method which I am not calling anywhere. I am posting it in the forum so that I can get some help reducing it further. Right now it is < 100 lines, but spread over 9 files.

I have put the code on github. -> https://github.com/dsnippet/ldcbug

To test, clone the git repo, have LDC in path and make run.

Please help.
January 28, 2019
This is what I get on my Ubunto 16.04 machine. Strange that the code never calls func1!

core.exception.AssertError@grault.d(6): func1 was never called

January 28, 2019
huh it worked for me, but I am on a different ldc version. is it easy for you to update that?
January 28, 2019
On Monday, 28 January 2019 at 21:00:42 UTC, Adam D. Ruppe wrote:
> huh it worked for me, but I am on a different ldc version. is it easy for you to update that?

Fails for me in the same way as OP described.

ldc: stable 1.13.0

Interestingly, if you call func7 and not func8 from func, you get stack overflow (func starts calling itself). You can reduce the levels of inheritance, but foo seems to be important.
January 28, 2019
On Monday, 28 January 2019 at 21:00:42 UTC, Adam D. Ruppe wrote:
> huh it worked for me, but I am on a different ldc version. is it easy for you to update that?

I am using LDC-1.14.0-beta1. The only way to upgrade is to compile from source.
What version is yours?
January 29, 2019
On Monday, 28 January 2019 at 23:57:09 UTC, Bottled Gin wrote:
> I am using LDC-1.14.0-beta1. The only way to upgrade is to compile from source.
> What version is yours?

Mine is actually older, 1.12-beta but I was wrong; it actually did happen, I was just compiling it wrong. Sorry, my mistake.

So yeah, bug confirmed. Strange: it only happens with separate compilation. If you compile directly with ldc2 *.d, it all works.

The vtable seems to be wrapping around. So when we call func7, it goes back to func, func8 goes to func1, if we were to add a func9, it goes to func2.

ldc2 *.d # works correctly

for i in *.d; do ldc2 -c $i; done;
ldc2 *.o # produces the wrong code


huh, this is totally weird. And it happens with dmd as well as ldc, so it isn't a compiler specific thing; we have a frontend bug.

I gotta run, will look more later though.
January 30, 2019
On Tuesday, 29 January 2019 at 00:17:22 UTC, Adam D. Ruppe wrote:
> On Monday, 28 January 2019 at 23:57:09 UTC, Bottled Gin wrote:
>> [...]
>
> Mine is actually older, 1.12-beta but I was wrong; it actually did happen, I was just compiling it wrong. Sorry, my mistake.
>
> So yeah, bug confirmed. Strange: it only happens with separate compilation. If you compile directly with ldc2 *.d, it all works.
>
> The vtable seems to be wrapping around. So when we call func7, it goes back to func, func8 goes to func1, if we were to add a func9, it goes to func2.
>
> ldc2 *.d # works correctly
>
> for i in *.d; do ldc2 -c $i; done;
> ldc2 *.o # produces the wrong code
>
>
> huh, this is totally weird. And it happens with dmd as well as ldc, so it isn't a compiler specific thing; we have a frontend bug.
>
> I gotta run, will look more later though.

I suggest to open the issue in bugzilla as well. This post will soon disappear from the first page.
January 30, 2019
> I suggest to open the issue in bugzilla as well. This post will soon disappear from the first page.

Reducing a similar case in dustmite. Hopefully, I will have the reduced test by tomorrow or day after. Will file a bug after that.

BTW, looks like it has something to do with selective import in foo.d:

import corge: corge;

I can confirm that the bug disappears (even in my 40000 line project) if I replace it with:

import corge;

Not that I do not use selective imports elsewhere. But a combination of this selective import with some other factors seems to cause the bug.

Any clues?
January 31, 2019
What an amazing issue! I'm in love!

I've given you a PR to reduce the test further. The issue is related to the circular import between foo and qux, and the fact that qux forces foo to do ~something~ with its vtable to enable its use in the hashmap.
January 31, 2019
On Thursday, 31 January 2019 at 09:41:42 UTC, FeepingCreature wrote:
> What an amazing issue! I'm in love!
>
> I've given you a PR to reduce the test further. The issue is related to the circular import between foo and qux, and the fact that qux forces foo to do ~something~ with its vtable to enable its use in the hashmap.

Thanks, I merged in your PR.

I managed to minimize another issue which I believe could be related. This time it is a compile time error which occurs only when compiling separately. Compiling the modules together does not result in Error.

$ git clone https://github.com/dsnippet/circular.git
$ cd circular
$ ldc2 -c foo.d

With LDC-1.14-beta1, I get:

fred.d(4): Error: function void fred.qux!(bar).qux.thunk() does not override any function, did you mean to override void foo.foo.thunk()?
fred.d(7): Error: template instance `fred.qux!(bar)` error instantiating

« First   ‹ Prev
1 2 3