Description of problem: Converting true to an int must yield the value 1, according to the standard. The attached program shows that in a certain situation gcc converts true to other values than 1. Version-Release number of selected component (if applicable): gcc-3.4.3-22.fc3 How reproducible: Always. Steps to Reproduce: 1. Type g++ foo.cpp -o foo 2. Then type ./foo Actual results: 8 Expected results: 1 Additional info: 1) The bug does not happen if you use -O2 or -O9. 2) With gcc 3.3.4 it also happens if you use -O2 (but it does not if you use -O9). 3) The bug has been reported to happen also with gcc 4.0. 4) 8 is not a special number. In a closely related situation I was getting 191. 5) The attached program uses boost (I am using the package boost-devel-1.32.0-5.fc3), and boost might happen to be buggy, but this is really a gcc bug. In no situation should gcc convert a bool to any integer other than 0 or 1.
Created attachment 114125 [details] testcase
I take my last comment back: I don't know if it's a gcc bug or a boost bug.
I think you trigger undefined behaviour, because there is no sequence point at | in: b = (ch_p(':')[assign_a(mybool, false)] | eps_p[assign_a(mybool, true)]); so expecting that mybool will be true is a wrong expectation. I don't know boost at all (that's why I'm reassigning the bug), but under the debugger I see the actors that actually do the assignment (boost::spirit::assign_action::act<bool, bool> (bool &, const bool &) in this case) is called far after the definition method has left, yet it uses references to definition's local variables.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Same bug in current FC5.
Same bug FC6.
This is undefined behavior. Results are very strange, however. I do think that the -O0 behavior is a gcc bug. -O2 %./a.out 0 -O1 %./a.out 1 -00 %./a.out 8
I do not think that the behavior is undefined. The source code seems to me to be perfectly compliant with the Boost Spirit documentation. (I do not understand the objection in Comment #3: the fact that there is or not a sequence point at | does not seem relevant to me.)
Created attachment 221151 [details] Test case. I took a stab at this problem. What happens in boost is in more simple terms illustrated by the attached source. The problem is with const reference to immediate value, which ends up pointing to stack. Obviously when the action actually takes place, the stack is in completely different shape. The run looks like this: $ ./a.out ctor: 0xbf9ed113, 1 call: 0xbf9ed113, 191 191 Sequencing of the original test case may still be dubious, but I didn't dig in that direction, because the problem exhibits itself even when I remove the first branch of | operator. Benjamin, I'm not sure what's the problem here. Is C++ supposed to treat const references to immediate values like this, which would indicate that the problem is in boost; or is this a bug in compiler, and I should report upstream?
Created attachment 221161 [details] Test case. And just for reference, cut down version of original testcase. Transcript of run: $ ./a.out 8 $ ./a.out 10 $ ./a.out 8 So you see, it's not even deterministic...
Great job on the reduced test case Petr! To me, this is a boost bug. In your reduced example, the second argument of the tester ctor should not be a reference, but a value. A reference to temporary is wack. -benjamin
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
Bug still present.
Petr, update Fedora version field.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Same bug in current Fedora 12 (original testcase gives 191 instead of 1).
Given the long history of this bug, I think it's unlikely to get directly resolved via this bug ticket. Has the issue been discussed upstream?
I'm closing this. Results are the same on F13/F14/RHEL6 with the 2nd attachment's testcase: -O0 == 0 -01 and higher = 1 The original issue is about bool conversions to int values other than 0 or 1, so that seems resolved. This isn't a bug, but rather undefined behavior, see #3. -benjamin
Not wanting to create unsolicited noise I do not reopen the bug, but on my system (up to date F13) I still get 191 with -O0.