#2286 gcc-torture-execute-20001121-1 fails when doing test-host on CubieBoard (dual-core ARMv7)

closed-fixed
Ben Shi
None
other
5
2014-08-13
2014-07-16
Ben Shi
No

While I try the auto build script on my CubieBoard following the instructions on the page http://sdcc.sourceforge.net/mediawiki/index.php, an error rises.

The error message is:
gen/host/gcc-torture-execute-20001121-1/gcc-torture-execute-20001121-1.o: In function testTortureExecute': /root/build/sdcc-build/armv7l-unknown-linux-gnueabihf.build/sdcc/support/regression/gen/host/gcc-torture-execute-20001121-1/gcc-torture-execute-20001121-1.c:28: undefined reference tobar'
collect2: ld returned 1 exit status
make[3]: [gen/host/gcc-torture-execute-20001121-1/gcc-torture-execute-20001121-1.bin] Error 1
make[2]:
[results/host/gcc-torture-execute-20001121-1.out] Error 2
make[1]: [test-port] Error 2
make:
[test-host] Error 2

If I either remove the function prefix 'inline' or change it to 'static inline', then it passes.

By checking the disassembly (the attached 101.s) of gcc-torture-execute-20001121-1.o, the inline function bar() is wiped out, but there still is a call to it (4: f7fffffe bl 0 <bar>) in testTortureExecute(), where there should be a direct code replacement.

But if I write a simple a.c:

include <stdio.h>

inline int add(int a, int b)
{
return a + b;
}
int main(int argc, char **argv)
{
int a, b;
sscanf(argv[1], "%d", &a);
sscanf(argv[2], "%d", &b);

    printf("%d", add(a, b));
    return 0;

},
and compile it by "gcc a.c -O2 -c", then my board native gcc (arm-linux-gnueabihf) keeps the add() in the a.o, and replace the call in main() with add()'s function body.

Does the build script use my native gcc or build a new one by itself? Or it is due to some compiling flags?

1 Attachments

Discussion

  • Ben Shi
    Ben Shi
    2014-07-16

    If I directly,

    configure
    make all
    make install
    cd support/regression
    make test-host

    then this .c passes.

    What is the difference between manual test and auto script test ?

     
  • Ben Shi
    Ben Shi
    2014-07-17

    I found that it is due to the "--std=c99" flag, the above a.c also fails to be compiled if "--std=c99" is specified on both my arm board and my ubuntu 12.04 PC.

    So it means that this flag is specified by the snapshot build script, but not in manually "make test-host".

    Can we change that? Why other build machines have not this problem?

     
  • Erik Petrich
    Erik Petrich
    2014-07-17

    My Mac running Lion (Mac OS 10.7.5) also fails this regression test, even with a manual "make test-host". I hadn't worried about this because it ran okay on everything else.

    I think we should change the regression test itself so that the inline function is "static inline" rather than just "inline". If the compiler is following the c99 standard, it is allowed to totally ignore non-static inline function definitions, so there is supposed to be a second (non-inline) version of the function somewhere that it can use instead. With a static inline function definition the compiler is also allowed to ignore the inline request, but if it does, it must still generate a callable function from the one definition it was given. I am fairly sure a static inline function would still work in this regression test if it's compiling in the gnu89 mode, which handles inlining differently (because it pre-dated the standard).

     
  • Ben Shi
    Ben Shi
    2014-07-17

    • assigned_to: Ben Shi
     
  • Ben Shi
    Ben Shi
    2014-07-17

    So we add a "static" to all inline functions in sdcc/support/regression/tests/*.c ?

    Before committing, is there anything else needed to do besides test-hosts and test-ports ?

    I have never touch code beyond the stm8 port.

     
  • Maarten Brock
    Maarten Brock
    2014-07-17

    You should not blindly add "static" to all inline functions. I've carefully created tests/inline.c along with fwk/lib/extern1.c and fwk/lib/extern2.c to test inline functions with external linkage.

    I'm more thinking that this regression test is both faulty and redundant and should therefor be removed. I see no reason for double testing nor for testing gcc gnu89 mode.

     
  • Ben Shi
    Ben Shi
    2014-07-17

    How about if we only change this .c ?

    I though this is the least change way, and code redundancy is not a problem, only if it is right.

     
  • Ben Shi
    Ben Shi
    2014-07-19

    I temporarily add "static"s, since this issue blocks my build-machine setup. We can delete the redundant test case in the future.

     
  • Ben Shi
    Ben Shi
    2014-07-20

    Maybe this gcc-torture-execute-20001121-1.c is a redundant case for inline test, but there are 3 more cases which are for others than inline itself, but also do not match the c99.

    So I though a unique solution adding 'static' is better.

     
  • Ben Shi
    Ben Shi
    2014-07-20

    • status: open --> closed-fixed