[#5888] bfin-uclinux-libmudflap-4.3.sum pass40-frag.c output pattern test regress
Submitted By: Mingquan Pan
Open Date
2010-02-08 02:08:39
Priority:
Medium Assignee:
Nobody
Board:
N/A Silicon Revision:
Resolution:
Assigned (Not Started) Fixed In Release:
N/A
Processor:
BF527
Host Operating System:
toolchain rev.:
trunk head 4.3 kernel rev.:
State:
Open Found In Release:
Is this bug repeatable?:
Summary: bfin-uclinux-libmudflap-4.3.sum pass40-frag.c output pattern test regress
Details:
bfin-uclinux-libmudflap-4.3.sum pass40-frag.c output pattern test regress compared with 4.1 test results.
Tests that now fail, but worked before:
bfin-uclinux: libmudflap.cth/pass40-frag.c (-O2) output pattern test
bfin-uclinux: libmudflap.cth/pass40-frag.c (-O3) output pattern test
bfin-uclinux: libmudflap.cth/pass40-frag.c output pattern test
bfin-uclinux: libmudflap.cth/pass40-frag.c (-static -DSTATIC) output pattern test
The log is:
Executing on host: bfin-uclinux-gcc -ggdb3 -DDEBUG_ASSERT -I/home/test/work/cruise/checkouts/toolchain/gcc-4.3/libmudflap/testsuite -I/home/test/work/cruise/checkouts/toolchain/gcc-4.3/libmudflap/testsuite/.. -I.. -L/.libs /home/test/work/cruise/checkouts/toolchain/gcc-4.3/libmudflap/testsuite/libmudflap.cth/pass40-frag.c -O2 -fmudflapth -lmudflapth -lpthread -Wl,--noinhibit-exec -Wl,-elf2flt=-s80000 -L/testsuite -lm -o ./pass40-frag.exe (timeout = 20)
spawn bfin-uclinux-gcc -ggdb3 -DDEBUG_ASSERT -I/home/test/work/cruise/checkouts/toolchain/gcc-4.3/libmudflap/testsuite -I/home/test/work/cruise/checkouts/toolchain/gcc-4.3/libmudflap/testsuite/.. -I.. -L/.libs /home/test/work/cruise/checkouts/toolchain/gcc-4.3/libmudflap/testsuite/libmudflap.cth/pass40-frag.c -O2 -fmudflapth -lmudflapth -lpthread -Wl,--noinhibit-exec -Wl,-elf2flt=-s80000 -L/testsuite -lm -o ./pass40-frag.exe^M
PASS: libmudflap.cth/pass40-frag.c (-O2) (test for excess errors)
Executing on bfin-uclinux: /tmp/pass40-frag.exe.23295 (timeout = 300)
Executing on bfin-uclinux: rm -f /tmp/pass40-frag.exe.23295 (timeout = 300)
Executed ./pass40-frag.exe, status 0
100 200 300 400 500 600 700 800 900 1000
1100 1200 1300 1400 1500 1600 1700 1800 1900 2000
2100 2200 2300 2400 2500 2600 2700 2800 2900 3000
3100 3200 3300 3400 3500 3600 3700 3800 3900 4000
4100 4200 4300 4400 4500 4600 4700 4800 4900 5000
5100 5200 5300 5400 5500 5600 5700 5800 5900 6000
6100 6200 6300 6400 6500 6600 6700 6800 6900 7000
7100 7200 7300 7400 7500 7600 7700 7800 7900 8000
8100 8200 8300 8400 8500 8600 8700 8800 8900 9000
9100 9200 9300 9400 9500 9600 9700 9800 9900 10000
PASS: libmudflap.cth/pass40-frag.c (-O2) execution test
FAIL: libmudflap.cth/pass40-frag.c (-O2) output pattern test
Output pattern 100 200 300 400 500 600 700 800 900 1000
Follow-ups
--- Stuart Henderson 2010-07-22 08:19:08
i swear i added a comment here.
anyway, this looks suspiciously correct. the output pattern test is failing,
but the output looks spot on to me. i'm still investigating.
--- Stuart Henderson 2010-08-05 09:59:43
It looks like tests which expect the last character of output to be a newline
fail (this is also the reason for [#6126] failing), unless there is further
output from the test. This is most likely not a problem with the toolchain so I
suggest we downgrade this to priority 3 and update the test to expect to fail
for just now. any objections?
The reason this is a regression is because in 4.1 we were getting a libmudflap
violation after all the test output, meaning there *was* a new line and the test
passed.
so the test passed when it was failing and now fails because it's passing.
--- Sonic Zhang 2010-08-09 07:10:14
Fail in both 4.1 and 4.3. Not regression bugs. Low priority. Stuart should mark
them XFAIL in test cases and defer to next release.
--- Stuart Henderson 2010-08-09 10:33:23
Updated the following tests to expect to fail:
gcc-4.3/libmudflap/testsuite/libmudflap.cth/pass40-frag.c
gcc-4.3/libmudflap/testsuite/libmudflap.cth/pass59-frag.c
--- Mike Frysinger 2010-08-09 12:31:46
there is no real point in setting tests as XFAIL. we already have a tracker
item for it as well as a wiki page where we list for each release the items
expected to fail. XFAIL is useful really only when we go sending the change
upstream.
--- Mingquan Pan 2012-06-13 06:50:20
It is now failing like this:
Executing on bfin-uclinux: /tmp/pass40-frag.exe.20177 {} {} (timeout = 300)
spawn [open ...]^M
9100 WARNING: program timed out.
Executing on bfin-uclinux: rm -f /tmp/pass40-frag.exe.20177 (timeout =
300)
XYZ0ZYX
Executed ./pass40-frag.exe, status 1
rsh to bfin-uclinux failed for /tmp/pass40-frag.exe.20177, 100 200 300 400 500
600 700 800 900 1000
9100
FAIL: libmudflap.cth/pass40-frag.c (-O2) execution test
XFAIL: libmudflap.cth/pass40-frag.c (-O2) output pattern test
...
Executing on bfin-uclinux: /tmp/pass42-frag.exe.20177 {} {} (timeout = 300)
*******
mudflap violation 1 (check/write): time=1339289204.245361 ptr=0xSEGV
XYZ139ZYX
311da3d size=1
pc=0x310f962
location=`/home/test/work/cruise/checkouts/toolchain/gcc-4.3/libmudflap/testsuite/libmudflap.c/pass42-frag.c:7:3
(foo)'
[0x0x310e8ba]
Nearby object 1: checked region begins 887B before and ends 887B before
mudflap object 0x2e2659c: name=`errno area'
bounds=[0x311ddb4,0x311ddb7] size=4 area=static check=0r/0w liveness=0
alloc time=1339289204.245304 pc=0x310f522
number of nearby objects: 1
Executing on bfin-uclinux: rm -f /tmp/pass42-frag.exe.20177 (timeout =
Executed ./pass42-frag.exe, status 1
FAIL: libmudflap.c/pass42-frag.c execution test
FAIL: libmudflap.c/pass42-frag.c output pattern test
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found