4854 2013-07-16 09:01:22 +0000 floor call (from math.h) is broken on qemuppc 2013-10-07 13:39:15 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 1.5 x86 Multiple VERIFIED FIXED Medium+ normal 1.5 1 sstncr raj.khem bruce.ashfield elizabeth.flanagan jessica.zhang meta.mr.watcher meta.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 34592 0 sstncr 2013-07-16 09:01:22 +0000 poky commit: 74e403705e25afec656b5e40921771a9c29bdc40 1. Given 3 core-image-sato-sdk images for qemuarm, qemux86-64 and qemuppc and the following test.c file: ---cut here--- #include <stdio.h> #include <math.h> int main(int argc, char * argv[]) { double f = 1234.67; printf("floor(%f) = %f\n", f, floor(f)); return 0; } ---and here---- 2. copy the test.c file on the target and run on the target: gcc test.c -lm -o test ./test 3. The output will be: - on qemux86-64 and qemuarm: floor(1234.670000) = 1234.000000 - on qemuppc: floor(1234.670000) = 1235.000000 Now according to the floor man page: "floor, floorf, floorl - largest integral value not greater than argument These functions return the largest integral value that is not greater than x. For example, floor(0.5) is 0.0, and floor(-0.5) is -1.0" So, that's clearly broken on qemuppc. I haven't tested this with adt-installer nor meta-toolchain. 34646 1 raj.khem 2013-07-17 14:57:26 +0000 This works fine on real ppc(p2020) hardware. Could be qemu problem. 34651 2 raj.khem 2013-07-17 21:29:38 +0000 another data point is that it works fine with uclibc/qemuppc now I wonder if it has to do with the machine 603e that we tune eglibc for when building it for qemuppc and the machine we use in qemu emulation which is G4/ppc7xxx, uclibc does not have any machine specific knowledge when it comes to these two ppc variants. 34766 3 sgw 2013-07-22 20:14:04 +0000 *** Bug 4891 has been marked as a duplicate of this bug. *** 34910 4 bruce.ashfield 2013-07-25 15:15:35 +0000 khem: are we seeing the same thing with softfloat or turn on math emulation in the kernel ? I haven't checked if that's even possible for our mac99, but wanted to toss that out. We've seen plenty of softfloat -> math emu -> exception handling issues in the past with e500 cores, and this sounds similar. 35245 5 sgw 2013-08-01 06:40:42 +0000 Where are we with this issue, it's a very visible failure on the Autobuilder due to the new sanity tests. I am not sure if this needs an updated tune or changes to eglibc, Khem can you please let us know so we can have someone else look into it if needed. Thanks 35249 6 raj.khem 2013-08-01 06:48:45 +0000 (In reply to comment #5) > Where are we with this issue, it's a very visible failure on the Autobuilder > due to the new sanity tests. I am not sure if this needs an updated tune or > changes to eglibc, Khem can you please let us know so we can have someone > else > look into it if needed. Someone could play with tunings as I have suggested so to check if its not the mismatch between tunings and qemu emulation mode. Rule out tuning mismatch from suspects. Try using older 1.4.x qemu and see if it fails consistently there too rule out qemu from suspects. Other track is to is to look into eglibc's implementation itself I cant look into it this week but someone beats me to it all the better > > Thanks 35310 7 sgw 2013-08-01 23:39:14 +0000 More data, I build master and dylan today and ran master against 1.4 qemu and 1.4 against master qemu (criss-cross). 1.4 Qemu with 1.4 Image = Good 1.4 Qemu with 1.5 Image = Good 1.5 Qemu with 1.4 Image = Bad 1.5 Qemu with 1.5 Image = Bad So the winner is something changed in the current version of Qemu, I am going to try a quick and dirty update to qemu_git. More info later. 35312 8 sgw 2013-08-02 02:10:47 +0000 OK, bisect of qemu show this commit in qemu, this is as far as I can take this, I need someone with more PPC and Qemu know how to take this further 7d08d85645def18eac2a9d672c1868a35e0bcf79 is the first bad commit commit 7d08d85645def18eac2a9d672c1868a35e0bcf79 Author: Aurelien Jarno <aurelien@aurel32.net> Date: Sat Apr 20 08:56:22 2013 +0000 target-ppc: add support for extended mtfsf/mtfsfi forms Power ISA 2.05 adds support for extended mtfsf/mtfsfi form, with a new W field to select the upper part of the FPCSR register. For that the helper is changed to handle 64-bit input values and mask with up to 16 bits. The mtfsf/mtfsfi instructions do not have the W bit marked as invalid anymore. Instead this is checked in the helper, which therefore needs to access to the insns/insns_flags2. They are added in the DisasContext struct. Finally change all accesses to the opcode fields through extract helpers, prefixed with FP for consistency. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Alexander Graf <agraf@suse.de> 35431 9 sgw 2013-08-06 15:38:02 +0000 This issue exists in the 3.10 kernel also, I tested with the latest linux-yocto-dev branch (AUTOREV'ed) 35666 10 raj.khem 2013-08-15 05:55:34 +0000 At this point its most likely a QEMU regression, since the eglibc/floor() function works fine on real h/w I did a static compile of binary to make sure it uses the same floor() function which fails on qemu. I have initiated discussion on with qemu developers on this. 35669 11 raj.khem 2013-08-15 13:58:51 +0000 The proposed patch works and thefore I have added it to qemu and sent out the patch on oe-core ml. 35823 12 sgw 2013-08-21 17:41:13 +0000 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2a48e9007cc92fedfdb6919411859fb943eacc94 37686 13 sstncr 2013-10-07 13:39:15 +0000 Marked as Verified.