clang-analyze on RTEMS

[Ralf Corsepius]

On 09/20/2010 01:35 PM, Joel Sherrill wrote:
> On 09/19/2010 10:39 PM, Ralf Corsepius wrote:
>> On 09/20/2010 03:21 AM, Joel Sherrill wrote:
>>> Hi,
>>>
>>> I have run clang-analyze on RTEMS. Running
>>> it on the same subset we run Coverity Scan
>>> on produced no issues. I don't know if clang
>>> will turn up anything but it is another
>>> tool in the arsenal. So I tried to run it
>>> on everything and got this:
>>>
>>> checking for style of include used by gmake... GNU
>>> checking for sparc-rtems4.11-gcc...
>>> /usr/lib/clang-analyzer/scan-build/ccc-analyzer
>>> checking for sparc-rtems4.11-gcc... (cached)
>>> /usr/lib/clang-analyzer/scan-build/ccc-analyzer
>>> checking whether the C compiler works... no
>>> configure: error: in
>>> `/home/joel/rtems-4.11-work/build/gcc-testing/rtems/clang-analyzer/b-clang-sparc-rtems4.11/sparc-rtems4.11/c/sis':
>>>
>>>
>>> configure: error: C compiler cannot create executables
>>> See `config.log' for more details.
>>> gmake[2]: *** [sis] Error 1
>>> gmake[2]: Leaving directory
>>> `/home/joel/rtems-4.11-work/build/gcc-testing/rtems/clang-analyzer/b-clang-sparc-rtems4.11/sparc-rtems4.11/c'
>>>
>>>
>>>
>>> It is pretty easy to run .. just configure .. then
>>>
>>> scan-build -o output_dir make
>>>
>>> Any thoughts on why the autoconf test fails?
>> Me never having used clang and you not providing sufficient informations
>> to be able to help, only 2 general remarks:
>>
>> * General answer from the "top autoconf newbie answering templates'
>> drawer":
>>
>> Do as autoconf tells you - "See 'config.log' for details"
>>
> OK. Should have posted that. My hunch from the output matches
> what config.log (attached) shows. It tries to use ccc-analyzer as
> the compiler.
Seems so, ... and it seems to fail badly:

configure:3368: checking whether the C compiler works
configure:3390: /usr/lib/clang-analyzer/scan-build/ccc-analyzer 
-mcpu=cypress -O2 -g   conftest.c  >&5
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
conftest.c:1: error: bad value (cypress) for -mtune= switch
configure:3394: $? = 1
configure:3432: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "rtems-c-src"
| #define PACKAGE_TARNAME "rtems-c-src"
| #define PACKAGE_VERSION "4.10.99.0"
| #define PACKAGE_STRING "rtems-c-src 4.10.99.0"
| #define PACKAGE_BUGREPORT "http://www.rtems.org/bugzilla"
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }

Wild guess: This clang seems to be a native-only tool.

The error above likely originates from a native i386/x86_64-gcc:

# touch tmp.c

# gcc -mcpu=cypress -O2 -g   tmp.c
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
tmp.c:1: error: bad value (cypress) for -mtune= switch

# /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -mcpu=cypress -O2 -g   tmp.c
/opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.5.1/../../../../sparc-rtems4.11/bin/ld: 
warning: cannot find entry symbol _start; defaulting to 0000000000010074


> Attached is my script to drive this.
>> * Knowing you are building on x86_64, your log message referring to
>> /usr/lib/clang-ananlyser indicates your "clang"-package is likely
>> misconfigured/incorrectly installed.
>>
>>
> It is the RPM from Fedora 13 on my home laptop. I was killing
> some time and tried it.

So this is an i386 installation?

Except if this laptop is old or is an Atom-powered netbook, this rarly 
makes sense.

Ralf