llvm backend issue on AMD64
Hi, While running translations with various options on an AMD64, I encountered issues with the llvm backend: the translation fails when llvm-as is called. The error message is:: [translation:ERROR] llvm-as: <stdin>:586398: Redefinition of function 'LL_os_fstat'! In entry_point.ll, I have a forward declaration of LL_os_fstat:: declare fastcc %structtype_tuple10* %LL_os_fstat(long) and indeed 2 definitions of the function. The first one is at line 449952, and it has a structure very similar to the definition I get when I translate in 32bit mode (but takes a long instead of an int as argument). The second one looks like:: internal fastcc %structtype_tuple10* %LL_os_fstat(long %tmp_13431) { %tmp_13433 = cast long %tmp_13431 to int %tmp_13432 = call fastcc %structtype_tuple10* %LL_os_fstat(int %tmp_13433) ret %structtype_tuple10* %tmp_13432 } If I comment out this second definition, I get a similar error regarding LL_os_lseek, LL_os_fork, etc. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/
Hi Alexandre, Thank you for trying this out! Do the llvm tests pass? pypy-llvm has not been properly tested on 64 bit systems! Some efforts were made but compatibilty was never maintained because of a lack of such a machine. If you could give me an account on your computer I could make sure that at least proper checks are in place. cheers, Eric On Nov 30, 2006, at 10:56 AM, Alexandre Fayolle wrote:
On Thu, Nov 30, 2006 at 12:42:48PM +0100, Eric van Riet Paap wrote:
Unfortunately, no. See http://codespeak.net/~afayolle/summary.html for details. The installed llvm version is 1.8b. llvm-gcc --version says llvm-gcc (GCC) 3.4-llvm 20051104 (LLVM 1.7cvs)
I am afraid this is going to be difficult. The machine is inside logilab's LAN, and only available through a VPN. However I'll be happy to help solving the issue (trying to patch the code if pointed in some initial direction, or applying patches and reporting back) -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/
At least If I remember correctly what samuele told me is that if you really want to use llvm you should be using the cvs trunk version, this might fix some bugs for you (or open new ones :-)) On 11/30/06, Alexandre Fayolle <alexandre.fayolle@logilab.fr> wrote:
-- Leonardo Santagada (http://www.lomohomes.com/retype) Não se preocupe com o que os outros vão fazer. O melhor jeito de prever o futuro é inventa-lo. - Alan Kay
(please, don't add me to the recipients when you reply on-list. I'm subscribed. Thanks) On Thu, Nov 30, 2006 at 10:36:41AM -0200, Leonardo Santagada wrote:
Well, the Debian package uses a cvs snapshot from 2006-10-21, and apparently, llvm does not support AMD64. The support is "hacked back in" by the package maintainer, so the problem may well be in the toolchain. (and maybe it's not that usefull trying to get that backend to work on AMD64 until llvm supports the arch officially) -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science Reprise et maintenance de sites CPS: http://www.migration-cms.com/
Hi Alex, On Thu, Nov 30, 2006 at 10:56:38AM +0100, Alexandre Fayolle wrote:
While running translations with various options on an AMD64
We don't actively support 64-bit machines right now. There are failing tests. They reflect known problems. They are things to fix first before we should try to debug the resulting inconsistencies. No deep problem, but still... (We decided to focus on 32-bit machines for simple lack of time.) A bientot, Armin
participants (5)
-
Alexandre Fayolle
-
Armin Rigo
-
Eric van Riet Paap
-
Jacob Hallén
-
Leonardo Santagada