Re: manipulating FPU rounding modes on alpha
Hi, this is exactly the same result that I get on Uwe's EV56 without and with math_emu. I'm not in the position to discuss whether math_emu should be a module or built in. Using which kernel? linux-image-2.6.21-2-alpha-generic 2.6.21-6 Here is my /proc/cpuinfo in case you want to compare against the other EV56 that supposedly worked fine without math_emu: This seems to be a misunderstanding. If the module is loaded, everything is fine; if it is not loaded, I get the same errors as you. So the other EV56 behaves exactly like your machine. Joachim P.S.: Please CC: me on replies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
On Tue, Sep 11, 2007 at 08:43:44AM +0200, Joachim Reichel wrote: This seems to be a misunderstanding. If the module is loaded, everything is fine; if it is not loaded, I get the same errors as you. So the other EV56 behaves exactly like your machine. Well that makes sense then. Well hopefully as soon as the kernel packaging bug is fixed then the problem will go away. In the mean time EV6 and higher machines are OK, and any machine running an SMP kernel is OK too (since they have math_emu built in). The cgal package is fine and is just unfortunately affected by a bug in the kernel package. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
Hi, This seems to be a misunderstanding. If the module is loaded, everything is fine; if it is not loaded, I get the same errors as you. So the other EV56 behaves exactly like your machine. Well that makes sense then. Well hopefully as soon as the kernel packaging bug is fixed then the problem will go away. In the mean time EV6 and higher machines are OK, and any machine running an SMP kernel is OK too (since they have math_emu built in). The cgal package is fine and is just unfortunately affected by a bug in the kernel package. Your analysis regarding EV6 and above is not correct. The package fails on EV56 and below without math_emu for obvious reasons. According to www.buildd.net, the buildd ds10 is an EV6. On this machine the package fails with an error slightly different from EV56 without math_emu. The reasons for the error on ds10 is still unknown, in particular, whether it is caused by a bug in the package itself. Regards, Joachim P.S.: Please CC: me on replies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
On Sun, Sep 09, 2007 at 09:38:43PM -0400, Lennart Sorensen wrote: I am running a build right now. It built on my machine. So here is the state of my machine: kernel: 2.6.18.dfsg.1-13etch2 cpu: Alpha EV56 (21164A) 433MHz. running unstable in a chroot, with stable on the main system. Did the build in the unstable chroot, but of course still under the kernel from stable. 2.6.18 has MATH_EMU built in and hence always present. Would you like me to try putting the new 2.6.22 kernel on and building under that? -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
Hi Lennart, Would you like me to try putting the new 2.6.22 kernel on and building under that? if it is not too much work for you, yes, I would appreciate that. Kind regards, Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
On Mon, Sep 10, 2007 at 04:56:02PM +0200, Joachim Reichel wrote: if it is not too much work for you, yes, I would appreciate that. I will give it a shot. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
On Mon, Sep 10, 2007 at 12:44:56PM -0400, Lennart Sorensen wrote: I will give it a shot. Build fails running 2.6.22, or rather the test fails. Running 'LD_LIBRARY_PATH=/root/cgal-3.3.1/debian/tmp/usr/lib /root/cgal-3.3.1/debian/tests/rounding_modes' returns: default: ERROR get/set: ERROR ZERO zero : ERROR ZERO +inf : ERROR ZERO -inf : ERROR ZERO near : ERROR ZERO But if I then load the 'math_emu' module and repeat the command I get: default: ok get/set: ok zero : ok +inf : ok -inf : ok near : ok So the math_emu feature in the kernel has something to do with it. Looking at the kernel description for math_emu on the alpha, it looks like a very serious error for debian to have made it modular instead of built in, since the purpose of the module is not to emulate an FPU like it is on x86 or arm, but instead to provide IEEE compliant floating point on the alpha. This is the description on 2.6.18: config MATHEMU tristate Kernel FP software completion if DEBUG_KERNEL !SMP default y if !DEBUG_KERNEL || SMP help This option is required for IEEE compliant floating point arithmetic on the Alpha. The only time you would ever not say Y is to say M in order to debug the code. Say Y unless you know what you are doing. No wonder the floating point stuff goes broken when that isn't loaded. Now this feature only applies to alphas below EV6 (So since mine as an EV56 it needs the math_emu feature to generate IEEE compliant floating point behaviour). I also see an indication that if you call gcc with the -mieee option, it will generate code that runs on any alpha correctly, without relying on the kernel to solve the problem for it. I guess the real answer is that either debian should switch MATH_EMU back to 'y' as highly recomended by the comment in the kernel, or we need something to ensure that any alpha with a CPU less than an EV6 automatically loads the module at boot (especially the buildd's). Perhaps calling it math_emu is a bad idea on the alpha, since it is more of an emulate proper ieee floating point, but certainly I think it is wrong to make it a module in the debian kernels, since only 21264 and higher alphas work correctly now, unless you know to load the math_emu module. There isn't even a note in the linux-image changelog indicating that this change was made. Amazingly this was filed in the past against 2.6.18 as bug 411813, and apparently lost again in later kernels. It appears it is going to be fixed in the next 2.6.22 kernel release. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
Hi, Build fails running 2.6.22, or rather the test fails. Running 'LD_LIBRARY_PATH=/root/cgal-3.3.1/debian/tmp/usr/lib /root/cgal-3.3.1/debian/tests/rounding_modes' returns: default: ERROR get/set: ERROR ZERO zero : ERROR ZERO +inf : ERROR ZERO -inf : ERROR ZERO near : ERROR ZERO But if I then load the 'math_emu' module and repeat the command I get: default: ok get/set: ok zero : ok +inf : ok -inf : ok near : ok this is exactly the same result that I get on Uwe's EV56 without and with math_emu. I'm not in the position to discuss whether math_emu should be a module or built in. I also see an indication that if you call gcc with the -mieee option, it will generate code that runs on any alpha correctly, without relying on the kernel to solve the problem for it. Your conclusion seems wrong since the test is built with -mieee -mfp-rounding-mode=d -frounding-math. Note that the failure is slightly different from that in the build logs on ds10 (which is an EV6 anyway). Maybe the problem is specific to EV6 and above? Is another alpha developer willing to help? I asked Martin Zobel-Helas for an account on ds10, but he is quite busy right now with listmaster stuff. Lennart, thanks for your help. Regards, Joachim P.S.: Please CC: me on replies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
On Mon, Sep 10, 2007 at 11:20:21PM +0200, Joachim Reichel wrote: this is exactly the same result that I get on Uwe's EV56 without and with math_emu. I'm not in the position to discuss whether math_emu should be a module or built in. Using which kernel? Your conclusion seems wrong since the test is built with -mieee -mfp-rounding-mode=d -frounding-math. Note that the failure is slightly different from that in the build logs on ds10 (which is an EV6 anyway). Maybe the problem is specific to EV6 and above? Well I did see some indication that -mieee breaks EV6 and above. They were old messages though so who knows what gcc does now. Why ever did Digital not just implement ieee floating point properly in the first place. :) I am still new to using an alpha, so not quite sure what gcc arguments do what yet. Is another alpha developer willing to help? I asked Martin Zobel-Helas for an account on ds10, but he is quite busy right now with listmaster stuff. Lennart, thanks for your help. No problem. Certainly the package as it is now builds fine with meth_emu enabled (loaded as module or built in) on an EV56 (PWD 433au), and the test fails without math_emu. Here is my /proc/cpuinfo in case you want to compare against the other EV56 that supposedly worked fine without math_emu: cpu : Alpha cpu model : EV56 cpu variation : 7 cpu revision: 0 cpu serial number : system type : Miata system variation: 0 system revision : 0 system serial number: cycle frequency [Hz]: 433149046 est. timer frequency [Hz]: 1024.00 page size [bytes] : 8192 phys. address bits : 40 max. addr. space # : 127 BogoMIPS: 858.04 kernel unaligned acc: 0 (pc=0,va=0) user unaligned acc : 0 (pc=0,va=0) platform string : Digital Personal WorkStation 433au cpus detected : 1 L1 Icache : 8K, 1-way, 32b line L1 Dcache : 8K, 1-way, 32b line L2 cache: 96K, 3-way, 64b line L3 cache: 2048K, 1-way, 64b line -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
I also see an indication that if you call gcc with the -mieee option, it will generate code that runs on any alpha correctly, without relying on the kernel to solve the problem for it. Your conclusion seems wrong since the test is built with -mieee -mfp-rounding-mode=d -frounding-math. As far as my understanding goes, this is not how the kernel module and -mieee work. I understand the difference in code generated with -mieee is that the ASM is produced in such a way that precise exceptions handling can be done. Precise exception handling is necessary for the kernel to be able to restart code after an exception/trap occurs. Without it, the kernel has to kill any program once a math fixup trap occurs (as it will when any such things as infs, nans, etc., that are not supported in hardware, are encountered). The difference in having the module load/not loaded is when precise exception handling is in effect (i.e., -mieee) and a trap occurs. Without the module the kernel just zeros the result and continues. With the module it generates the proper IEEE result and continues. Note this does not apply to anything after the EV56 as they have both (I believe it is both, but it may also be just one or the other) precise exceptions in all cases and hardware support for full IEEE specification. Later! -Tyson PS: The debian default is -mieee on unless --ffinte-math-only (part of -ffast-math) is specified (this was not the original default and getting it this way was the solution to a lot of pain in the form of random SIGFPEs). -- Tyson Whitehead (-twhitehe at uwo.ca -- MC-) Computer Engineer Dept. of Applied Mathematics, Graduate Student- Applied Mathematics University of Western Ontario, GnuPG Key ID# 0xF7666BFF London, Ontario, Canada signature.asc Description: This is a digitally signed message part.
Re: manipulating FPU rounding modes on alpha
On Sun, Sep 09, 2007 at 01:05:03PM +0200, Joachim Reichel wrote: it would be really helpful if some alpha porters could try to build cgal. If the build fails, could I get an account on your machine to track down the problem? I am running a build right now. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
On Thu, Sep 06, 2007 at 09:41:56PM +0200, Joachim Reichel wrote: I'm maintaining cgal (non-free), a package for computational geometry that requires manipulating the FPU rounding mode for some math operations. I need some help concerning an alpha specific problem. It turned out that the FPU rounding macros in 3.3-1 didn't work on alpha (search for ERROR in [1]). Uwe Schindler kindly allowed me to use his alpha machine to debug the problem. I found out that the software contained #ifdef's with specific macros for alpha. These macros didn't work (I don't know whether they never worked or don't work any longer). The generic macros from glibc worked. Based on this I uploaded 3.3-2 using the generic macros from glibc. But when the package was build on the buildd, the test failed again [2]. Unfortunately, it went unnoticed. Now upstream released 3.3.1 also using the generic glibc macros. And again, the test failed [3]. I just build the package manually, and the test succeeds! I have no clue how to debug this problem. The test works if the package is build manually, but fails on the buildd (ds10). I have no experience with alpha and don't know how to track this down. Could someone try to build the package manually and see if it fails?. It would be helpful to have a machine where the build fails when the package is build manually. One difference is that Uwe's machine runs current testing (libc6.1-dev 2.6.1-1), while the buildd uses older versions (libc6.1-dev_2.6-2 for 3.3-2 and libc6.1-dev_2.6-5 for 3.3.1-1) [4] Has someone a chroot environment with libc6.1-dev 2.6 (not 2.6.1)? A build failure in such a environment would indicate that the older glibc might cause the problem. Let me know if you need further information. Is this possibly a result of the switch to ldbl128 that happened around the end of may/beginning of june on alpha, powerpc, sparc and s390? This is where 'long double' changed from being 64bit to being 128bit. After you start to support 128bit floating point numbers, rounding might be affected on things that expect only 64bit. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: manipulating FPU rounding modes on alpha
On my machine (the machine where Joachim tested the build) the kernel module math_emu is loaded. Could it be the case that the test do not fail on my machine because of that? In older mails from this list I recognize a problem that code linked against the new libc needs math_emu enabled? - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] -Original Message- From: Joachim Reichel [mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2007 9:42 PM To: debian-alpha@lists.debian.org Subject: manipulating FPU rounding modes on alpha Hi, I'm maintaining cgal (non-free), a package for computational geometry that requires manipulating the FPU rounding mode for some math operations. I need some help concerning an alpha specific problem. It turned out that the FPU rounding macros in 3.3-1 didn't work on alpha (search for ERROR in [1]). Uwe Schindler kindly allowed me to use his alpha machine to debug the problem. I found out that the software contained #ifdef's with specific macros for alpha. These macros didn't work (I don't know whether they never worked or don't work any longer). The generic macros from glibc worked. Based on this I uploaded 3.3-2 using the generic macros from glibc. But when the package was build on the buildd, the test failed again [2]. Unfortunately, it went unnoticed. Now upstream released 3.3.1 also using the generic glibc macros. And again, the test failed [3]. I just build the package manually, and the test succeeds! I have no clue how to debug this problem. The test works if the package is build manually, but fails on the buildd (ds10). I have no experience with alpha and don't know how to track this down. Could someone try to build the package manually and see if it fails?. It would be helpful to have a machine where the build fails when the package is build manually. One difference is that Uwe's machine runs current testing (libc6.1-dev 2.6.1-1), while the buildd uses older versions (libc6.1-dev_2.6-2 for 3.3-2 and libc6.1-dev_2.6-5 for 3.3.1-1) [4] Has someone a chroot environment with libc6.1-dev 2.6 (not 2.6.1)? A build failure in such a environment would indicate that the older glibc might cause the problem. Let me know if you need further information. Kind regards, Joachim P.S.: Please CC: me on replies. [1] http://experimental.ftbfs.de/fetch.php?pkg=cgalver=3.3- 1arch=alphastamp=1183155884file=logas=raw [2] http://experimental.ftbfs.de/fetch.php?pkg=cgalver=3.3- 2arch=alphastamp=1184861686file=logas=raw [3] http://experimental.ftbfs.de/fetch.php?pkg=cgalver=3.3.1- 1arch=alphastamp=1189034249file=logas=raw [4] Shouldn't buildds build the packages in a current sid chroot? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
Hi, I have no clue how to debug this problem. The test works if the package is build manually, but fails on the buildd (ds10). I have no experience with alpha and don't know how to track this down. Is this possibly a result of the switch to ldbl128 that happened around the end of may/beginning of june on alpha, powerpc, sparc and s390? This is where 'long double' changed from being 64bit to being 128bit. After you start to support 128bit floating point numbers, rounding might be affected on things that expect only 64bit. I doubt that this is the cause. Note that it works with the newer libc6 while it fails on the machine with the older version. If the transition is the cause, it should be the other way round. By the way, the test uses only doubles. Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
On Thu, Sep 06, 2007 at 10:51:19PM +0200, Uwe Schindler wrote: On my machine (the machine where Joachim tested the build) the kernel module math_emu is loaded. Could it be the case that the test do not fail on my machine because of that? In older mails from this list I recognize a problem that code linked against the new libc needs math_emu enabled? AFAIK the math_emu module should not be needed on the buildds, which are ev6 and above. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: manipulating FPU rounding modes on alpha
On Thu, Sep 06, 2007 at 10:51:19PM +0200, Uwe Schindler wrote: On my machine (the machine where Joachim tested the build) the kernel module math_emu is loaded. Could it be the case that the test do not fail on my machine because of that? In older mails from this list I recognize a problem that code linked against the new libc needs math_emu enabled? Well certainly 2.6.18 kernel in Etch has math emu built in so always present. 2.6.22 has it as a module, which probably means not loaded most of the time. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RE: manipulating FPU rounding modes on alpha
Hi, I just checked once again on Uwe's machine without math_emu loaded. Now the test fails -- but in a slightly different way than on the buildd. Furthermore, the buildd ds10 is a ev6 according to www.buildd.net, thus it shouldn't need math_emu, right? Joachim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
