On Mon, Aug 21, 2017 at 9:42 AM, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
> On Mon, Aug 21, 2017 at 2:26 PM, Christopher Li <sparse@xxxxxxxxxxx> wrote:
>> On Sun, Aug 20, 2017 at 6:16 PM, Luc Van Oostenryck wrote:
>>
>> With this applied, sparse still have a bug at did not match the
>> value to the bit field member, right? I saw on the other email
>> thread said the value always pick offset zero.
>
> I'm not sure to understand.
> Have you an example?
I am referenitng to your email reply to Dibyendu:
===========================
It's a very surprising bug. It's not a linearization or
an optimization bug as the AST is already wrong.
With a simpler test case, like:
struct s {
char a:4;
char b:4;
};
int foo(void)
{
struct s x = { .a = 2, .b = 4 };
return x.b;
}
you can see that the linearization produce correct
code for the initializer.
You can also see that the return statement to be
linearized is something like
STMT_RETURN
ret_value: EXPR_VALUE (value = 2)
===========================
>
> Wait for the pull request, please.
>
Sure. Glad that I asked :-)
>
> Well ..., if we have an EXPR_FVALUE which type is a bitfield, yes
> for sure there would be a bug. But I have no reason to belive there
> is such bug and since checking the ctype is more costly than checking
> the expr->type, I think it's best so.
>
> Note, I find this check already annoying and hackish if not worse.
>
Yes, from your other email said there is a bug some where else
in sparse yet. (the text I quote you).
Chris
--
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
