1121 2011-05-27 05:09:10 +0000 LSB 4.1: error from "abs" of math function 2013-04-12 07:33:08 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.0-alpha mpc8315e-rdb ppc VERIFIED FIXED Medium normal 1.4 M4 1 Xiaofeng.yan kai.kang brett.ciphery jessica.zhang kai.kang liezhi.yang mark.hatle meta.mr.watcher meta.watcher sgw yi.zhao --- --- --- oldest_to_newest 14046 0 Xiaofeng.yan 2011-05-27 05:09:10 +0000 /26_numerics/complex/13450.cc 1 failed Message from the test: DejaGNUTest.command_1: DejaGNUTest.command_1: /opt/lsb/test/lib/libstdcpp_4.1.0/_26_numerics_complex_13450.exe DejaGNUTest.command_1: DejaGNUTest.command_1: DejaGNUTest.command_output_1: DejaGNUTest.command_output_1: _26_numerics_complex_13450.exe: /nethome/autobuild/tmp/rpm-build/BUILD/lsb-test-libstdcpp-4.1.0/testsuite/26_numerics/complex/13450.cc:41: void test01_do(T, T) [with T = long double]: Assertion `abs(ref - res2) < eps' failed. DejaGNUTest.command_output_1: DejaGNUTest.command_output_1: DejaGNUTest.command_status_1: 6 DejaGNUTest.result_1: FAIL: 26_numerics/complex/13450.cc execution test INFO: qmtest.cause: 26_numerics/complex/13450.cc execution test INFO: qmtest.end_time: 2011-05-23T01:06:49Z INFO: qmtest.start_time: 2011-05-23T01:06:49Z INFO: qmtest.target: local 14047 1 Xiaofeng.yan 2011-05-27 05:09:42 +0000 I record this bug and will fix it on 1.1 14107 2 169 Xiaofeng.yan 2011-05-31 23:38:02 +0000 Created attachment 169 test program about data type long double 14108 3 Xiaofeng.yan 2011-05-31 23:50:28 +0000 Hi Mark, This bug is caused by data type "long double". Please check attachment to get test program. Look at my test steps $./powerpc-poky-linux-g++ abs.cc -o abs -g mpc8315e#./abs c When I run this program on x86 (OS ubuntu), I got information "a" instead of "c". The correct result should be "a". if the type of variable "ld1" and "ld2" is "long" or "double", output information is "a" on mpc8315e. I think it is float-precision problem. I don't know this bug comes from hardware or complication tool or glibc? Can you give me suggestion about my question? I have checked that mpc8315e supports hard-float. TARGET_CC_ARCH = "-mcpu=603e -mhard-float" The following information come from gdb test01_do<long double> (a=-3.2000000000000002, b=1.3999999999999999) at abs.cc:11 11 bool test __attribute__((unused)) = true; (gdb) n 14 T eps = numeric_limits<T>::epsilon() * 100; (gdb) n 16 cplx ref = pow(cplx(a, T()), cplx(b, T())); (gdb) n 17 cplx res1 = pow(a, cplx(b, T())); (gdb) n 18 cplx res2 = pow(cplx(a, T()), b); (gdb) n 20 assert (abs(ref - res1) < eps); (gdb) p ref $1 = {_M_value = -1.5746800804295207 + -4.8463669598557395 * I} (gdb) p res1 $2 = {_M_value = -1.5746800804295207 + -4.8463669598557395 * I} (gdb) p res2 $3 = {_M_value = -1.5746800804295207 + -4.8463669598557395 * I} (gdb) p eps $4 = 4.9406564584124654e-322 (gdb) n 21 assert( abs(ref - res2) < eps ); (gdb) p eps $5 = 4.9406564584124654e-322 (gdb) p ref $6 = {_M_value = -1.5746800804295207 + -4.8463669598557395 * I} (gdb) p eps $7 = 4.9406564584124654e-322 (gdb) p ref $8 = {_M_value = -1.5746800804295207 + -4.8463669598557395 * I} (gdb) p res1 $9 = {_M_value = -1.5746800804295207 + -4.8463669598557395 * I} (gdb) p res2 $10 = {_M_value = -1.5746800804295207 + -4.8463669598557395 * I} (gdb) p ref $11 = {_M_value = -1.5746800804295207 + -4.8463669598557395 * I} (gdb) n abs: abs.cc:21: void test01_do(T, T) [with T = long double]: Assertion `abs(ref - res2) < eps' failed. Program received signal SIGABRT, Aborted. 0x0fe55e9c in raise () from /lib/libc.so.6 14112 4 Xiaofeng.yan 2011-06-01 05:30:09 +0000 Hi Mark, I also check the user manual of e300 core. It says single-precision(32bits) and double-precision(64 bits) can be supported but I don't know whether quad-precision(128 bits) is supported or not? I can't find this words. I also run this test binary on wind river ppc(e440) platform and get same result. I guess it could be real hardware problem. At present wind river makes lsb test by LSB 4.0. We use LSB 4.1 to make lsb test for yocto. 14121 5 brett.ciphery 2011-06-01 11:01:15 +0000 This looks like an acknowledged upstream bug: http://bugs.linuxbase.org/show_bug.cgi?id=2447 So it's not necessary to fix anything, the problem will be waived. 14470 6 Xiaofeng.yan 2011-06-29 04:40:22 +0000 upstream http://bugs.linuxbase.org/show_bug.cgi?id=2447 26691 7 kai.kang 2012-10-18 07:37:44 +0000 Libstdc++ test aborted on ppc, so can't verify this on ppc. Pass on x86 and x86_64 30019 8 kai.kang 2013-02-22 07:36:57 +0000 Test passed with "lsb-test-libstdcpp v. 4.1.0-18.lsb4 " 32027 9 yi.zhao 2013-04-12 07:33:08 +0000 Verified with 1.4 M5 RC3. Git rev: master/fe336b149552b1f4f24d979c40302653298b98cc 169 2011-05-31 23:38:02 +0000 2011-05-31 23:38:02 +0000 test program about data type long double abs.cc text/x-c++src 700 Xiaofeng.yan I2luY2x1ZGUgPGNvbXBsZXg+CiNpbmNsdWRlIDxsaW1pdHM+CiNpbmNsdWRlIDxjc3RkbGliPgoj aW5jbHVkZSA8YXNzZXJ0Lmg+CiNpbmNsdWRlIDxzdGRpby5oPgoKdGVtcGxhdGU8dHlwZW5hbWUg VD4KICB2b2lkIHRlc3QwMV9kbyhUIGEsIFQgYikKICB7CiAgICB1c2luZyBuYW1lc3BhY2Ugc3Rk OwogICAgYm9vbCB0ZXN0IF9fYXR0cmlidXRlX18oKHVudXNlZCkpID0gdHJ1ZTsKICAgIHR5cGVk ZWYgY29tcGxleDxUPiBjcGx4OwoKICAgIFQgZXBzID0gbnVtZXJpY19saW1pdHM8VD46OmVwc2ls b24oKSAqIDEwMDsKCiAgICBjcGx4IHJlZiA9IHBvdyhjcGx4KGEsIFQoKSksIGNwbHgoYiwgVCgp KSk7CiAgICBjcGx4IHJlczEgPSBwb3coYSwgY3BseChiLCBUKCkpKTsKICAgIGNwbHggcmVzMiA9 IHBvdyhjcGx4KGEsIFQoKSksIGIpOwoKICAgIGlmIChhYnMocmVmLXJlczIpIDwgZXBzICkKICAg ICAgICBwcmludGYoImFcbiIpOwogICAgZWxzZSBpZihhYnMocmVmLXJlczIpID09IGVwcykKICAg ICAgICBwcmludGYoImJcbiIpOwogICAgZWxzZQogICAgICAgIHByaW50ZigiY1xuIik7CiAgfQoK CmludCBtYWluKCkKewogICAgbG9uZyBkb3VibGUgbGQxOwogICAgbG9uZyBkb3VibGUgbGQyOwog ICAgbGQxID0gLTMuMmw7CiAgICBsZDIgPSAxLjRsOwogICAgdGVzdDAxX2RvKGxkMSwgbGQyKTsK ICAgIHJldHVybiAwOwp9Cg==