On Sat, Mar 11, 2017 at 06:08:04PM +0000, Dibyendu Majumdar wrote:
> On 11 March 2017 at 15:51, Luc Van Oostenryck
> <luc.vanoostenryck@xxxxxxxxx> wrote:
> > On Sat, Mar 11, 2017 at 10:10:27AM -0500, Jeff Garzik wrote:
> >> On Sat, Mar 11, 2017 at 9:16 AM, Dibyendu Majumdar
> >> <mobile@xxxxxxxxxxxxxxx> wrote:
> >> > I still think pseudo values should have a type - then we won't need
> >> > all the complexity!
> >>
> >> Yep, agreed - giving pseudos a type is both natural and intentional -
> >> it is a natural outcome of the operation, and should be available
> >> without any further lookups. Giving pseudos a type actually
> >> simplifies complexity and makes tree manipulation (optimizer) easier.
> >>
> >> ...of course we need to maintain that type information correctly in
> >> all cases and through all transformations...
> >
> > OK. The mini-serie I just posted *should* give (correct?) type
> > information to all PSEUDO_VALs.
> >
> > Dibyendu, can you look if we can make good use of it?
> >
>
> Sure. We may need to rework some of the previous changes but one case
> comes straight to mind - that of variadic functions such as printf.
Yes, two patches from series can be dropped.
But there is still some bad issues that remains,
for example pointer subtraction with NULL and some
optimization that destroy correct typing info.
They're bad enough to make me doubt of the value of this change.
Here are some failing cases:
#define NULL ((void *)0)
int tst(int *ip) { return !ip; }
int foo(int *ip) { return ip != NULL; }
long bar(void *vp) { return vp - NULL; }
long baz(int *ip) { return ip - ((int *)0); }
For variadic functions, this is yet another story.
-- 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
