public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jimfr06 at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/54544] Option -Wuninitialized does not work as documented with volatile Date: Tue, 11 Sep 2012 16:42:00 -0000 [thread overview] Message-ID: <bug-54544-4-yj42wJhj7L@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-54544-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54544 Zakhar <jimfr06 at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | --- Comment #3 from Zakhar <jimfr06 at gmail dot com> 2012-09-11 16:41:43 UTC --- On second thoughs, I reopen the issue! WHY: --- The 'correction' of the code above is a contrary to what the function intended to do and thus breaks its logic: the declaration in the second version of the code are inconsistent with what the function was intented to. That is because, I suppose, the message gcc delivers and its correction are not OK with what really happens. FURTHER EXPLANATIONS: --------------------- You are right Andrew, the variable 'bar' is indeed (first version of the code) a 'pointer to a volatile memory location' (location of an int). *And that was intended so*. The code is a simplification of a 'memory protection algorithm' where the int that is pointed represents the count of threads using a given piece of memory. This count being accessed from several threads, is indeed volatile as no thread can assume the value didn't change from last time it read/wrote the value. (atomic instructions where removed from the code example). The pointer itself is not at all volatile. Anyway, once it is passed to the function, it sits on the stack where its value should be unchanged as long a the function lives, and same goes for the 'bar' automatic variable. I'm not doing crazy threaded things on variables on the stack of this function! I was confused by the warning message saying: 'bar' may be used uninitialized in this function ... because the message is indeed confusing. 'bar' is NOT used uninitialized (as demonstrated) but the *content pointed by 'bar'* could be. I must confess that I didn't look from far enough to interpret the message this way. HYPOTHESIS: ----------- So could it be that gcc saw that, and warns incorrectly on 'bar' instead of '*bar'? If so, yes, because the function receives a pointer to a memory location, the function itself cannot know whether the location pointed to was initialized or not. 'bar' gets the same address ( bar = p ) thus, indeed, the location pointed by 'bar' could be un-initialized. This could also be coherent with the fact that when we change the function to static, the warning disappears. Being static, all the callers have to be on the same source, thus the compiler can check if the callers initialize properly the content memory pointed to. But then, shouldn't the message be: '*bar' may be used uninitialized in this function. And that would indeed be correct, because '*bar' being the memory pointed to by bar, could indeed be un-initialized (if the caller didn't initialize it). And thus, the compiler would do a good job signaling that, as '*bar' (memory which bar points to) is declared as volatile, but it is NOT an automatic variable (the pointer is, not the memory pointed to). My hypothesis is probably wrong, because if gcc warned about un-initialized memory pointed to, it would have to warn on that: /*01*/ int /*02*/ foo( p ) /*03*/ int *p; /*04*/ { /*05*/ int foobar; /*06*/ /*07*/ foobar= *p; /*08*/ /*09*/ return foobar + 2; /*10*/ } (we don't know if '*p' has ever been initialized). And this short code snipet produces no warning at all, which is fine because a lot of code do that (passing variable 'by reference'), and it is perfectly correct not to warn. CONCLUSION: ---------- As previously concluded, it is not strictly a 'bug' as the documentation perfectly states that in some case the dectection is broken, but I assume this issue can go in the general thread "better wuninitialized". - either gcc saw that '*bar' is uninitialized and should report that (and not report the pointer instead) - or gcc saw 'bar' (the pointer) to be unitialized, and that is a test case where it can do better work, as we can demonstrate it IS initialized. VERSION 3 of the code: --------------------- Of course, NOT to break my program logic, the correct declaration of the variable should be: /*09*/ volatile int * volatile bar; The 1st 'volatile' because indeed the memory we point to MUST be declared as volatile. The 2nd 'volatile' to suppress the 'false positive' detection on the pointer. QUESTION @Andrew: ---------------- Should I post something on the general thread "better wuninitialized" (unless my deductions are wrong again), or do you attach the use case directly from this bug report?
next prev parent reply other threads:[~2012-09-11 16:42 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-09-10 21:19 [Bug c/54544] New: " jimfr06 at gmail dot com 2012-09-10 21:23 ` [Bug middle-end/54544] " pinskia at gcc dot gnu.org 2012-09-10 21:33 ` jimfr06 at gmail dot com 2012-09-11 16:42 ` jimfr06 at gmail dot com [this message] 2012-09-11 21:09 ` jimfr06 at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-54544-4-yj42wJhj7L@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).