Bug 1185673
| Summary: | -Wclobber produces useless, incorrect warnings for setjmp/longjmp hazards | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Tom Lane <tgl> | ||||
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | qe-baseos-tools-bugs | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.6 | CC: | law, mfranc, mpolacek | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-02-12 14:36:32 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Note that the test program is stripped down as much as possible. If you want to complain that the external functions couldn't cause such a longjmp for lack of access to jbuf, save your breath: in the real application where I'm seeing this type of problem, they definitely do have access. (For the record, the test case is stripped down from an actual missing-volatile-marker bug in Postgres 9.4.0. But investigation says that gcc's clobber warnings have been pretty divorced from reality as far back as 2.95.3.) -Wclobbered warns about vars and arguments at risk, those that are live across the setjmp and live in registers. fd in this case is allocated to memory (because it is live across several calls), and therefore not a problem. Yes, it's in memory, but the optimizations I mentioned make the code unsafe, so I need the warning to tell me to put "volatile" on the variable declaration. Also, the bigger picture here is that we would like gcc to warn about non-spec-compliant code of this type, even if the code gcc chooses to generate is not at risk. We develop mostly with gcc but we expect the code to run on non-gcc compilers; so a missing "volatile" poses a risk of bad code generation on other compilers even if gcc generated code that works fine. In any case, filing a request against RHEL6 doesn't make much sense, we definitely can't change what gcc produces with existing warning flags for warnings in released versions of gcc - many people use -Werror and any such changes could break their code. Well, how to respond to this bug report is your decision. I would be satisfied if there were a long-run solution (ie, something in the next gcc release). Tom, We're going to track this issue directly upstream rather than in Red Hat's BZ since the work necessary for this enhancement needs to first occur upstream. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65041 |
Created attachment 983991 [details] Test program demonstrating two misbehaviors of -Wclobbered warnings Description of problem: I wish that -Wclobbered would warn me about code that fails to meet the restrictions specified for safe use of setjmp/longjmp, namely (quoting from longjmp man page) The values of automatic variables are unspecified after a call to longjmp() if they meet all the following criteria: * they are local to the function that made the corresponding setjmp(3) call; * their values are changed between the calls to setjmp(3) and longjmp(); and * they are not declared as volatile. -Wclobbered is advertised as meeting this need, but it not only fails to warn about unsafe situations, but it generates useless warnings about perfectly safe situations. Version-Release number of selected component (if applicable): gcc-4.4.7-11.el6.x86_64 (also observed on current Fedora 20, gcc 4.8.3) How reproducible: 100% Steps to Reproduce: Compile the attached test program with "gcc -Wall -Wclobbered -O2 -c setjmptest.c" Actual results: setjmptest.c:15: warning: variable 'a2' might be clobbered by 'longjmp' or 'vfork' Expected results: I should get a warning about fd (which is at risk) and not about a2 (which is not). Additional info: The compiled code is evidently optimized on the assumption that someotherfunc() cannot cause transfer of control into the else-block: the assignment "fd = -1" is removed, and so is the "if (fd >= 0)" test. I am not whining about that: I am whining about the compiler's failure to warn me that it might do this.