On Sun, Aug 06, 2017 at 07:18:20PM +0100, Dibyendu Majumdar wrote: > On 6 August 2017 at 19:15, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > On Sun, Aug 6, 2017 at 7:58 PM, Dibyendu Majumdar > > <mobile@xxxxxxxxxxxxxxx> wrote: > >> On 6 August 2017 at 18:45, Luc Van Oostenryck > >> <luc.vanoostenryck@xxxxxxxxx> wrote: > >>> On Sun, Aug 6, 2017 at 7:04 PM, Dibyendu Majumdar > >>> <mobile@xxxxxxxxxxxxxxx> wrote: > >>>> Wouldn't have thought so - as the variable is not initialized at the > >>>> point of declaration. The assignment occurs after declaring the struct > >>>> variable s3. > >>> > >>> IIRC, this patch was written specifically for the case you reported here. > >>> > >>>> I haven't tried that patch though. > >>> > >>> You'll need the full series: > >>> https://github.com/lucvoo/sparse/tree/fix-bitfield-init-v3 > >>> > >> > >> I will have a look at it. I did report separately the issue of not > >> zeroing out structs when they are initialized and the change you > >> mentioned earlier looks more for addressing that issue. > > > > Indeed. > > I mixed up both (or more exactly, I thought it solved both). > > > > The tests in your tree all are for initialization scenario - are you > sure you fixed the issue mentioned in this thread? I will check later > tonight and report back. No no. By "Indeed, I mixed up both" I meant that you're right and that this patch doesn't solve your issue here. The issue here is a problem of (partially)-uninitialized var (only s3.onebit is initialized but the whole s3 is first read) coupled by some missing simplification of masking operation. When using a version that handle more correctly uninitialized vars, we get the following: foo: .L0: <entry-point> and.32 %r2 <- UNDEF, $-65 or.32 %r3 <- %r2, $64 lsr.32 %r4 <- %r3, $6 cast.1 %r5 <- (32) %r4 cast.32 %r6 <- (1) %r5 setne.32 %r7 <- %r6, $1 ret.32 %r7 The UNDEF is for the load of s3 and the masking should get rid of it but doesn't (yet). -- Luc -- 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
