>
> Very excited to see this and the other work -- thank you!
>
> I seem to get this when testing it out:
> +Running gcc:/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
> +FAIL: gcc.dg/analyzer/pr101837.c (test for warnings, line 10)
> +FAIL: gcc.dg/analyzer/pr101837.c (test for warnings, line 5)
> +FAIL: gcc.dg/analyzer/pr101837.c (test for warnings, line 9)
>
> I can reproduce it with gcc -c -fanalyzer
> gcc/testsuite/gcc.dg/analyzer/pr101837.c -O2. Works with trunk, fails
> with patch applied on trunk. On the one hand, it's good, but it's not so
> good for the analyzer.
>
> I'll keep testing the patch.
The testcase does:
/* { dg-additional-options "-O3 -fsanitize=undefined" } */
void memory_exhausted();
void memcheck(void *ptr) {
if (ptr) /* { dg-warning "leak" } */
memory_exhausted();
}
int emalloc(int size) { memcheck(__builtin_malloc(size)); } /* { dg-message
"allocated here" } */
int main() { int max_envvar_len = emalloc(max_envvar_len + 1); } /* {
dg-message "use of uninitialized value 'max_envvar_len'" } */
so emalloc does not return its allocated memory and by optimizing it
away we optimize away the memory leak by optimizing away the allocation.
Removing the out of memory check would make us to remove the allocation
away anyway and hide the leak.
So perhaps with memory leak transform we want to disable the
malloc/free removal completely? It is bit hard to check whether
malloc will always be paired by free inside tree-ssa-dce. We woluld have
to insert fake edges and check post-dominance.
Or is it Ok to miss an error that optimizes away?
Honza
>
> thanks,
> sam
