This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/67618] malloc+memset optimization breaks code
- From: "daniel.gutson at tallertechnologies dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 17 Sep 2015 20:11:11 +0000
- Subject: [Bug middle-end/67618] malloc+memset optimization breaks code
- Auto-submitted: auto-generated
- References: <bug-67618-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #6 from Daniel Gutson <daniel.gutson at tallertechnologies dot com> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Daniel Gutson from comment #4)
> > (In reply to Andreas Schwab from comment #3)
> > > Trying to read the (uninitialized) contents of the allocated memory for x <=
> > > 12 would be undefined behaviour, so calling calloc instead does not change
> > > the defined behaviour.
> >
> > Why do you assert that the program will read the memory?
>
> It does not. It just optimizes the code.
I meant: how do you know what the program will do next? Maybe it will write
memory. See below please.
>
> > The optimization ignores the 'if' statement (just comment that line and
> > see), so if malloc() returns NULL, memset is called unconditionally and will
> > try to write to address NULL. The "x > 12" was just an example that this is
> > arbitrary. Replace it with something else. The 'if' shall not be ignored.
>
> yes that just undefined behavior when invoking memset with a NULL value, so
> replacing it is still fine.
That's why the 'if (ptr != NULL)' should not be ignored, which currently is.
The 'if' prevents the UB.
>
> Also calloc is sometimes faster than a malloc/memset due to knowing if the
> kernel will zero out the memory, etc.
This is not under discussion.