Re: memset zero bytes at NULL - isolate-erroneous-paths

[OndÅej BÃlka <neleai at seznam dot cz>]

On Mon, Nov 18, 2013 at 07:24:46AM -0700, Jeff Law wrote:
> On 11/18/13 04:08, Richard Biener wrote:
> >>I'd say that turning memset (0, '\0', 0) into a trap is bad from a QOI
> >perspective.  Jeff, is there an easy way to avoid this?  Testcase:
> >
> >void fn (void *addr, int a)
> >{
> >   if (a == 0)
> >     addr = (void *)0;
> >   __builtin_memset (addr, '\0', a);
> >}
> >
> >I wonder where in isolate-paths you check for builtins at all?  ah,
> >it's probably from the nonnull attribute on memset.  Which also
> >means that trying to catch this case reliably isn't going to work
> >(you cannot prove the program has len == 0 in this case and
> >conditionally not trapping would somewhat defeat the purpose
> >of isolating this path)
> It's the nonnull attribute on memset.  One thought would split the
> optimization into two parts.  One which transforms *0 and the other
> which transforms calls/returns.  Have the former enabled by -O2 the
> latter off for now. For the next release, both enabled by default at
> -O2.
> 
> Add distinct warnings for both cases, possibly enabled by -Wall
> (depends on the noise).
> 
> That gets most of the benefit now and gives a way for users to
> identify brokenness in their code.
> 
> Sadly, this feels a lot like -fstrict-aliasing did eons ago.
> Aggressive TBAA exposed all kinds problems and it took a lot of user
> (re)education to get them fixed.
> 
You risk that when user tries to use isolate paths only to find spurious
errors like these that he will not use it even in cases where it helps.

One way would be remove nonnull attribute in mem* functions.

Note that c standard also disallows.

char *m = malloc (32);
if (!m)
  return 0;
...
int pos = 32;
return memchr (m, 42, 32 - pos);

On other hand if we could break invalid programs with impunity
one could make memchr/memcmp a cycle faster by dropping
an initial n == 0 check.