Hi, compiling the latest release 0.5.1 (as well as from git) with gcc-4.2.4 on zenwalk (slackware current), ectest fails; using gcc-3.4.6 all tests succeeds. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20081220/68be24c8/attachment-0002.htm
Rob Til Freedmen wrote:> Hi, > compiling the latest release 0.5.1 (as well as from git) with gcc-4.2.4 > on zenwalk (slackware current), > ectest fails; using gcc-3.4.6 all tests succeeds.I'm looking at the log you posted at: http://zenwalk.pinguix.com/user-accounts/tilderb/extra/celt/celt-gcc-4.2.4-error.log Is this the complete log, or did you cut it short?
Rob Til Freedmen wrote:> Hi, > compiling the latest release 0.5.1 (as well as from git) with > gcc-4.2.4 on zenwalk (slackware current), > ectest fails; using gcc-3.4.6 all tests succeeds.That's strange. The package cannot compile with GCC 3.4.6, as that version does not understand the use of -fvisibility, which is a recent addition to GCC. However, I'm not sure of the revision at which -fvisibility was first added. Regards, Steve
Rob Til Freedmen wrote:> cut after some 'Decoded 0 instead of 1 with ft of 2. ' linesI mostly wanted to see if it got any errors after "Testing random streams...", but my compilation of gcc 4.2.4 has finished and I can now reproduce the problem, and it's our fault. This would have been a nasty one to find ourselves, since it's caused by undeterministic behavior of an x86 instruction, so thank you very much for the report. The test case is covering more cases than libcelt actually uses, so the problem is not a real problem (i.e., your build of libcelt should still be okay). However, try applying the following patch in libcelt and let me know if it fixes the problem: --- entdec.c.orig 2008-12-20 21:52:22.000000000 -0500 +++ entdec.c 2008-12-20 21:52:42.000000000 -0500 @@ -107,7 +107,7 @@ int ftb; t=0; _ft--; - ftb=EC_ILOG(_ft); + ftb=EC_ILOG(_ft)&-!!_ft; if(ftb>EC_UNIT_BITS){ ftb-=EC_UNIT_BITS; ft=(unsigned)(_ft>>ftb)+1; In a future release, we will instead change the test case and add the appropriate celt_assert() checks to ensure our assumptions are not violated here.
Rob Til Freedmen wrote:> Yep, "All 8 tests passed"Great. Jean-Marc, attached is a patch to remove support for encoding the value 0 in the range [0,1) using 0 bits. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-ectest-to-not-check-a-case-which-isn-t-guarantee.patch Type: text/x-patch Size: 2709 bytes Desc: not available Url : http://lists.xiph.org/pipermail/opus/attachments/20081220/0eef504e/attachment-0002.bin
Timothy B. Terriberry a ?crit :> Rob Til Freedmen wrote: >> Yep, "All 8 tests passed" > > Great. Jean-Marc, attached is a patch to remove support for encoding the > value 0 in the range [0,1) using 0 bits.Thanks for the patch, it's pushed now. I think we can live without the ability to encode no information using no bits. Jean-Marc