Created attachment 31829 [details] the test case to trigger the bug. I used the following command $gcc -Wall -Wextra -pedantic -std=c11 -c unused-var.c And GCC outputs no warnings. However in the source file unused-var.c, the last global variable "g_1853" is NOT used. ////////////////////////////// Start of the source file ///////////// /** * compile this program with the following command * * gcc -c -pedantic -std=c11 -Wall -Wextra unused-var.c */ static int g_37 = (-1L); static int *g_187 = &g_37; /** * this variable will NOT be reported although it is NOT used. */ static int ** volatile g_1853 = &g_187;/* VOLATILE GLOBAL g_1853 */ ////////////////////////////// End of the source file ///////////// The Gcc version is 4.9.0, built on 01/09/2014 gcc (GCC) 4.9.0 20140109 (experimental) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Don't mark the variable volatile then. Volatile tells the compiler the variable may be used through means not known to the compiler, so it isn't unused.
Thanks for your reply. One more question regarding this issue. Support I have a closed program static volatile int a; int main() {return 0;} Even though "a" is not read anywhere in this program, do you mean that it is still possible for "a" to be used somewhere else? I checked the C standard draft(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). In Page 122, it says that what constitutes an access to an object that has volatile-qualified type is implementation-defined. Is this the reason why GCC thinks the variable is used, but Clang treats it unused? Thanks again.
For the given code, it does seem make sense to issue a warning (whether or not "volatile" is used) because this is likely a bug in the code. $ gcc-trunk -Wunused-variable small.c $ clang-trunk -Wunused-variable small.c small.c:1:21: warning: unused variable 'a' [-Wunused-variable] static volatile int a; ^ 1 warning generated. $ cat small.c static volatile int a; int main () { return 0; } ---------------------- This also seems to be a missed optimization opportunity: $ gcc-trunk -O3 -S small.c $ cat small.s .file "small.c" .section .text.unlikely,"ax",@progbits .LCOLDB0: .section .text.startup,"ax",@progbits .LHOTB0: .p2align 4,,15 .globl main .type main, @function main: .LFB0: .cfi_startproc xorl %eax, %eax ret .cfi_endproc .LFE0: .size main, .-main .section .text.unlikely .LCOLDE0: .section .text.startup .LHOTE0: .local a .comm a,4,4 .ident "GCC: (GNU) 4.9.0 20140115 (experimental) [trunk revision 206638]" .section .note.GNU-stack,"",@progbits
*** This bug has been marked as a duplicate of bug 57258 ***
This change was done on purpose. See the patch and thread at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00847.html
> *** This bug has been marked as a duplicate of bug 57258 *** Andrew, I'm confused. The two are different, right? 57258 is about a possible extra warning, and this one is about a missing warning. What did I miss? Thanks.
Those two cases are different, the other PR was about automatic volatile variables, where if they are unused it is really hard to come up with a way how they could be modified behind compiler's back. While for this case, variable in .data/.bss etc. section it is not so hard, the variable has a name through which it can be referenced, eventhough only from within the same assembly file. User could inject some assembly which will access it, the var can use section attribute that places it into some magic section that is e.g. IO mapped, etc.
(In reply to Jakub Jelinek from comment #7) > Those two cases are different, the other PR was about automatic volatile > variables, where if they are unused it is really hard to come up with a way > how they could be modified behind compiler's back. While for this case, > variable in .data/.bss etc. section it is not so hard, the variable has a > name through which it can be referenced, eventhough only from within the > same assembly file. User could inject some assembly which will access it, > the var can use section attribute that places it into some magic section > that is e.g. IO mapped, etc. Thanks Jakub. So, this is confirmed then?
It is IMHO working correctly and looks like clang bug to me.