On 10 March 2017 at 17:44, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
> On Fri, Mar 10, 2017 at 02:23:26PM +0000, Dibyendu Majumdar wrote:
>> Hi,
>>
>> This example fails:
>>
>> extern int (*f) (int);
>> int main(int argc, const char *argv[]) {
>> if (f) {
>> return (*f)(6);
>> }
>> }
>>
>> The linearized output is:
>>
>> main:
>> .L0:
>> <entry-point>
>> load.64 %r1(f) <- 0[f]
>> br %r1(f), .L1, .L3
>> .L1:
>> load %r3 <- 0[%r1(f)]
>> call.32 %r4 <- %r3, $6
>> br .L3
>> .L3:
>> ret.32 %r4
>>
>> It is the second load that is failing. Am investigating the cause - it
>> seems something to do with calc_memop_addr().
>
> No, it's a problem with the linearized code.
> There is no reasons for this second load to even exist.
> You can see this by replacing '(*f)(6)' by the equivalent 'f(6)'.
Okay.
>
> Also you should be careful with this example as there is no
> return for the 'else' part which create some undefined value
> which can create weirdness.
>
Yes, here is an amended test.
static int testfunc(int i) {
return i-6;
}
static int (*f) (int) = testfunc;
int main(int argc, const char *argv[]) {
if (f) {
return f(6);
}
else {
return 1;
}
}
I am creating a bunch of tests that can be run after compiling. The
current backend tests are not very useful as they do not actually run
or validate the results.
Regards
Dibyendu
--
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
