Created attachment 811465 [details] raid.c Description of problem: When compiling the (soon to be) attached file with -Os, I receive the following warning: [pilcher@ian freecusd2]$ gcc -Os -W -Wall -Wextra -lpthread -c -o /dev/null raid.c raid.c: In function ‘fcd_raid_fn’: raid.c:694:20: warning: ‘array’ may be used uninitialized in this function [-Wmaybe-uninitialized] array->ideal_devs = atoi(c + matches[4].rm_so); ^ raid.c:642:25: note: ‘array’ was declared here struct fcd_raid_array *array; ^ I don't get this warning with -O0, -O1, -O2, or -O3. (array is initialized by the call to fcd_find_array at line 651; that function can be found at line 371.) Version-Release number of selected component (if applicable): gcc-4.8.1-1.fc19.x86_64
Created attachment 811466 [details] freecusd.h
See analysis in upstream bug report. Executive summary: -Os throttles certain optimizations and as a result we lose precision in the analysis in the uninitialized variable warning. This is unlikely to be fixed.
(In reply to Jeff Law from comment #2) > Executive summary: -Os throttles certain optimizations and as a result we > lose precision in the analysis in the uninitialized variable warning. > > This is unlikely to be fixed. Hmm. So it seems like the best option is to ensure that fcd_find_array really does unconditionally initialize 'array', even in the error path where it will never be used: name_len = match->rm_eo - match->rm_so; if (name_len >= FCD_RAID_DEVNAME_SIZE - 1) { FCD_WARN("RAID device name '%.*s' too long\n", (int)name_len, buf + match->rm_so); #ifdef __OPTIMIZE_SIZE__ /* See https://bugzilla.redhat.com/show_bug.cgi?id=1018422 */ *array = NULL; #endif return -1; } Is there a better alternative that I'm missing?
Seems fairly reasonable. I like that you're annotating the initialization -- there's always some chance things will change in the future and we'll have a better way to deal with this kind of problem in GCC and if you've got the "bogus" initializations marked, they're much easier to find and remove. I wish we'd done the same in GCC itself when we first decided to make it -Wuninitialized clean. Anyway, I think we'll keep the upstream report open and attach it to whatever meta bug we have for -Wuninitialized as well as the jump threading metabug so folks working in those areas will periodically review the bug.
(In reply to Jeff Law from comment #4) > Anyway, I think we'll keep the upstream report open and attach it to > whatever meta bug we have for -Wuninitialized as well as the jump threading > metabug so folks working in those areas will periodically review the bug. Sounds like a plan. Closing UPSTREAM.