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