On 03/12/18 06:19, Andrew Sadek wrote:
On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager <ea...@eagerm.com <mailto:ea...@eagerm.com>> wrote:On 03/02/2018 08:12 AM, Andrew Sadek wrote: Hello Michael, I tried running the whole GCC test suite on the current head (without my patch) along with 'microblaze-qemu' but I have the following problems: 1) The test is hanging at 'gcc.c-torture/string-large-1.c' , the gcc is making a 100% CPU usage and the machine stucks. I tried compiling the file alone, it generated a couple of warnings than it hangs. warning: '__builtin_memchr' specified size 4294967295 exceeds maximum object size 2147483647 [-Wstringop-overflow=] vp1 = __builtin_memchr (a, b, SIZE1); Is it a bug? Is there something wrong with my configuration ? GCC configured with options : --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --enable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-target-optspace --disable-nls --enable-multiarch --enable-languages=c,c++ Your configuration is more complex than my hard-metal target version, but it looks reasonable. The problem with string-large-1.c does appear to be a bug. You can add a line to the test case which will mark it as known failure for MB: /* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */ (I have not tested this, but it should work. Compare with other xfail's.)Problem that the whole compile package is invoked with '-w' which inhibits all warnings and overrides ' -Werror' as well as ' -Wfatal-errors' . As a result, the warning message does not appear when running compile.exp. Any suggestions ? Do I remove the '-w' ?2) For running QEMU, I have no problem with elf execution. But I do not know how to auto terminate the QEMU itself as it remains up even after program execution. Is there some command to be passed to QEMU in order make system shut down after program termination with its exit code ? Yes, this is a problem. For other targets using QEMU I have added dummy HLT instructions to terminate QEMU, or used a wrapper around QEMU which sets breakpoints at exit (or _exit) and stops the simulator when hit. If you are running Linux on QEMU, instead of using QEMU's built-in gdb interface you might use the Linux system as the target for the test suite, running gdbserver on the target.I have finally managed to fully run QEMU with test suite but had to make a local modification in the QEMU code itself. In the translate function, I make a check if "bri 0" is reached which is the '_exit'. Then, abort the QEMU app with the exit code stored in 'r5'.
I've done essentially the same for other targets.
Here are the results below: _Without Patch:_ === gcc Summary === # of expected passes90776 # of unexpected failures 1317 # of unexpected successes3 # of expected failures207 # of unresolved testcases115 # of unsupported tests2828 _With Patch and after adding my test case:_ === gcc Summary === # of expected passes90790 # of unexpected failures1317 # of unexpected successes3 # of expected failures207 # of unresolved testcases115 # of unsupported tests2828
This appears to be reasonable results. It appears that there are no regressions.
Please send me the mb-gcc command line options for both of these test runs. -- Michael Eager ea...@eagerm.com 1960 Park Blvd., Palo Alto, CA 94306
