On Sun, 2008-07-06 at 22:33 +0100, David Given wrote:
> I've found a couple of places where sparse behaves rather oddly.
>
> Firstly, if you declare something static, and then try to define it
> later, sparse appears to get confused:
>
> ---snip---
> static int i;
> int i = 0;
> ---snip---
>
> $ ./test-parsing test.c
> test.c:2:5: warning: symbol 'i' was not declared. Should it be static?
>
> .align 4
> int static [signed] [toplevel] i,
> .align 4
> int [signed] [addressable] [toplevel] i =
> movi.32 v1,$0
>
> Enumeration of the list of defined symbols shows two different symbols
> with the name 'i'. This isn't entirely obvious when using the test tools
> as, of course, two strings with the same value look the same! This is
> causing me issues with forward declarations of static functions:
>
> static void foo();
> { ... foo(); ... } // calls static foo
>
> foo() {} // defines extern foo
> { ... foo(); ... } // calls extern foo
>
> This then leads to link errors as static foo hasn't been found.
I've observed this problem before. Alexey Zaytsev reported this as
well. I think he may have a fix in the works. Alexey?
> The second issue is with the following piece of C99 code:
>
> ---snip---
> extern void nop(void)
> void bar(void)
> { for (int i=0; i<10; i++) nop(); }
> ---snip---
>
> $ ./test-linearise test.c
> test.c:3:6: warning: symbol 'bar' was not declared. Should it be static?
> bar:
> .L0xb7d7600c:
> <entry-point>
> br .L0xb7d76038
>
> .L0xb7d76038:
> call nop
> br .L0xb7d76038
>
> The for loop seems to silently turn into an infinite loop. Which did
> cause one of my benchmarks to, um, produce rather poor results...
No kidding. An interesting bug. Does this go away if you declare "int
i" at the top of the function?
> (You may be interested to know that my compiler is now producing
> working, running code for non-trivial apps. Big chunks of it do need
> throwing away and rewriting, but it's actually *working*!)
Awesome!
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
