https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #11 from Daniel Gutson <daniel.gutson at tallertechnologies dot
com> ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Daniel Gutson from comment #9)
> > (In reply to Marc Glisse from comment #8)
> > > (bugzilla bug that reset the component...)
> > >
> > > (In reply to Daniel Gutson from comment #6)
> > > > That's why the 'if (ptr != NULL)' should not be ignored, which
> > > > currently is.
> > > > The 'if' prevents the UB.
> > >
> > > Uh, if you consider it UB, I don't understand the problem. At runtime,
> > > either malloc succeeded and the transformation is fine, or x<=12 and the
> > > transformation is fine, or the call to memset is undefined behavior so
> > > anything is fine (including the transformation). Unless you explicitly
> > > want
> > > to catch the trap, I don't understand what you are saying. Could you
> > > detail
> > > step by step where a well-defined behavior in the original program is
> > > turned
> > > into a different behavior in the optimization?
> >
> > See this example: ('function' is same as above)
> >
> > void caller(void)
> > {
> > void* ptr = function(1);
> > *(char*)ptr = 1;
> > }
>
> Maybe file another bug which does the opposite transformation for the cases
> where memcpy happens after the calloc. There is not enough information to
> know if the value is going to be <=15 most of the time or not so we just
> guess.
Can't we use this one?
>
> Anyways there is no breaking of code.
OK, my bad.
> If you don't want this transformation
> inside a function which is called calloc, then you need to use
> -fno-builtin-malloc to disable finding of the malloc call.
Shouldn't be -fno-builtin-calloc the flag to prevent this optimization? I don't
want to disable malloc's builtin flavor everywhere else.
