www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Is LLVM10 still supported?

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
I am trying to build LDC, but get errors like this:

Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a 
type that is unsized!"), function getTypeSizeInBits, file 
/opt/local/libexec/llvm-10/include/llvm/IR/DataLayout.h, line 625.
Oct 20 2020
parent reply kinke <noone nowhere.com> writes:
On Tuesday, 20 October 2020 at 18:13:16 UTC, Ola Fosheim Grøstad 
wrote:

 I am trying to build LDC, but get errors like this:

 Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a 
 type that is unsized!"), function getTypeSizeInBits, file 
 /opt/local/libexec/llvm-10/include/llvm/IR/DataLayout.h, line 
 625.


Sure, LLVM 6.0+ is supported. You're 'just' hitting an LLVM 
assertion here, probably because of an earlier LDC bug. As you 
hit it when building LDC, that's either the host compiler or the 
fresh compiler compiling druntime/Phobos.
Oct 20 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 20 October 2020 at 22:18:37 UTC, kinke wrote:

 Sure, LLVM 6.0+ is supported. You're 'just' hitting an LLVM 
 assertion here, probably because of an earlier LDC bug. As you 
 hit it when building LDC, that's either the host compiler or 
 the fresh compiler compiling druntime/Phobos.


Ok, I tried to build "master" with LLVM10. I didn't get the 
assertion failure when I built with LLVM11.

Whenever I modify some d code and rebuild with ninja, then 
building ldc2.o is somewhat slow. I believe I am building using 
"Debug" target setting. Is there some way to speed this up?
Oct 21 2020
parent reply kinke <noone nowhere.com> writes:
On Wednesday, 21 October 2020 at 07:19:24 UTC, Ola Fosheim 
Grøstad wrote:

 Whenever I modify some d code and rebuild with ninja, then 
 building ldc2.o is somewhat slow.


Yes, by default, the entire frontend is compiled to a single 
object file. Use `-DCOMPILE_D_MODULES_SEPARATELY=ON` in the CMake 
cmdline to compile each module separately 
(https://github.com/ldc-developers/ldc/blob/37a27eb9e558669afe5deacadd5780d5542fdcba/CMakeLists.txt#L142).
Oct 21 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 21 October 2020 at 12:17:01 UTC, kinke wrote:

 On Wednesday, 21 October 2020 at 07:19:24 UTC, Ola Fosheim 
 Grøstad wrote:

 Whenever I modify some d code and rebuild with ninja, then 
 building ldc2.o is somewhat slow.


 Yes, by default, the entire frontend is compiled to a single 
 object file. Use `-DCOMPILE_D_MODULES_SEPARATELY=ON` in the 
 CMake cmdline to compile each module separately 
 (https://github.com/ldc-developers/ldc/blob/37a27eb9e558669afe5deacadd5780d5542fdcba/CMakeLists.txt#L142).


Makes sense. Separate compilation makes more sense for tweaking. 
Thanks!
Oct 21 2020
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 21 October 2020 at 12:17:01 UTC, kinke wrote:

 On Wednesday, 21 October 2020 at 07:19:24 UTC, Ola Fosheim 
 Grøstad wrote:

 Whenever I modify some d code and rebuild with ninja, then 
 building ldc2.o is somewhat slow.


 Yes, by default, the entire frontend is compiled to a single 
 object file. Use `-DCOMPILE_D_MODULES_SEPARATELY=ON` in the 
 CMake cmdline to compile each module separately 
 (https://github.com/ldc-developers/ldc/blob/37a27eb9e558669afe5deacadd5780d5542fdcba/CMakeLists.txt#L142).


Just a question, when forking LDC, is there anything I really 
need to change in order to not cause confusion? I wasn't really 
sure how to deal with the LICENSE, so I rewrote it like this:

https://github.com/OlaFosheimGrostad/dex/blob/master/LICENSE

Please let me know if I should have done it in a different way.
Oct 28 2020
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 21 October 2020 at 12:17:01 UTC, kinke wrote:

 On Wednesday, 21 October 2020 at 07:19:24 UTC, Ola Fosheim 
 Grøstad wrote:

 Whenever I modify some d code and rebuild with ninja, then 
 building ldc2.o is somewhat slow.


 Yes, by default, the entire frontend is compiled to a single 
 object file. Use `-DCOMPILE_D_MODULES_SEPARATELY=ON` in the 
 CMake cmdline to compile each module separately


Hm. When I change dmd's parse.d and do "ninja ldc2" it does not 
detect the change?
Nov 10 2020
parent reply kinke <noone nowhere.com> writes:
On Tuesday, 10 November 2020 at 15:47:21 UTC, Ola Fosheim Grøstad 
wrote:

 Hm. When I change dmd's parse.d and do "ninja ldc2" it does not 
 detect the change?


IIRC, the dmd.parse module is recompiled and ldc2 re-linked. 
Transitive dependencies aren't handled, i.e., other unchanged 
modules importing dmd.parse aren't recompiled.
Nov 10 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 10 November 2020 at 17:18:20 UTC, kinke wrote:

 On Tuesday, 10 November 2020 at 15:47:21 UTC, Ola Fosheim 
 Grøstad wrote:

 Hm. When I change dmd's parse.d and do "ninja ldc2" it does 
 not detect the change?


 IIRC, the dmd.parse module is recompiled and ldc2 re-linked. 
 Transitive dependencies aren't handled, i.e., other unchanged 
 modules importing dmd.parse aren't recompiled.


I can't really make the build scripts work as I would expect them 
to.

For instance, after removing a file and executing "ninja clean":

$ ninja clean ldc2
ninja: error: '…dirpath…/parse_d4.d', needed by 'obj/ldc2.o', 
missing and no known rule to make it
Jan 10 2021
parent reply kinke <noone nowhere.com> writes:
On Sunday, 10 January 2021 at 09:30:13 UTC, Ola Fosheim Grøstad 
wrote:

 For instance, after removing a file and executing "ninja clean":

 $ ninja clean ldc2
 ninja: error: '…dirpath…/parse_d4.d', needed by 'obj/ldc2.o', 
 missing and no known rule to make it


You'll probably have to re-run CMake to have the ninja scripts 
updated, removing the vanished source file. I guess that's the 
price to pay for globbing the source files. - Without a dirty 
source tree, i.e., when git-committing the changes before a 
build, ninja re-runs CMake automatically.
Jan 10 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 10 January 2021 at 12:09:08 UTC, kinke wrote:

 You'll probably have to re-run CMake to have the ninja scripts 
 updated, removing the vanished source file.


Yes, I did, and that worked, of course.


 I guess that's the price to pay for globbing the source files. 
 - Without a dirty source tree, i.e., when git-committing the 
 changes before a build, ninja re-runs CMake automatically.


Hm, I guess I should read a tutorial on Ninja...

A side note, is there any reason for building "mars.d"? LDC has 
its own main. Was a bit confusing... :-)
Jan 10 2021
parent reply kinke <noone nowhere.com> writes:
On Sunday, 10 January 2021 at 12:30:23 UTC, Ola Fosheim Grøstad 
wrote:

 A side note, is there any reason for building "mars.d"? LDC has 
 its own main. Was a bit confusing... :-)


Heh - LDC has its own C main, a D main and a manual cppmain; the 
main program flow is shared with DMD however, so parts of mars.d 
and DMD's main() are re-used.
Jan 10 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 10 January 2021 at 12:47:37 UTC, kinke wrote:

 On Sunday, 10 January 2021 at 12:30:23 UTC, Ola Fosheim Grøstad 
 wrote:

 A side note, is there any reason for building "mars.d"? LDC 
 has its own main. Was a bit confusing... :-)


 Heh - LDC has its own C main, a D main and a manual cppmain; 
 the main program flow is shared with DMD however, so parts of 
 mars.d and DMD's main() are re-used.


Hm... I will consider merging this into one... or are there good 
reasons for keeping this fragmented structure?
Jan 11 2021