Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> ...The
> ((optimize("-fno-optimize-sibling-calls"))) attribute is needed on
> platforms with GCC to ensure that the stack frame for
> alloc_lock_file() is not replaced by the stack frame for xcalloc().
Hmm, I am getting
cc1: warnings being treated as errors
lockfile.c:189: error: 'optimize' attribute directive ignored
make: *** [lockfile.o] Error 1
from this patch with gcc (Debian 4.3.2-1.1) 4.3.2
Aren't "struct lock_file" instances supposed to be reachable from the
linked list, i.e. lock_file_list? Why does valgrind consider that
elements on that list are leaked in the first place?
We keep loaded objects in *obj_hash[] and they sure are "leaked" by the
same definition of leakage, no? How are we squelching valgrind on them?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html