llvm dev - Jun 2005 - [LLVMdev] Cygwin 'make check' results

>Okay, this is looking much better. I'll commit the configure script.
Great, that did the job.
>There's a couple of CFrontEnd failures. Possibly you're not working
with
>the latest llvm-gcc? (built from CVS?)
checkout today about 16:00 GMT
>The others are known JIT failures on Cygwin .. it can't load symbols
>from the LLI executable. We don't have a fix for this (yet).
Please explain.
>So, I'd say we're good to go :)
Just about I'll do the release build tommorow.

Aaron

After a make clean on test we are getting :-

# of expected passes            1766
# of unexpected failures        12
# of expected failures          55

Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050603/ab431a62/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: makecheck.txt
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050603/ab431a62/attachment.txt>

Okay, those 12 unexpected failures fall into three categories:

1. Math failures. things like "unordered" are not being found in
math.h
   So either Cygwin doesn't support such FP functions or it has them in
   some other header file that we need. Also, one of the tests fails
   because "complex.h" is not found. Again, this is probalby just a
   Cygwin deficiency that we can't do anything about.

2. The LLI test failures occur because the dlsym function on cygwin can
   only find symbols in a loaded DLL. If the symbol is in the .EXE file
   then the symbol doesn't get found. Since LLI links in things like
   printf, strcat, and some other fundamental functions, they don't get
   found on Cygwin. A similar thing happens on MacOS but for a much
   smaller set of files for which we hand code a workaround. The set
   of functions on Cygwin is basically a large fraction of glibc, too
   much to do by hand. 

3. You have another permission problem in your make check output 
   directories. Not sure how this happens, but if you're on windows,
   its probably a sharing violation. Are you running two of these
   make check's at the same time?

All in all, I don't think any of this is hugely significant except #2
which thwarts LLI and JIT on Cygwin. We don't have a workaround for
this, its just a deficiency of Cygwin. The only thing we *could* do is
build a huge table of every symbol that LLI links statically and scan
that table whenever a symbol is looked up. This adds significant
overhead for dynamically linking symbols at runtime in the JIT. I think
the better thing to do is wait for a new JIT engine that compiles
everything to ELF files statically off line and loads them as necessary.
Alexander Friedman and I are working on that kind of an approach for our
runtimes.

Reid.

On Fri, 2005-06-03 at 00:31 +0100, Aaron Gray wrote:
> After a make clean on test we are getting :-
>  
> # of expected passes            1766
> # of unexpected failures        12
> # of expected failures          55
> 
> Aaron 
>  
>  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050602/8db6344e/attachment.sig>