https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.
Anyways there is no breaking of code. 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.
