LLVM 2.7 svn Error
Libor
software versions:
1) Upgraded Ubuntu to Karmic Koala (Ubuntu 9.10) (yes, they do go for
naff names...) - no problems.
2) Updated to the latest svn version of LLVM and recompiled - no
problems.
3) Updated to the latest svn version of Pure and attempted to
recompile.
The latest LLVM seems to be broken again against the latest Pure.
I got the following error when compiling Pure. Is it easily fixable?
g++ -g -O2 -fPIC -I/usr/local/include -D_GNU_SOURCE -
D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I. -I. -
DLIBPURE='"libpure.so.5"' -c -o interpreter.o interpreter.cc
interpreter.cc: In member function ‘llvm::ReturnInst* Env::CreateRet
(llvm::Value*, const rule*)’:
interpreter.cc:4853: error: invalid conversion from
‘llvm::Instruction*’ to ‘llvm::CallInst*’
make: *** [interpreter.o] Error 1
Cheers,
Libor
Eddie Rucker
Last week (maybe the week before???), I compiled the latest LLVM and Pure but the
string and list functions gave crazy results. Albert confirmed that the latest
LLVM did not work correctly with Pure. I guess the LLVM crew have changed stuff
enough that Pure doesn't even compile against it anymore. Better stick with 2.5
or 2.6. I've gone back to LLVM 2.5 for the time being since it currently works best.
e.r.
On Fri 30/10/09 5:37 AM , Libor lib...@gmail.com sent:
> I have just performed my periodic installation using the latest
> software versions:
>
> 1) Upgraded Ubuntu to Karmic Koala (Ubuntu 9.10) (yes, they do go for
> naff names...) - no problems.
> 2) Updated to the latest svn version of LLVM and recompiled - no
> problems.
> 3) Updated to the latest svn version of Pure and attempted to
> recompile.
>
> The latest LLVM seems to be broken again against the latest Pure.
> I got the following error when compiling Pure. Is it easily fixable?
>
> g++ -g -O2 -fPIC -I/usr/local/include -D_GNU_SOURCE -
> D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I. -I. -
> DLIBPURE='"libpure.so.5"' -c -o interpreter.o interpreter.cc
> interpreter.cc: In member function ‘llvm::ReturnInst*
Albert Graef
> Last week (maybe the week before???), I compiled the latest LLVM and Pure but the
> string and list functions gave crazy results. Albert confirmed that the latest
> LLVM did not work correctly with Pure. I guess the LLVM crew have changed stuff
> enough that Pure doesn't even compile against it anymore. Better stick with 2.5
> or 2.6. I've gone back to LLVM 2.5 for the time being since it currently works best.
Yes, there are issues with LLVM from TOT, and they are currently doing
more changes to the JIT API which break backward compatibility again.
I'm waiting for the dust to settle. Meanwhile, if someone already has a
patch which makes Pure compile and run with TOT again, I'll be happy to
apply it.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef
> Yes, there are issues with LLVM from TOT, and they are currently doing
> more changes to the JIT API which break backward compatibility again.
> I'm waiting for the dust to settle. Meanwhile, if someone already has a
> patch which makes Pure compile and run with TOT again, I'll be happy to
> apply it.
w.r.t. LLVM TOT. The bad news is that things have gone from bad to
worse. At least on x86-64, the LLVM JIT seems to be completely broken in
2.7svn. Most of that can be attributed to tail call optimization being
broken, but even if I turn off TCO in Pure there are still four failed
checks due to segfaults in the LLVM JIT compiler. With TCO enabled more
than 50% of the checks fail.
The breakage is definitely in the JIT. When I batch-compile the same
Pure programs, they work fine, including TCO. I've also taken a look at
the generated LLVM assembler code and up to trivial symbol renaming,
it's exactly the same as with LLVM 2.6, so I'm pretty sure that there's
no problem with the LLVM IR that Pure generates.
With so much stuff broken in LLVM TOT, I don't even know where to start
debugging this. I remember that Pure still worked with early 2.7svn
revisions (some time between the first and the second 2.6 prerelease),
so I might go back and replay LLVM commits until I start hitting the
point where the breakage started. But that will be an arduous process.
I've been following llvm-dev but I haven't seen any announcements there
about major JIT changes which would explain this massive fallout.
For the time being, I can only advise to stay away from LLVM 2.7svn.
Stick with LLVM 2.5 or 2.6, they both work fine with Pure. I've been
running the latter for some weeks now and I haven't seen any problems,
apart from the LLVM 2.5 JIT being a little faster than the one in 2.6
(but that's probably due to the multithreading support in LLVM 2.6).
Libor
Ubuntu box again
without the bother of regressing LLVM.
Thanks for trying. It sounds like LLVM is rapidly going downhill.
Getting slower and buggier with each release is not good for projects
depending on it.
Libor
Albert Graef
> This is a pity, I was looking forward to being able to use Pure on my
> Ubuntu box again without the bother of regressing LLVM.
an environment for building Pure against LLVM 2.5, say, and still use
2.7svn for everything else. AFAICT, the command line utilities from LLVM
2.7svn should be ok for making Pure's batch compiler work. The bugs I
saw are only in the JIT, batch-compiled Pure programs seem to work fine
even with 2.7svn. And the bitcode emitted by pure -c -s should be ok
with any LLVM >=2.5 toolchain. So having 2.7svn as your main LLVM
installation should be ok, as long as you build Pure with either LLVM
2.5 or 2.6.
> Thanks for trying. It sounds like LLVM is rapidly going downhill.
> Getting slower and buggier with each release is not good for projects
> depending on it.
local optimum, I'm pretty confident that the LLVM developers will
eventually get these things sorted out again. Running a development
version always carries with it the risk of intermittent bugs. If you
want stability then obviously you're better off with the stable
releases, that's what they are for after all. ;-)
Cheers,
Albert Graef
> Ok, I've taken another look at this and fixed the compilation probs
> w.r.t. LLVM TOT. The bad news is that things have gone from bad to
> worse. At least on x86-64, the LLVM JIT seems to be completely broken in
> 2.7svn.
until LLVM r84031. In r84032 some guys from Google's UnladenSwallow team
started working on JIT improvements and bugfixes, ironically that's also
when Pure stopped working. With r85295 it starts working again, but only
with lazy JIT compilation disabled (otherwise it fails four checks,
which all seem to be related to anonymous closures; not sure what's the
exact issue there). With r88984 there were some changes in the JIT which
apparently break fastcc+tail calls, which is when Pure started showing
major breakage (some 25 failed checks).
Thus at present the last revision in LLVM svn which works with Pure is
r88983. You have to make sure that lazy compilation is disabled, though.
To these ends, you can use the latest Pure from svn (r2802 should be
fine). With Pure 0.39 you'll have to comment out line 160 in
interpreter, which reads:
JIT->DisableLazyCompilation(false);
Change that to:
//JIT->DisableLazyCompilation(false);
I have reported these issues on the LLVM list, so there's hope that we
get this sorted out before the LLVM 2.7 release.
Cheers,
Libor
recompiled the latest LLVM svn and the latest Pure in the normal way
and all 45 tests passed! Whatever/whoever it is/has fixed it, thanks!
Albert Graef
out minutes ago). I'll try to check out a fresh tree now.
Libor, you're running this on a true 64 bit Linux system, right? Are you
sure that you have the latest LLVM revision (what does 'svn info | grep
-i "Last Changed Rev"' in your LLVM svn tree say?)? If you happen to
have an LLVM revision between r85295 and r88983 inclusive then it's
supposed to work. r88984 and later are broken, at least for me.
Libor
with
the versions. I am upgrading my Asus to the
latest Ubuntu remix and had to format the disk, so it is now lost.
I am currently testing it on my 64bit machine, compiling LLVM
version 90962, will report the result.
Libor
Sorry for the false alarm.
Albert Graef
> I am afraid it still bombs out with 90962 on 64bit.
> Sorry for the false alarm.
try r88983, I'd be interested to hear about the results, too.)
Libor
I am using that for now on my Acer, which gets me out of compiling LLVM
(2.7) with mixed results. This seems to be a satisfactory compromise
meeting ground for Ubuntu, LLVM and Pure, allowing all three to work
together with minimum fuss.
So, I also give up on the bleeding edge LLVM for now but look forward
to it being sorted out in the future. I keep hoping that the latest
LLVM version should start showing some performance benefits at some
stage, instead of just bugs ? :)
Libor
error when attempting to compile LLVM 2.5:
In file included from Signals.cpp:30:
Unix/Signals.inc: In function ‘void<unnamed>::PrintStackTrace()’:
Unix/Signals.inc:81: error: invalid conversion from ‘const char*’ to
‘char*’
Unix/Signals.inc:96: error: invalid conversion from ‘const char*’ to
‘char*’
Any quick fix ideas?
Cheers, Libor
Libor
tests
because it is not configured right for Pure.
Jiri Spitz
> Hmm, I tried to fall back but no go either. I now get the following
> error when attempting to compile LLVM 2.5:
>
> In file included from Signals.cpp:30:
> Unix/Signals.inc:81: error: invalid conversion from �const char*� to
> �char*�
> Unix/Signals.inc:96: error: invalid conversion from �const char*� to
> �char*�
>
There are two occurences of line:
const char* name = strrchr(dlinfo.dli_fname, '/');
in the file Unix/Signals.inc.
Simply add an explicit cast:
const char* name = (const char*)strrchr(dlinfo.dli_fname, '/');
This error occurs with the newest GCC versions - there is likely sticter
type checking than in older versions.
Jiri
Libor
> Simply add an explicit cast:
> const char* name = (const char*)strrchr(dlinfo.dli_fname, '/');
Jirko, thank you for the hint. Actually, these two lines in my
copy of the source demand (char*) cast to work, as follows:
char* name = (char*)strrchr(dlinfo.dli_fname, '/');
So it is not quite the usual case of "constant poisoning".
Is it just me finding myself spending 90% of my time
fixing things intended to make programming safe?
I wish they would give it a rest....
Libor
John Cowan
> So it is not quite the usual case of "constant poisoning". Is it just
> me finding myself spending 90% of my time fixing things intended to
> make programming safe? I wish they would give it a rest....
No, it's C++. In C++ there are fifty ways to do anything, 49 of
which are wrong (including the straightforward and obvious way). C++
is a high level language masquerading as a high level language. C++
is a programming language that induces paranoia in its users: you dare
not trust your compiler, your libraries, your fellow programmers, or
(above all) yourself not to shoot you in the foot (which causes your
leg to be amputated).
I could go on....
--
John Cowan <co...@ccil.org> http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script. One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.' --Beverly Erlebacher
John Cowan
> No, it's C++. In C++ there are fifty ways to do anything, 49 of
> which are wrong (including the straightforward and obvious way). C++
> is a high level language masquerading as a high level language.
Er, that's "low level language masquerading as a high level language".
--
John Cowan co...@ccil.org http://ccil.org/~cowan
Female celebrity stalker, on a hot morning in Cairo:
"Imagine, Colonel Lawrence, ninety-two already!"
El Auruns's reply: "Many happy returns of the day!"
Albert Graef
> char* name = (char*)strrchr(dlinfo.dli_fname, '/');
I guess that dlinfo.dli_fname is a const char* in which case the C++
incarnation of strrchr makes the return type a const char* too (see
http://www.cplusplus.com/reference/clibrary/cstring/strrchr/). Which
makes sense if you think about it, as the result of strrchr points into
the const char* argument, so it should be a const char* as well.
This must be a recent change or fix in the g++ library, as I don't have
the const char* variation of strrchr in my cstring header, so I don't
see this error with gcc 4.3.
But anyway, the proper fix would be to make 'name' a const char*, which
actually is how it's declared in the corresponding LLVM 2.6 source.
> Is it just me finding myself spending 90% of my time
> fixing things intended to make programming safe?
> I wish they would give it a rest....
I know that feeling. :) Yeah, const can drive you crazy, because it
"ripples through." People often just give up and cast stuff to char*,
which of course defeats the purpose.
Another reason why (purely) functional programming is so nice;
everything is 'const' anyway, so you don't even have to think about it. :)
Albert
Libor
> This must be a recent change or fix in the g++ library, as I don't have
> the const char* variation of strrchr in my cstring header, so I don't
> see this error with gcc 4.3.
Yes, this was gcc 4.4.1 and I get constant poisoning in other C++ code
too.
I don't write C++ code myself, as I agree with John and avoid it like
a plague.
Give me plain honest C anyday, that does not masquerade as anything.
In C you can also write it in 50 different ways but they will all
work :)
On the other hand, in Java, you must write one-liner "Hello World" in
50 lines :)
> Another reason why (purely) functional programming is so nice;
> everything is 'const' anyway, so you don't even have to think about it. :)
This is an excellent point. Put that in the primer?
Libor
Albert Graef
> I investigated some more. Turns out that everything was fine and dandy
> until LLVM r84031. In r84032 some guys from Google's UnladenSwallow team
> started working on JIT improvements and bugfixes, ironically that's also
> when Pure stopped working. With r85295 it starts working again, but only
> with lazy JIT compilation disabled (otherwise it fails four checks,
> which all seem to be related to anonymous closures; not sure what's the
> exact issue there). With r88984 there were some changes in the JIT which
> apparently break fastcc+tail calls, which is when Pure started showing
> major breakage (some 25 failed checks).
Continuing the saga, Jeffrey Yasskin has fixed the TCO-related LLVM JIT
breakage. I've also committed some more fixes for LLVM 2.7 compatibility
to Pure svn, so the latest svn sources of Pure should work with the
current LLVM 2.7svn again.
That's good news. At least chances are good now that Pure will work with
LLVM 2.7 when it comes out.
Ryan, that also means that Pure *might* work with LLVM 2.7 on Snow
Leopard in 64 bit now. It would be great if you could give this a try
when Pure 0.43 gets released.
Libor
Pure 0.43 now works here on my Ubuntu 64bit with
LLVM 2.7 latest version (95516). All 49 tests passed.
Libor