Messages in this thread |  | | | Date | Mon, 25 Jul 2011 19:50:26 -0400 | | Subject | Re: [PATCH] TRACING: Fix a copmile warning | | From | Arnaud Lacombe <> |
| |
Hi,
[adding gcc-help@ to the Cc: list]
On Mon, Jul 25, 2011 at 6:38 PM, Arnaud Lacombe <lacombar@gmail.com> wrote: > Hi, > > On Mon, Jul 25, 2011 at 4:19 PM, Steven Rostedt <rostedt@goodmis.org> wrote: >> On Mon, 2011-07-25 at 15:43 -0400, Arnaud Lacombe wrote: >> >>> Actually, we have a special uninitialized_var(x) macro to handle such >>> false positive. From include/linux/compiler-gcc.h: >>> >>> /* >>> * A trick to suppress uninitialized variable warning without generating any >>> * code >>> */ >>> #define uninitialized_var(x) x = x >> >> I'm aware of that too, but I think that is inappropriate as well. As I >> said, some versions of gcc report it, others don't. Seems that gcc 4.6.0 >> says this is an error where 4.5.1 does not (I just tried both). >> gcc will only emits the warning at -Os. It seems to me that the resulting code clearly ends-up testing an uninitialized value, ie. assuming the following test-case:
extern void *e(void); extern void *f(void); extern void g(void);
void fn(void) { void *b, *a; a = e(); if (a != 0) b = f(); if (a != 0 && b != 0) g(); } gcc 4.5.1 will generates the following x86-32 assembly:
% gcc -m32 -Wall -Os -c -S -o - kernel/trace/trace_printk.c .file "trace_printk.c" kernel/trace/trace_printk.c: In function 'fn': kernel/trace/trace_printk.c:7:8: warning: 'b' may be used uninitialized in this function .text .globl fn .type fn, @function fn: pushl %ebp movl %esp, %ebp pushl %esi pushl %ebx call e testl %eax, %eax movl %eax, %ebx je .L2 call f movl %eax, %esi .L2: testl %esi, %esi je .L1 testl %ebx, %ebx je .L1 popl %ebx popl %esi popl %ebp jmp g .L1: popl %ebx popl %esi popl %ebp ret .size fn, .-fn .ident "GCC: (GNU) 4.5.1 20100924 (Red Hat 4.5.1-4)" .section .note.GNU-stack,"",@progbits
It seems gcc transforms the conditional from:
if (a != NULL && b != NULL) ... to
if (b != NULL && a != NULL) ... In which case the warning is fully valid. I'm not sure what's the C standard guarantee in term of conditional test order. gcc 4.7.0 has the same behavior.
- Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |