• Yuriy (18/18) Mar 24 2014 Hello, I've been looking at LDC sources and it seems a bit weird
• Kai Nacke (18/37) Mar 24 2014 Well, merging the DMD frontend is not the problem. The
• Trass3r (2/2) Apr 24 2014 I wonder what the planned move to D for the frontend will mean
• David Nadlinger via digitalmars-d-ldc (8/10) Apr 24 2014 The shift towards the visitor interface for accessing the AST was
• Trass3r (1/1) Apr 24 2014 Good to hear :)
• Trass3r (4/8) Apr 27 2014 Tested the x64 MSVC combination and the 2.065 branch crashes when
• Kai Nacke (6/14) Apr 28 2014 Yes, I build with assertions enabled. Which assertions do you
• Trass3r (2/4) Apr 29 2014 Trunk llvm, VS2013.
• Trass3r (24/28) Apr 30 2014 Ok 2.064 branch, latest llvm.
• Kai Nacke (6/35) May 04 2014 I do not get assertions errors. I use VS2012. But my LLVM tree is
• Trass3r (24/24) May 06 2014 Tried again with default compiler options but same result for
• Kai Nacke (22/30) May 06 2014 Now I can trigger the second assertion failure. Seems to have
• Trass3r (24/35) May 07 2014 Yeah in debug mode only the second one triggers (which was indeed
• Trass3r (15/17) May 08 2014 with /d2Zi+ the stack trace is better:

"Yuriy" <yuriy.glukhov gmail.com> writes:

Hello, I've been looking at LDC sources and it seems a bit weird 
to me, that DMD is not used as a submodule. If LDC aims to 
provide LLVM generation, using original DMD as a frontend, it 
will get hard to maintain merges from original DMD over time. And 
it seems to me, that it is already, as DMD is not up-to-date 
there. E.g. while DMD factored out toIR and toElem to visitors, 
LDC still uses old design.

If i'm right and such problem exists, what do you think of the 
following plan to fix this:
1. Create a DMD fork. Create an ldc-dmd branch in it, and replace 
it's contents with current DMD state in LDC.
2. Start using DMD fork with it's ldc-branch in LDC repo as a 
submodule.
3. Gradually refactor LDC and ldc-dmd branch with the goal to 
completely eliminate differences between ldc-dmd branch and DMD 
fork master.
4. Repeat step 3, until complete =)
5. Switch submodule to DMD fork master, and close dmd-ldc branch.

"Kai Nacke" <kai redstar.de> writes:

Hi Yuriy!

On Monday, 24 March 2014 at 09:51:34 UTC, Yuriy wrote:
 Hello, I've been looking at LDC sources and it seems a bit 
 weird to me, that DMD is not used as a submodule. If LDC aims 
 to provide LLVM generation, using original DMD as a frontend, 
 it will get hard to maintain merges from original DMD over 
 time. And it seems to me, that it is already, as DMD is not 
 up-to-date there. E.g. while DMD factored out toIR and toElem 
 to visitors, LDC still uses old design.

 If i'm right and such problem exists, what do you think of the 
 following plan to fix this:
 1. Create a DMD fork. Create an ldc-dmd branch in it, and 
 replace it's contents with current DMD state in LDC.
 2. Start using DMD fork with it's ldc-branch in LDC repo as a 
 submodule.
 3. Gradually refactor LDC and ldc-dmd branch with the goal to 
 completely eliminate differences between ldc-dmd branch and DMD 
 fork master.
 4. Repeat step 3, until complete =)
 5. Switch submodule to DMD fork master, and close dmd-ldc 
 branch.

Well, merging the DMD frontend is not the problem. The 
merge-2.064 and merge-2.065 contains the merge of the last 2 DMD 
releases. (The latter one contains the refactoring using visitor 
pattern.)
In fact, I have a MSBUILD script to do the merge - I only have to 
resolve conflicts, which is usually simple.

The real problem is that a change in the frontend must be handled 
in the glue layer between frontend AST and LLVM IR. This must 
always be done manually.

E.g.: there is only 1 test failure left in the merge-2.064 
branch: a missing symbol in std.uni unittest. The merge-2.065 
branch has some more problems in phobos unit tests - because I 
did not fixed the changes.

Any help here is appreciated.

Regards,
Kai

"Trass3r" <un known.com> writes:

I wonder what the planned move to D for the frontend will mean 
for ldc/gdc's future.

David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:

On 24/04/14 21:27, Trass3r via digitalmars-d-ldc wrote:
 I wonder what the planned move to D for the frontend will mean for
 ldc/gdc's future.

The shift towards the visitor interface for accessing the AST was 
primarily motivated by the need to be able to keep the codegen layer in 
C++ even if the frontend is switched to D. We extensively discussed this 
at the last DConf, and the impact of the switch on both GDC and LDC will 
be reasonably small.

Best,
David

"Trass3r" <un known.com> writes:

Good to hear :)

"Trass3r" <un known.com> writes:

 E.g.: there is only 1 test failure left in the merge-2.064 
 branch: a missing symbol in std.uni unittest. The merge-2.065 
 branch has some more problems in phobos unit tests - because I 
 did not fixed the changes.

Tested the x64 MSVC combination and the 2.065 branch crashes when 
building the runtime. 2.064 has less problems but now I enabled 
llvm assertions and it hits 2 of them. Do you build with 
assertions?

"Kai Nacke" <kai redstar.de> writes:

Hi Trass3r!

On Sunday, 27 April 2014 at 16:25:05 UTC, Trass3r wrote:
 E.g.: there is only 1 test failure left in the merge-2.064 
 branch: a missing symbol in std.uni unittest. The merge-2.065 
 branch has some more problems in phobos unit tests - because I 
 did not fixed the changes.

 Tested the x64 MSVC combination and the 2.065 branch crashes 
 when building the runtime. 2.064 has less problems but now I 
 enabled llvm assertions and it hits 2 of them. Do you build 
 with assertions?

Yes, I build with assertions enabled. Which assertions do you 
hit? And which LLVM version do you use?

Regards,
Kai

"Trass3r" <un known.com> writes:

 Yes, I build with assertions enabled. Which assertions do you 
 hit? And which LLVM version do you use?

Trunk llvm, VS2013.
Need to look up the messages tomorrow.

"Trass3r" <un known.com> writes:

On Tuesday, 29 April 2014 at 18:26:44 UTC, Trass3r wrote:
 Yes, I build with assertions enabled. Which assertions do you 
 hit? And which LLVM version do you use?

 Trunk llvm, VS2013.
 Need to look up the messages tomorrow.

Ok 2.064 branch, latest llvm.

3>------ Build started: Project: druntime-ldc, Configuration: 
RelWithDebInfo x64 ------
4>------ Build started: Project: druntime-ldc-debug, 
Configuration: RelWithDebInfo x64 ------
4>  Generating src/core/atomic-debug.obj
3>  Generating src/core/atomic.obj
4>  Assertion failed: List && "Handle list is null?", file 
..\..\..\lib\IR\Value.cpp, line 528
3>  Assertion failed: List && "Handle list is null?", file 
..\..\..\lib\IR\Value.cpp, line 528
5>------ Build started: Project: phobos-ldc, Configuration: 
RelWithDebInfo x64 ------
5>  Generating std/algorithm.obj
6>------ Build started: Project: phobos-ldc-debug, Configuration: 
RelWithDebInfo x64 ------
6>  Generating std/algorithm-debug.obj
5>  Assertion failed: (!F || F->getParent() == &M) && "Function 
not in current module!", file 
..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 149
6>  Assertion failed: (!F || F->getParent() == &M) && "Function 
not in current module!", file 
..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 149

"Kai Nacke" <kai redstar.de> writes:

On Wednesday, 30 April 2014 at 10:10:39 UTC, Trass3r wrote:
 On Tuesday, 29 April 2014 at 18:26:44 UTC, Trass3r wrote:
 Yes, I build with assertions enabled. Which assertions do you 
 hit? And which LLVM version do you use?

 Trunk llvm, VS2013.
 Need to look up the messages tomorrow.

 Ok 2.064 branch, latest llvm.

 3>------ Build started: Project: druntime-ldc, Configuration: 
 RelWithDebInfo x64 ------
 4>------ Build started: Project: druntime-ldc-debug, 
 Configuration: RelWithDebInfo x64 ------
 4>  Generating src/core/atomic-debug.obj
 3>  Generating src/core/atomic.obj
 4>  Assertion failed: List && "Handle list is null?", file 
 ..\..\..\lib\IR\Value.cpp, line 528
 3>  Assertion failed: List && "Handle list is null?", file 
 ..\..\..\lib\IR\Value.cpp, line 528
 5>------ Build started: Project: phobos-ldc, Configuration: 
 RelWithDebInfo x64 ------
 5>  Generating std/algorithm.obj
 6>------ Build started: Project: phobos-ldc-debug, 
 Configuration: RelWithDebInfo x64 ------
 6>  Generating std/algorithm-debug.obj
 5>  Assertion failed: (!F || F->getParent() == &M) && "Function 
 not in current module!", file 
 ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 149
 6>  Assertion failed: (!F || F->getParent() == &M) && "Function 
 not in current module!", file 
 ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 149

I do not get assertions errors. I use VS2012. But my LLVM tree is 
more than a week old. I currently build LLVM. Maybe it is 
something new...

Regards,
Kai

"Trass3r" <un known.com> writes:

Tried again with default compiler options but same result for 
tested Release and ReleaseWithDebInfo configs.

cmake.exe -G "Visual Studio 12 Win64" 
-DCMAKE_INSTALL_PREFIX=.../llvm/installed 
-DLLVM_TARGETS_TO_BUILD=X86
-DLLVM_BUILD_TOOLS=OFF -DLLVM_INCLUDE_TESTS=OFF 
-DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_APPEND_VC_REV=ON 
-DCMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO="/DEBUG /INCREMENTAL:NO 
/OPT:REF /OPT:ICF" 
-DCMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO="/DEBUG 
/INCREMENTAL:NO /OPT:REF /OPT:ICF" ..

cmake.exe -G "Visual Studio 12 Win64" 
-DCMAKE_INSTALL_PREFIX=.../ldc -DLLVM_ROOT_DIR=.../llvm/installed 
-DLIBCONFIG++_INCLUDE_DIR=../libconfig-1.4.9/lib 
-DLIBCONFIG++_LIBRARY="../libconfig-1.4.9/x64/Release/libconfig++.lib" 
..

Generating src/core/atomic.obj
Assertion failed: List && "Handle list is null?", file 
..\..\..\lib\IR\Value.cpp, line 528
Generating std/algorithm-debug.obj
Assertion failed: !N->getContext().pImpl->MDNodeSet.RemoveNode(N) 
&& "Deleting a non-temporary uniqued node!", file 
..\..\..\lib\IR\Metadata.cpp, line 296

"Kai Nacke" <kai redstar.de> writes:

Hi Trass3r!

On Tuesday, 6 May 2014 at 12:35:17 UTC, Trass3r wrote:
 Generating src/core/atomic.obj
 Assertion failed: List && "Handle list is null?", file 
 ..\..\..\lib\IR\Value.cpp, line 528
 Generating std/algorithm-debug.obj
 Assertion failed: 
 !N->getContext().pImpl->MDNodeSet.RemoveNode(N) && "Deleting a 
 non-temporary uniqued node!", file 
 ..\..\..\lib\IR\Metadata.cpp, line 296

Now I can trigger the second assertion failure. Seems to have 
something to do with recent changes in debug symbol generation.

My configuration is:
cmake -G "Visual Studio 11 Win64" 
-DCMAKE_INSTALL_PREFIX="D:/Program Files/LLVM-x64" 
-DCMAKE_BUILD_TYPE=Debug -DPYTHON_EXECUTABLE="C:/Program 
Files/Python/Python33/python.exe" 
-DLLVM_TARGETS_TO_BUILD="X86;ARM;PowerPC;Mips;Sparc;CppBackend" 
-DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_BUILD_TESTS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF 
-DLLVM_ENABLE_ZLIB=OFF D:/OpenSource/LLVM/LLVM-git


cmake -G "Visual Studio 11 Win64" 
-DCMAKE_INSTALL_PREFIX="D:\Program Files\LDC" 
-DCMAKE_BUILD_TYPE=Debug -DLLVM_ROOT_DIR="D:/Program 
Files/LLVM-x64" 
-DLIBCONFIG++_INCLUDE_DIR="D:/OpenSource/libconfig-1.4.9/lib" 
-DLIBCONFIG++_LIBRARY="D:/OpenSource/libconfig-1.4.9/x64/Debug/libconfig++.lib" 
..\ldc

Regards,
Kai

"Trass3r" <un known.com> writes:

On Wednesday, 7 May 2014 at 05:18:12 UTC, Kai Nacke wrote:
 Now I can trigger the second assertion failure. Seems to have 
 something to do with recent changes in debug symbol generation.

 My configuration is:
 cmake -G "Visual Studio 11 Win64" 
 -DCMAKE_INSTALL_PREFIX="D:/Program Files/LLVM-x64" 
 -DCMAKE_BUILD_TYPE=Debug

Yeah in debug mode only the second one triggers (which was indeed 
introduced recently). In release mode I get the other assertion:

	ldc2.exe!llvm::ValueHandleBase::AddToExistingUseList(llvm::ValueHandleBase 
* * List=0x00000000001ff440) Line 531	C++

  	ldc2.exe!llvm::scc_iterator<llvm::CallGraph * 
__ptr64,llvm::GraphTraits<llvm::CallGraph * __ptr64> 
::DFSVisitChildren() Line 158	C++

  	ldc2.exe!llvm::scc_iterator<llvm::CallGraph * 
__ptr64,llvm::GraphTraits<llvm::CallGraph * __ptr64> 
::GetNextSCC() Line 179	C++

  	ldc2.exe!llvm::scc_begin<llvm::CallGraph * 
__ptr64>(llvm::CallGraph * const & G=0x00000000024f7e70) Line 
225	C++
  	ldc2.exe!`anonymous 
namespace'::CGPassManager::runOnModule(llvm::Module & M={...}) 
Line 434	C++
  	ldc2.exe!`anonymous 
namespace'::MPPassManager::runOnModule(llvm::Module & M={...}) 
Line 1625	C++
  	ldc2.exe!llvm::legacy::PassManagerImpl::run(llvm::Module & 
M={...}) Line 1734	C++
  	ldc2.exe!ldc_optimize_module(llvm::Module * 
M=0x0000000000000023) Line 400	C++
  	ldc2.exe!writeModule(llvm::Module * m=0x0000000000000000, 
std::basic_string<char,std::char_traits<char>,std::allocator<char> 
 filename={...}) Line 133	C++

  	ldc2.exe!main(int argc=0, char * * argv=0x0000000000000000) 
Line 1279	C++

"Trass3r" <un known.com> writes:

with /d2Zi+ the stack trace is better:

llvm::ValueHandleBase::AddToExistingUseList(llvm::ValueHandleBase** 
List=0) Line 531
llvm::scc_iterator<llvm::CallGraph*,llvm::GraphTraits<llvm::CallGraph*> 
::DFSVisitChildren() Line 158

llvm::scc_iterator<llvm::CallGraph*,llvm::GraphTraits<llvm::CallGraph*> 
::GetNextSCC() Line 179

`anonymous namespace'::CGPassManager::runOnModule(llvm::Module & 
M=<struct at NULL>) Line 434
`anonymous namespace'::MPPassManager::runOnModule(llvm::Module & 
M={...}) Line 1625
llvm::legacy::PassManagerImpl::run(llvm::Module & M={...}) Line 
1734
ldc_optimize_module(llvm::Module* M=0x00000000024a6d20) Line 400

But it still makes no sense. In MPPassManager::runOnModule M 
looks fine and then in CGPassManager::runOnModule it's allegedly 
null.