Messages in this thread | | | Date | Sun, 02 Sep 2012 11:04:50 +0200 | From | Toralf Förster <> | Subject | does gcc gives a false warning in kernel/trace/trace_events_filter.c ? |
| |
The current git tree of linux gave with gcc-4.6.3 :
kernel/trace/trace_events_filter.c: In function ‘ftrace_function_set_filter_cb’: kernel/trace/trace_events_filter.c:2074:8: warning: ‘ret’ may be used uninitialized in this function [-Wuninitialized]
which refers to this piece of code:
2061 static int ftrace_function_set_filter_cb(enum move_type move, 2062 struct filter_pred *pred, 2063 int *err, void *data) 2064 { 2065 /* Checking the node is valid for function trace. */ 2066 if ((move != MOVE_DOWN) || 2067 (pred->left != FILTER_PRED_INVALID)) { 2068 *err = ftrace_function_check_pred(pred, 0); 2069 } else { 2070 *err = ftrace_function_check_pred(pred, 1); 2071 if (*err) 2072 return WALK_PRED_ABORT; 2073 2074 *err = __ftrace_function_set_filter(pred->op == OP_EQ, 2075 pred->regex.pattern, 2076 pred->regex.len, 2077 data); 2078 } 2079 2080 return (*err) ? WALK_PRED_ABORT : WALK_PRED_DEFAULT; 2081 } 2082
From a Gentoo forum user I got a hint :
"Maybe it's some kind of a weird inlining issue? I think it's referring to the ret in __ftrace_function_set_filter(), which would be uninitialized if the for-loop does not run (re_cnt ≤ 0)"
Now I'm wondering if re_cnt can become zero or if gcc is wrong here ?
-- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- 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/
| |