Hi all,

I started to work on merging the 2.063 frontend: https://github.com/klickverbot/ldc/tree/merge-2.063

Almost compiles Phobos, but an implementation of ClassReferenceExp::toConstElem is missing. This shouldn't be hard to add, utilizing the struct initializer code.

After that, it's adapting the new section detection mechanism in druntime (which shouldn't be too hard, as I got a pretty good overview of the problem space already), and maybe implementing the DSO registry stuff for proper shared library support.

David

The merge-2.063 branch survives building Phobos now.

Yay! It's bugfixing time!

David

On Wednesday, 12 June 2013 at 18:45:40 UTC, David Nadlinger wrote:
> The merge-2.063 branch survives building Phobos now.
>
> Yay! It's bugfixing time!
>
> David

Sounds great!

I'll give it a try...

Kai

On Wednesday, 12 June 2013 at 19:09:47 UTC, Kai Nacke wrote:
> On Wednesday, 12 June 2013 at 18:45:40 UTC, David Nadlinger wrote:
>> The merge-2.063 branch survives building Phobos now.
>>
>> Yay! It's bugfixing time!
>>
>> David
>
> Sounds great!
>
> I'll give it a try...

There are some strange issues with the AA value type not being resolved (type->ty == Tident) in std.traits.

Sigh…

David

Seems like the ModuleInfo layout changed, tackling that before trying to fix anything else.

David

On Wednesday, 12 June 2013 at 19:26:30 UTC, David Nadlinger wrote:
> Seems like the ModuleInfo layout changed, tackling that before trying to fix anything else.

Scrap that – the fact that we are not emitting the extra minfo data is screwing up ModuleInfo iteration, which leads to no module constructors being called at all.

This is obviously a big problem.

David

On Wednesday, 12 June 2013 at 19:34:39 UTC, David Nadlinger wrote:
> Scrap that – the fact that we are not emitting the extra minfo data is screwing up ModuleInfo iteration, which leads to no module constructors being called at all.

If each LLVM module we generate would be emitted as an object file, this would be easy to resolve: Just emit _minfo_beg/_minfo_end and a constructor calling _d_dso_registry in module-level inline asm.

Still not quite clean on how to get this to work with IR-level linking…

David

On Wednesday, 12 June 2013 at 22:08:10 UTC, David Nadlinger wrote:
> On Wednesday, 12 June 2013 at 19:34:39 UTC, David Nadlinger wrote:
>> Scrap that – the fact that we are not emitting the extra minfo data is screwing up ModuleInfo iteration, which leads to no module constructors being called at all.
>
> If each LLVM module we generate would be emitted as an object file, this would be easy to resolve: Just emit _minfo_beg/_minfo_end and a constructor calling _d_dso_registry in module-level inline asm.
>
> Still not quite clean on how to get this to work with IR-level linking…

I added an rt.sections_ldc module that is just based on what we had before (i.e. reads the _Dmodule_ref chain). Entirely untested so far, there are probably big issues with it still (it might not even compile on non-Linux systems).

Next step would be to get the DMD testsuite to pass. I'm using a DMD-built d_do_test right now, as I think d_do_test is still miscompiled.

David

Great work, man.
Good luck.

On 2013-06-13 00:08, David Nadlinger wrote:

> If each LLVM module we generate would be emitted as an object file, this
> would be easy to resolve: Just emit _minfo_beg/_minfo_end and a
> constructor calling _d_dso_registry in module-level inline asm.
>
> Still not quite clean on how to get this to work with IR-level linking…

If the bracketing symbols is causing problems what about iterating the segments and sections until you find the section with the module info data?

-- 
/Jacob Carlborg