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:
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/ _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
On Thu, Nov 30, 2006 at 12:42:48PM +0100, Eric van Riet Paap wrote:
Hi Alexandre,
Thank you for trying this out!
Do the llvm tests pass?
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)
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.
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
On Thu, Nov 30, 2006 at 12:42:48PM +0100, Eric van Riet Paap wrote:
Hi Alexandre,
Thank you for trying this out!
Do the llvm tests pass?
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)
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.
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/
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iQEVAwUBRW7OkF6T+PKoJ87eAQL3zQgAhwXKdu4WAl6MK9LMTa7ncEdYigydQ0Rg IwcA9mSMy7SelcWmKJeRJ0o4TbpdXO2HQ+FdcAHBDV1Lc9VGJYMq+rySjfmYJ9dh b0YOva7xqqYo8lk68S3OGyCZpmFXCHzcfSv+kLujXkCgCblb6lLmyal5eSG6qXaf vqfRojb/qZgtrltZpiQ839JMDHJGSJ67SBNwQY89P3xIXsszL7j1ec5eVg5iw3hS 2m/t5I5rTMk72wOF39XMDIXAdHnIN+BZpY9ykxPRn9Y2Wzgn9S0/Uw5WghkXOfDJ k6wHJ8+MTMQKzJovhpzIIIyH3My63JdqSBDqsYt3n6sQI5EsvK/5aA== =/ZNr -----END PGP SIGNATURE-----
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-- 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:
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 :-))
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/
On Thursday 30 November 2006 13:29, Alexandre Fayolle wrote:
On Thu, Nov 30, 2006 at 12:42:48PM +0100, Eric van Riet Paap wrote:
Hi Alexandre,
Thank you for trying this out!
Do the llvm tests pass?
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)
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.
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)
I have an amd64 machine running a pure 64 bit debian system (etch). I can make an account available. Jacob
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