http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56301
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-18
12:48:13 UTC ---
I don't see how this is a bug.
job_64 = job_new (class_39, "");
# DEBUG job => job_64
if (job_64 == 0B)
goto <bb 43>;
else
goto <bb 44>;
<bb 43>:
# DEBUG __fmt => "BAD: wrong value for %s, got unexpected %p\n\tat %s:%d
(%s).\n"
__printf_chk (1, "BAD: wrong value for %s, got unexpected %p\n\tat %s:%d
(%s).\n", "job", 0B, "tests/test_job.c", 111, &__FUNCTION__);
abort ();
<bb 44>:
D.9269_65 = job_64->pid;
*D.9269_65 = pid_49;
that was the last use of the memory pointed to by job_64 (job_new is marked as
malloc). In fact, job_64->pid is uninitialized! To quote the documentation
of the malloc attribute:
@item malloc
@cindex @code{malloc} attribute
The @code{malloc} attribute is used to tell the compiler that a function
may be treated as if any non-@code{NULL} pointer it returns cannot
alias any other pointer valid when the function returns and that the memory
has undefined content.
This will often improve optimization.
Standard functions with this property include @code{malloc} and
@code{calloc}. @code{realloc}-like functions do not have this
property as the memory pointed to does not have undefined content.
it appears that the returned memory does not have undefined contents.
