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
        -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

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

Reply via email to