2.4 Pre-release (v1) Available for Testing

Project Infrastructure LLVM Dev List Archives
1

LLVMers,

The 2.4 pre-release is available for testing:
http://llvm.org/prereleases/2.4/

If you have time, I'd appreciate anyone who can help test the release. Please do the following:

1) Download/compile llvm source, and either compile llvm-gcc source or use
    llvm-gcc binary.
2) Run make check, send me the testrun.log
3) Run "make TEST=nightly report" and send me the report.nightly.txt
4) Please provide details on what platform you compiled LLVM on and how
    you built LLMV (src == obj, or src != obj)

Please COMPLETE ALL TESTING BY the end of the day on Oct. 19th!

Thanks,
Tanya

2

LLVMers,

The 2.4 pre-release is available for testing:
http://llvm.org/prereleases/2.4/

If you have time, I'd appreciate anyone who can help test the release.
Please do the following:

1) Download/compile llvm source, and either compile llvm-gcc source or use
   llvm-gcc binary.
2) Run make check, send me the testrun.log
3) Run "make TEST=nightly report" and send me the report.nightly.txt
4) Please provide details on what platform you compiled LLVM on and how
   you built LLMV (src == obj, or src != obj)

Downloaded the 2.4pr source code.
Compiling on Windows XP SP2 using Visual Studio 2005/VC8 with current patches.

Initial notice while it is compiling, lots of warning that look valid, such as:
1) "The POSIX name for this item is deprecated. Instead, use the ISO
C++ conformant name: someFuncName"
2) "...not all control paths return a value"
3) "type name first seen using 'class' now seen using 'struct'"
4) Lots of conversion/truncation warning, this one does not need to be
a big focus, but explicit conversion/truncations would silence these
and make the compiler happy.
5) "destructor could not be generated because a base class destructor
is inaccessible"
6) " check operator precedence for possible error; use parentheses to
clarify precedence"
7) "switch statement contains 'default' but no 'case' labels"
8) etc...
9) And of course a few VC++ specific ones that can be ignored, but the
above are valid.

The full build log is at:
http://overminddl1.com/stuff/llvm/First_Full_Build.txt
On this first compile everything compiled except for llc and lli,
which did not link due to:
unresolved external symbol "class llvm::FunctionPass * __cdecl
llvm::createPBQPRegisterAllocator(void)"

I told it to compile again (hopefully just missed a link due to a bad
project build order I hope, from looking at it though that does not
appear to be the case, it looks like that symbol is not externally
visible...).
Second attempt to link the llc and lli projects again also failed,
some error, looks like that symbol needs to be fixed.

Other then the one link error due to the missing external symbol, the
windows build seems to build. Fibonacci also works fine (tested both
the debug and release builds with numbers from 1 to 45 each, I assume
the results are the correct numbers, did not check, it all looked fine
though). Lots of warnings, most of which look like they can be safely
ignored, a few should be handled. Are there any Windows tests you
want run?

3

OvermindDL1 <overminddl1@gmail.com> writes:

[snip]

On this first compile everything compiled except for llc and lli,
which did not link due to:
unresolved external symbol "class llvm::FunctionPass * __cdecl
llvm::createPBQPRegisterAllocator(void)"

That is because the lib/CodeGen project file is missing PBQP.cpp.

[snip]

Please COMPLETE ALL TESTING BY the end of the day on Oct. 19th!

Speaking of, we really need a test suite to test llvm itself, and not
llvm-gcc (to make sure llvm is correct on platforms without a gcc
build system). The closest we have is the Fibinocci project and that
is anything but conclusive.

I could add that to my CMake build system TODO, but so far I'm a bit
skeptic about LLVM relevance on the non-Unix world. The Windows build
can be broken for a long period before anyone notices. The VS2003
support is broken since a long time ago and, apart from myself, no other
user cares. Seems that LLVM penetration on Windows, for instance, is
almost nil. Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.

4

Hi Oscar,

I could add that to my CMake build system TODO, but so far I'm a bit
skeptic about LLVM relevance on the non-Unix world. The Windows build
can be broken for a long period before anyone notices. The VS2003
support is broken since a long time ago and, apart from myself, no other
user cares. Seems that LLVM penetration on Windows, for instance, is
almost nil. Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.

Just to add one voice, we're going to be heavily using LLVM on Windows soon. I was very happy to see your CMake work since we were planning on doing something similar once we were going to be building on Windows regularly, and would really like a consistent build system across Linux/OS X/Windows.

Once we get there we'll be happy to pitch in with an effort like this. If you come up with something, we may be able to set up some nightly test machines in the short term for various versions of Windows and compilers. Email me privately if you're interested.

Stefanus

5

With respect to random testing LLVM pre-2.4 is doing extremely well, we have no unreported bugs right now.

John

6

Óscar Fuentes wrote:

OvermindDL1 <overminddl1@gmail.com> writes:

Please COMPLETE ALL TESTING BY the end of the day on Oct. 19th!
      

Speaking of, we really need a test suite to test llvm itself, and not
llvm-gcc (to make sure llvm is correct on platforms without a gcc
build system). The closest we have is the Fibinocci project and that
is anything but conclusive.
    
I could add that to my CMake build system TODO, but so far I'm a bit
skeptic about LLVM relevance on the non-Unix world.

LLVM will be mostly irrelevant on Windows as long as it doesn't have either a native-enough testing framework on Windows, or a build process that chokes on canonical Windows tools. [Specifically, Perl. I get the same errors with unpatched LLVM sources with both ActiveState, and built-from-tarball Perl 5.8.8 . I'd guess the root problem is that canonical Windows builds of Perl use cmd rather than sh for the command shell.]

.... Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.
  

Assuming that the absence of testing is a sufficient cause for not wanting to use LLVM on that system, and the system is otherwise worth supporting: yes.

Kenneth

7

I could add that to my CMake build system TODO, but so far I'm a bit
skeptic about LLVM relevance on the non-Unix world. The Windows build
can be broken for a long period before anyone notices. The VS2003
support is broken since a long time ago and, apart from myself, no
other
user cares. Seems that LLVM penetration on Windows, for instance, is
almost nil. Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.

--
Oscar

I, for one, hugely appreciate your effort and the CMake build files. My
primary target is the Windows platform, and I'd *LOVE* to see LLVM working
on windows. I think this is a "build it and they will come" argument, but
LLVM is hugely useful for the kind of work I'm doing, and ATM I'm resorting
to using LLVM on a *nix system while preparing (hoping?) for a win32 build
to work. The near nil penetration is a side effect of the lack of
availability IMO: How can I use it when it's not working in the first
place?..

I'd be willing to help test and, if I'm at a point where I actually know
what I'm doing ;), possibly contribute to make The Fully Working LLVM Win32
Build a reality.

- Sherief

8

I could add that to my CMake build system TODO, but so far I'm a bit
skeptic about LLVM relevance on the non-Unix world. The Windows build
can be broken for a long period before anyone notices. The VS2003
support is broken since a long time ago and, apart from myself, no
other
user cares. Seems that LLVM penetration on Windows, for instance, is
almost nil. Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.

--
Oscar

I, for one, hugely appreciate your effort and the CMake build files. My
primary target is the Windows platform, and I'd *LOVE* to see LLVM
working
on windows. I think this is a "build it and they will come" argument,
but
LLVM is hugely useful for the kind of work I'm doing, and ATM I'm
resorting
to using LLVM on a *nix system while preparing (hoping?) for a win32
build
to work. The near nil penetration is a side effect of the lack of
availability IMO: How can I use it when it's not working in the first
place?..

I'd be willing to help test and, if I'm at a point where I actually know
what I'm doing ;), possibly contribute to make The Fully Working LLVM
Win32
Build a reality.

- Sherief

I have a working VS2K5 solution/proj file that builds everything
correctly I could pass on if anyone is interested.

9

Stefanus Du Toit wrote:
>>Just to add one voice, we're going to be heavily using LLVM on Windows soon

Add me to; I target/use Linux and Windows.

-srs

10

That's great John!

For my info, are there any reported bugs that are unfixed in 2.4?

-Chris

11

Can someone on windows please submit a patch?

Thanks,

-Chris

12

That is because the lib/CodeGen project file is missing PBQP.cpp.

That did not help, that cpp and its header do not contain
createPBQPRegisterAllocator anywhere in them. it was still missing
those files in the project though. What did fix it was adding in
RegAllocPBQP.cpp, so that file, and the PBQP.cpp/.h need to be added
to the VS project.

I could add that to my CMake build system TODO, but so far I'm a bit
skeptic about LLVM relevance on the non-Unix world. The Windows build
can be broken for a long period before anyone notices. The VS2003
support is broken since a long time ago and, apart from myself, no other
user cares. Seems that LLVM penetration on Windows, for instance, is
almost nil. Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.

Well I use it, and I know of three other windows LLVM users that have
contacted me for help with their own projects as well. The VC2k3
support is broken because of a "friend" declaration in LLVM in a way
that VS2k3 does not support (2k3's fault, although the friend usage
was also questionable...).

Although I think the main lack of visible Windows users (there are
definitely Windows llvm users) is because llvm feels so gcc oriented,
rather then being a truly open code generator (I mean come on, you try
to put in exception information even and it generates calls to the gcc
crt, it should *NOT* be doing that if it wants to be a truly platform
agnostic generator, and that is just one example among many).

Once we get there we'll be happy to pitch in with an effort like this.
If you come up with something, we may be able to set up some nightly
test machines in the short term for various versions of Windows and
compilers. Email me privately if you're interested.

If someone created some multi-platform (aka, not relying on gcc)
tests, I could donate a nightly test on windows as well. Perhaps if
such tests were setup it would be best to use a testing framework like
boost::test (or whatever it was called) to test all kinds of features
and such of llvm that would be compiled and ran as an executable on
whatever platform, all without relying on any compiler like gcc or
vc++ (the boost's version seems to work perfectly well everywhere, I
have used it a few times and have nothing but praise for it). For
testing the tools like lli and so forth then another C/C++ project
with llvm could build an application that calls those and runs tests
on them by calling with various arguments and seeing the responses and
so forth (boost::filesystem makes hiding all the multi-platform junk
of that easy sans the actual calling of the executable, but that can
easily be controlled by a macro in small segments). Technically you
would not even need to test those external llvm apps as everything can
be tested in the direct code path itself when testing everything else
internally (as those apps just call the internal things anyway).

LLVM will be mostly irrelevant on Windows as long as it doesn't have
either a native-enough testing framework on Windows, or a build process
that chokes on canonical Windows tools. [Specifically, Perl. I get the
same errors with unpatched LLVM sources with both ActiveState, and
built-from-tarball Perl 5.8.8 . I'd guess the root problem is that
canonical Windows builds of Perl use cmd rather than sh for the command
shell.]

.... Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.

Assuming that the absence of testing is a sufficient cause for not
wanting to use LLVM on that system, and the system is otherwise worth
supporting: yes.

Kenneth

I still do not see why all the tests revolve around llvm-gcc. They
are not really testing llvm, they are testing llvm-gcc. We need a
good testing framework built in c++ itself, that can be built by the
same compiler that builds llvm itself, which can then be run to do all
the tests and return a result back, perhaps even with a network
library like boosts to submit results to the website, it can all be
done in c++ quite easily and would work everywhere just fine, and yet
people feel the need to write all this external stuff. Yes, we need
the external stuff to test llvm-gcc, but on platforms where there is
no llvm-gcc there needs to be a testing framework to fully test llvm
itself, in all ways, but fully through its api, not something else
like llvm-gcc.

That is because the lib/CodeGen project file is missing PBQP.cpp.

Can someone on windows please submit a patch?

That was not the only missing file (there were three missing). I can
send you my project file if you so wish, just added the three files to
the codegen project file, nothing special (it is simple xml, you can
copy/paste three new entries in that file yourself actually). If you
want my project file, or a diff to the 2.4pr then just ask.

Actually, here, just add this into the rather obvious area in belongs
in, does not matter where in the section, just stick it with the rest
of the file xml nodes in the CodeGen.vcproj file. No clue if anything
else is missing, but it all builds fine with these:
These two go in the Name="Source Files" section, search for Name="Source Files"
      <File
        RelativePath="..\..\lib\CodeGen\PBQP.cpp"
        >
      </File>
      <File
        RelativePath="..\..\lib\CodeGen\RegAllocPBQP.cpp"
        >
      </File>
And this goes in the Name="Header Files" section as a child node,
again, just search for Name="Header Files"
      <File
        RelativePath="..\..\lib\CodeGen\PBQP.h"
        >
      </File>

Actually, here is a unified diff too (for the CodeGen.vcproj that
comes with the 2.4 pr1), as stated though, who knows if it is missing
other files, but right now with these it builds. If anyone needs me
to test the windows build just yell out on the list and I'll sync the
source and do a build and return the results to the list.
@@ -425,6 +425,10 @@
         >
       </File>
       <File
+ RelativePath="..\..\lib\CodeGen\PBQP.cpp"
+ >
+ </File>
+ <File
         RelativePath="..\..\lib\CodeGen\PHIElimination.cpp"
         >
       </File>
@@ -453,6 +457,10 @@
         >
       </File>
       <File
+ RelativePath="..\..\lib\CodeGen\RegAllocPBQP.cpp"
+ >
+ </File>
+ <File
         RelativePath="..\..\lib\CodeGen\RegAllocSimple.cpp"
         >
       </File>
@@ -736,6 +744,10 @@
       </File>
       <File
         RelativePath="..\..\include\llvm\CodeGen\Passes.h"
+ >
+ </File>
+ <File
+ RelativePath="..\..\lib\CodeGen\PBQP.h"
         >
       </File>
       <File

And for note, if anyone wants a test platform like I mentioned above,
one based completely in C++, I would be willing to help build it. Do
note, I really have no clue what should be tested inside llvm, I
barely use it myself (not too deep in my project yet, work is getting
the best of my time right now) so I know not exactly what to test, but
I can help setup the framework for the tests if anyone wants to help
with making the actually testing parts (or at least telling me what
needs to be tested so I could start making them). And for note, I
like boost, so I would probably require that for the framework as I
would use a few pieces out of it, but I do not think that is a big
deal as any distro I know of comes with it, and all the Windows devs I
know already have it too (it is just too useful not to have), so I do
not see it as an unnecessary addon, we could even tear out the parts
we would use and include it with the tests as well so others would not
require having it already if really wanted, its license encourages
that.

13

For my info, are there any reported bugs that are unfixed in 2.4?

Looks like there is one outstanding correctness bug (2697) and three crash bugs (2735, 2775, 2797). I haven't reverified these lately, though.

John

14

OvermindDL1 wrote:

  

LLVM will be mostly irrelevant on Windows as long as it doesn't have
either a native-enough testing framework on Windows, or a build process
that chokes on canonical Windows tools. [Specifically, Perl. I get the
same errors with unpatched LLVM sources with both ActiveState, and
built-from-tarball Perl 5.8.8 . I'd guess the root problem is that
canonical Windows builds of Perl use cmd rather than sh for the command
shell.]
    

.... Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.

Assuming that the absence of testing is a sufficient cause for not
wanting to use LLVM on that system, and the system is otherwise worth
supporting: yes.

Kenneth
    
I still do not see why all the tests revolve around llvm-gcc.

The *.ll source tests should not revolve around llvm-gcc. The *.c and *.cpp tests are as problematic as claimed.

There has been some noise about relocating the frontend tests elsewhere, but I have no idea when that will actually happen.

  They
are not really testing llvm, they are testing llvm-gcc. We need a
good testing framework built in c++ itself, that can be built by the
same compiler that builds llvm itself, which can then be run to do all
the tests and return a result back, perhaps even with a network
library like boosts to submit results to the website, it can all be
done in c++ quite easily and would work everywhere just fine, and yet
people feel the need to write all this external stuff.

I can see using C++ test drivers as part of LLVM testing, but they really are a different level of testing than the DejaGNU/expect framework tests.

I would not be comfortable using just C++ test drivers, but think they would be useful in enforcing things like IEEE semantics for APFloat, that are not easily accessible from driver programs.

I've thought about this myself (basically, what to do for platforms that don't have a reasonable native expect like MingW32), and there aren't that many good future-compatible choices when you actually need to examine both stdout and stderr, and can't assume POSIX. My initial prototyping work on this indicates that it's:
* easy to check for success/failure exit codes (can do this in both windows batchfile and Bourne shell script) and report last failing test case
* moderately easy to check for success/failure/assert exit codes and report all failing test cases (Bourne shell script, do not know how to do this in windows batchfile). (When using msvcrt assert, the exit code from an assert is 3 so it can be distinguished from a normal EXIT_FAILURE. I don't know how this works on other platforms.)
* painful to check stderr/stdout. Cf. earlier flamey thread. Basically, the only future-compatible options other than DejaGNU/expect I can think of are POSIX (which will not port to MSVC and MingW32), shell scripting (skeptical about this actually working generally), and Tcl. If future-compatibilty wasn't a requirement, Python is another possibility.

(Yes, I know shell scripting isn't windows-centric. If the alternate CMake build system stabilizes, having a CTest alternate test driver suite would make a lot of sense.)

  Yes, we need
the external stuff to test llvm-gcc, but on platforms where there is
no llvm-gcc there needs to be a testing framework to fully test llvm
itself, in all ways, but fully through its api, not something else
like llvm-gcc.
  

LLVM testing would benefit from a directly API-exercising testsuite regardless of whether there is llvm-gcc.

Kenneth

15

I think a pure C++ llvm test platform would work quite well
personally. Not only could you test little parts of the API, but you
can also create IR in memory (or load the occasional file, but then
that would not test more of the things, which is kind of the purpose)
and either JIT it to test execution of compiled llvm code, as well as
being able to run various optimization passes in different orders of
different sets and still verify that the code works correctly. With
such a C++ test platform you do not need to do anything with the
standard output/input as you can read everything directly, do not need
error codes, would just need to make sure everything works as
expected. Such as create some IR for known complicated problems for
many of the passes and confirm that they always work and nothing
breaks, can even make some that fail now that some optimization pass
should optimize so that would help encourage it to be fixed so that,
that one test would pass.

I see no reason why any shell scripts, DejaGNU, etc... or anything
would be necessary. If a compiler is capable of compiling llvm, then
it is certainly most capable of creating and handling the tests
through pure C++ as well, as such you would make the tests far more
distributable. Because many of my programs need to work on both
Windows XP clients and my FreeBSD server, I tend to not handle
anything that will not work on both without too much extra crap, and
things like this have always worked perfectly. C++ is extremely
capable, and running tests through it tend to execute faster, able to
test more things, can code the tests faster (there are wonderful
libraries that speed such things up, like boost), and it "Just Works"
everywhere. Relying on posix for example, is just as bad and useless
for multiplatform work as is relying on something like MFC
(consequently, it is reasons like this that I also *HATE* the automake
tools as they create the most convoluted horrible to deal with build
scripts in existence, where-as cmake works wonderfully, and if you
really need to do special crap like automake things do, it is just as
easy to whip up a short C++ program, add its project to your build,
have it build and execute first before building the rest, all easy to
do, and very multiplatform).

I do find it humorous though in how so many people seem to rely on 50
little types of shell scripts spread across 50 different languages
when C++ can do it all, and with the right libraries can do it all in
just about the same short amount of code, all faster, all more
reliable, all easier to use, and by far more multiplatform (as well as
the fact you do not have to memorize 50 languages, especially horrors
like M4 and the makefiles and the other automake tools).

16

OvermindDL1 wrote:

  

/* snip */
    
I think a pure C++ llvm test platform would work quite well
personally. Not only could you test little parts of the API, but you
can also create IR in memory (or load the occasional file, but then
that would not test more of the things, which is kind of the purpose)
and either JIT it to test execution of compiled llvm code, as well as
being able to run various optimization passes in different orders of
different sets and still verify that the code works correctly. With
such a C++ test platform you do not need to do anything with the
standard output/input as you can read everything directly, do not need
error codes, would just need to make sure everything works as
expected. Such as create some IR for known complicated problems for
many of the passes and confirm that they always work and nothing
breaks, can even make some that fail now that some optimization pass
should optimize so that would help encourage it to be fixed so that,
that one test would pass.

I see no reason why any shell scripts, DejaGNU, etc... or anything
would be necessary.

I don't think anyone is arguing that these are *necessary*, just that the time-to-maintain is far less with a test framework that automatically picks up all test cases and uses the test cases themselves to determine when to run them, and how.

  If a compiler is capable of compiling llvm, then
it is certainly most capable of creating and handling the tests
through pure C++ as well, as such you would make the tests far more
distributable.

At the absolute minimum, simple counting of the success/failure/internal error results requires three different exit codes, and a test driver capable of tallying them up and reporting all failures (unexpected success, unexpected failure, and internal errors with a designated distinct exit code).

That much could be done in C++, although the maintainability of even this is much simpler using a Bourne shell script to coordinate the C++ test drivers. If I didn't have to worry about automatically picking up the *.ll tests and configuring them via DejaGNU-command comments, creating said test driver for the *.ll files would be a rote-work task.

The problem is when you need to inspect stderr/stdout; the C and C++ standard libraries are pretty much not there, POSIX only works *NIX-side, and Boost generally locks out all but the most compliant or major compiliers for interprocess work.

The send-in-the-report feature of the current test framework is also mandatory; until that has an alternate, the DejaGNU framework should be staying.

(consequently, it is reasons like this that I also *HATE* the automake
tools as they create the most convoluted horrible to deal with build
scripts in existence, where-as cmake works wonderfully, and if you
really need to do special crap like automake things do, it is just as
easy to whip up a short C++ program, add its project to your build,
have it build and execute first before building the rest, all easy to
do, and very multiplatform).
  

CMake either works wonderfully (most of the time), or not at all. (My platform, MingW32. CMake incorrectly classifies MingW32 vs CygWin by the presence of sh, throws CygWin fullpaths at MingW32: catastrophic failure. Verified with CMake 2.6.1 and CMake 2.6.2, will not bootstrap.)

At least I can repair automake-configure generated makefiles when this happens. CMake is unrepairable (which indicates a serious architectural flaw, not repairable merely by adding in enough intelligence to distinguish between CygWin and MingW32 with sh).

I do find it humorous though in how so many people seem to rely on 50
little types of shell scripts spread across 50 different languages
  

No need to resort to hyperbole. Five is credible.

Kenneth

17

This is what I am not understanding about how you are thinking about
this. There are a great deal more responses and having a C++ test
program, say boost::test, it can handle a great deal of information,
spitting out exactly what caused various things to fail, it is not
just a matter of running a variety of programs and testing them, those
are more useful if you are testing an external app like llvm-gcc, not
llvm itself, which is a library, not an application, and if it was
treated as such then its testing framework for it and it alone could
become a great deal more powerful while being far easier to use. It
could quite literally just be a single extra project, each test could
be in its cpp file, no header for the tests needed, and just have
something like boost::test run them all in succession. If a test is
truly expected to fail in a spectacular way (say, by abort()ing the
application, those really need to be fixed and removed, there are ways
to hook the abort call) those could be made into a simple separate exe
and run by the main boost::test framework as well, nothing special
required.

I use this style testing and it is very simple to use, very powerful,
plenty of information, and it tests llvm as a library, meaning it can
test *all* of it, not just what the mini-apps like llc and such
expose, since they just access specific parts of the library anyway.
No testing error codes, no watching the standard input/output (which
is a horrible way of testing regardless), etc... And as stated, it is
also very simple for a C++ program to submit its own report, nothing
special there either.

If any mini test apps needed to be used, then you could still have the
main test program watch the standard input/output, that is a simple to
do regardless of the OS you are, but even using something like
boost::interprocess to communicate would be even far more powerful,
and still very simple. And it seems to support more compilers then
llvm anyway (these are just the tested compilers, it no doubt supports
more just fine, still more then llvm either way):
    * Visual 7.1 Windows XP
    * Visual 8.0 Windows XP
    * GCC 4.1.1 MinGW
    * GCC 3.4.4 Cygwin
    * Intel 9.1 Windows XP
    * GCC 4.1.2 Linux
    * GCC 3.4.3 Solaris 11
    * GCC 4.0 MacOs 10.4.1

DejaGNU can send in reports, so can C++ itself. It is simple for
boost::filesystem to parse through directories and, say, get all of
the .ll files, of which you can then run through various optimizers
and make sure the converted code is correct, or run through the
interpreter, or run through the JIT to test the JIT, etc...

That does not really surprise me about CMake, but then mingw is not a
primary compiler on Windows, more so is VC++ or Intel, either way a
bug should be submitted to the CMake devs. I thought you could
override things like that with some command line parameters anyway.
You cannot force it to output mingw files directly?

18

I should apologize. I have been trying to keep from attacking the
current process that llvm uses for testing (although I do still agree
that the current testing framework is more for testing llvm-gcc and
not llvm), but I have not quite been so successful. Some basic
background. I program for generally just two systems, Windows XP and
FreeBSD. These are rather polar opposites, and most 'multi-platform'
things seem to be designed for things like multiple platforms of
linux, and not actually multiple platforms. As such I have had to
find just about everything in every way I can that just makes it
simple to compile code for both XP and BSD (even with its usually
rather outdated gcc compiler), and it has been wonderfully successful;
I can, quite literally, just drop the source without any makefiles and
such, and just basically have it build everything in say a source and
header directory, using whatever optimizations and such I want, and it
just works. I do use CMake, but honestly it is rather rare as I find
it generally just easier to compile and link everything myself due to
how simple I try to keep everything. I develop from Visual Studio
2005 with the Visual Assist addon (I would drop VC++ in a hearbeat if
there was some other IDE, say like Eclipse, that got anywhere near the
feature-set that the Visual Assist add-on has, so far nothing is
getting close, without Visual Assist though, I would prefer something
else, like Eclipse or so, to VC++, but Visual Assist just swings the
favor overwhelmingly over), and everything is dumped into an SVN
repository running on the BSD box, upon which I will either compile
the project through VC++ on Windows, or I will login and sync to the
svn on the BSD machine and just run the very simple makefile (which,
quite literally, just builds everything together in specific project
directories at the optimization and such levels I want, nothing
special). I have had no real problems (other then some lacking
template support in the older GCC versions that the older BSD's used
to use, the newer ones are better though, boost still worked with the
older ones, but not all my personal code did).

Either way, because of the way I build, I have developed a rather
large lack of interest in things that I do not consider truly
multi-platform. As such I have found that just doing everything in
C++ itself just always works, no hassles. At rare times I will whip
up something in python (although I, oddly enough, seem to have to put
in more platform specific tests in it then I do in my C++ code), but
for any of my bigger projects I just stick with C++ itself, I am after
all a C++ programmer first and foremost.

19

Ideas and feedback are useful. However, one systematic problem that the LLVM community has is that most of the regular contributors are on unix systems. As you probably know, much open source software works by having people 'scratch their itch'. You (and many other people on windows) are very itchy about this, but you're not producing code.

If you have patches to start making specific progress towards your goal, they would be really welcome. Until then, we'll all admit that LLVM could work a lot better on windows, and follow it up with "patches welcome".

That said, I am really thrilled about the recent progress towards cmake'ifying llvm, and we do have some very helpful developers on windows (thank you!). There are just a few very specific people who are very willing to complain about lack of feature x, but are apparently unwilling to help make it a reality.

-Chris

20

Please send a diff or project file. I have no way of testing this, so I don't want to attempt to apply the patch manually, thanks!

-Chris