Double support

[pjaaskel]

Created a dummy pull request, just to have a place to add misc comments to.

[pjaaskel]

This file requires +x.

[rhinton]

Got it, see commit 10006c6.

[pjaaskel]

There's also some breakage in the old 'float'-tests in the systemtest. Not sure if it's due to my patch that's applied locally (which also affects f32) or your branch. Did you run compiletest.sh with your branch?

[rhinton]

I'm trying to run the system tests, but having trouble. What directory should I be in when I execute compiletest.sh? From compiletest.sh:326 and forward it looks like I should either be in the root or in the testsuite subdirectory. Running the script from the testsuite subdirectory I get a quick error on stdout. Running from the root I get errors about not finding tce/tools/scripts/systemtest.py -- but I can see the file is there.

[pjaaskel]

From root. Note that it doesn't work if you build out of the source tree. You should launch it in the directory where configure.ac is located:

tools/scripts/compiletest.sh -c

[rhinton]

OK, I ran from root

tce/tools/scripts/compiletest.sh -q -c

and got

   $ tce/tools/scripts/compiletest.sh -q -c
    Temp: /tmp/compiletest.tce.7qBMdRM
   touch: cannot touch 'systemtest_longlong/bintools/Compiler/denbench_verification.testdesc.disabled': No such file or directory
   -------------------------------------------------------------------------------
   Current environment (no env files used).
   -------------------------------------------------------------------------------
   Current revision of tce:tce is be5a08caddb11e113cdb8dafaf774552726b0798.
   compile: OK. (11s)
   unit tests: OK. (2m17s)
   sys tests: tce/tools/scripts/compiletest.sh: line 592: cd: systemtest: No such file or directory
   PROBLEMS.FAILED! (0s)
   Errors were found during testing.

The log compalins about not being able to find ../../tce/tools/scripts/systemtest.py (again, this is from compiletest.sh line 594). The file appears to be there and it's marked executable. Suggestions are welcome; I'll come back to this when I can.

[pjaaskel]

compiletest.sh should create symlinks to systemtest* dirs under testsuite to the tce root dir. Maybe that part is broken somehow.

[rhinton]

I can see those symlinks. But the file has two sets of ..s, so maybe the script needs to be changed if it's really only one directory deep.

[pjaaskel]

It doesn't work because ../ under a symlink dir means the parent of the symlinked dir not the symlink location. Confusing enough? :)

[rhinton]

Quite, thank you. :-) Confusing enough that I'm still not sure how to fix it. (I'm not a *NIX newbie, but I kind of feel like one in this context.)

[pjaaskel]

The strange part is why it works here and has worked for ~10-13y but not there?

[rhinton]

Any suggestions how to debug a terminate called after throwing an instance of 'CompileError'? I've pared down my doubles.cc test suite to just the first line in main(). The emitted LLVM IR has calls to @llvm.lifetime.start where the first argument is an i64. I don't see any other i64 functions (or bitcasts) now. There are lots of fmul, fsub, and fcmp instructions. Any easy way to see how these are being lowered?

[pjaaskel]

Does it print anything else than the exception name? If not, you can try hooking llvm-tce to gdb and add breakpoint to the CompileError exception's constructor to see where it's built. The lifetime markers are harmless. If you want to look at the final TTA code, just produce the tpef and use 'tcedisasm' to disassemble it to text.

[rhinton]

No, it doesn't print anything but the exception name. Great suggestion to run llvm-tce in gdb. I can't disassemble the tpef because it fails before it is produced. :-)

[rhinton]

That found it. The error is at llvm::LLVMTCEIRBuilder::buildTCECFG (this=this@entry=0x80d4100, mf=...) at LLVMTCEIRBuilder.cc:313. Here is the stack at the error point.

#0  CompileError::CompileError (this=0x820f850, filename=..., linenum=313, procname=..., errorMessage=...) at Exception.cc:1458
#1  0xb53e0e3a in llvm::LLVMTCEIRBuilder::buildTCECFG (this=this@entry=0x80d4100, mf=...) at LLVMTCEIRBuilder.cc:313
#2  0xb53e39bf in llvm::LLVMTCEIRBuilder::writeMachineFunction (this=0x80d4100, mf=...) at LLVMTCEIRBuilder.cc:173
#3  0xb53c3977 in llvm::LLVMTCEBuilder::runOnMachineFunction (this=0x80d4100, mf=...) at LLVMTCEBuilder.cc:871
#4  0xb619137f in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /usr/local/lib/libLLVM-3.7.1.so
#5  0x0809f5a4 in ?? ()

I made a mistake using lwpr_print_str. So first, we should add a catch in this call tree somewhere to print the error information instead of having to fire up gdb. Where is the best spot?

Also, I had to add an extern "C" around the lwpr include to get it to work. It would be nice to add this to the documentation on using LWPR ("How to print from Altera" chapter).

[pjaaskel]

Yes, the extern "C" should be added in the lwpr header. We haven't encountered this issue because we rarely compile in C++ mode. The catch belongs to llvm-tce main program. It's not going down there probably because of too tight throws-declarations.

[rhinton]

I can't find any too-restrictive "throws" declarations. Here is the stack I can see from within GDB:

    (gdb) where
    #0  CompileError::CompileError (this=0x8181970, filename=..., linenum=313, procname=..., errorMessage=...) at Exception.cc:1463
    #1  0xb53e0e3a in llvm::LLVMTCEIRBuilder::buildTCECFG (this=this@entry=0x80d59d0, mf=...) at LLVMTCEIRBuilder.cc:313
    #2  0xb53e39bf in llvm::LLVMTCEIRBuilder::writeMachineFunction (this=0x80d59d0, mf=...) at LLVMTCEIRBuilder.cc:173
    #3  0xb53c3977 in llvm::LLVMTCEBuilder::runOnMachineFunction (this=0x80d59d0, mf=...) at LLVMTCEBuilder.cc:871
    #4  0xb619137f in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from /usr/local/lib/libLLVM-3.7.1.so
    #5  0x0812587c in ?? ()
    Backtrace stopped: previous frame inner to this frame (corrupt stack?)

For now I'm going to catch it in the TCE code before it gets lost back in the LLVM code.

[pjaaskel]

That's all in TCE code. The llvm namespace is confusing. Thus the interesting site is 1.

[rhinton]

Right, the first 4 lines are in TCE code. But I believe line 4+ are in LLVM code. Then the outer code (application-level and a few layers below) are TCE code again. My best guess is that the exception is getting lost/confused/improperly filtered in the LLVM code somewhere, so it never makes it back to the handler at the TCE application level.

I did some greps on the LLVM and TCE code, and I couldn't find any "throws" restrictions in the code path that I'm aware of. But I know little of the code path inside LLVM, so I'll just echo here the command I used in case someone who knows that path can take a look.

(in LLVM base directory, just to be safe -- tools is a subdirectory)
$ find . -name "*.h*" -exec grep -Hs throw {} \;

For debug purposes I've added a handler in the function on line 3 for the moment.

[pjaaskel]

Yes, 4 is an LLVM function. I remember there has been a similar issue of not being able to pass the exception through LLVM layers (maybe due to missing RTTI/exception support in libLLVM or another reason). Actually, if you look at the comment in LLVMTCEIRBuilder::doFinalization():

  // Catch the exception here as throwing exceptions
  // through library boundaries is flaky. It crashes
  // on x86-32 Linux at least See:
  // https://bugs.launchpad.net/tce/+bug/894816
 EXIT_IF_THROWS(LLVMTCEBuilder::doFinalization(m));
 EXIT_IF_THROWS(prog_->convertSymbolRefsToInsRefs());

So it's better to surround the buildTCECFG() call also with EXIT_IF_THROWS to avoid the issue.

[rhinton]

I put that macro around the buildTCECFG call and it works as expected.