Created attachment 28765 [details] test case + preprocessor output The following code generates a pure virtual method call only when compiled with -O1/O2/O3, the same code seems working without error with gcc 4.7.3. The code is inlined in here and I have attached an archive containing the preprocessor output as well. Consider that it doesn't crash if: - Remove the noncopyable from B or - Remove one of the two segments in the extra scope in main or - Remove the try { } catch I have tried with boost 1.40, 1.50 and 1.52 #include <boost/optional.hpp> #include <boost/noncopyable.hpp> class B : boost::noncopyable { //if the noncopyable is removed works public: virtual size_t bar() const = 0; }; class D : public B { public: D() :theBar(foo(10)) { } virtual size_t bar() const { return theBar; } private: static size_t foo(const boost::optional<size_t> a) { if (a) { //if this is a.is_initialized() then it works return a.get(); } return 2; } const size_t theBar; }; class Foo { public: Foo(const B& b) :theBar(b.bar() * b.bar()) { } private: const size_t theBar; }; int main() { { //if this section is removed works D d; try { Foo myCompound(d); } catch(...) {} } { D d; try { Foo myCompound(d); } catch(...) {} } }
GCC 4.4 is no longer supported, and the problem seems to be already fixed in current releases.
Closing then.
Time to adopt ICC.
(In reply to comment #3) > Time to adopt ICC. There is only so much resources to support older versions of GCC. If you want support for older versions of GCC, then you should pay someone (like you do for ICC).
I have no problem to pay someone, I'm a bit disappointed seeing a bug closed because "new version works" without investigate if the problem is still there in new versions but not triggered by my test case. Also if 4.4.3 is not supported why while submitting the bug I was able to target the 4.4.3?
Let's make a deal: you provide a self-contained short testcase (say below 50 lines, definitely doable with the help of c-reduce or delta) and I add it to the mainline testsuite, to avoid regressions. I'll do that for free! ;)
(In reply to comment #5) > I have no problem to pay someone, I'm a bit disappointed seeing a bug closed > because "new version works" without investigate if the problem is still there > in new versions but not triggered by my test case. I'm a bit disappointed you think I didn't investigate. I'm a bit disappointed you didn't try a current release as requested at http://gcc.gnu.org/bugs/ (or even the most recent 4.4 release!) I'm a bit disappointed you didn't reduce the testcase to something that doesn't include thousands of lines of boost code. I'm a bit diappointed you didn't include the output of 'g++ -v'. But I got over my disappointment and I tested with half a dozen different versions of GCC and looked for old bugs in the area which I know about. I didn't find anything, but the bug is not reproducible in current releases. Exactly how much time do you expect someone to spend chasing a bug that doesn't appear to exist any more? If you can reproduce it with a current release then reopen the bug, otherwise this is a bug in a release series that is discontinued and not going to be fixed. If you pay me I'll find exactly which patch fixed it, otherwise the onus is on you to demonstrate there's still a problem. > Also if 4.4.3 is not supported why while submitting the bug I was able to > target the 4.4.3? There are lots of existing bugs with that version, so it has to be a valid option, or we'd have to delete all the old bugs. We could make it unselectable, but that would prevent us fixing or re-categorising old bugs if we need to, and is it really worth the effort of customising bugzilla in that way?
Jonathan, I have nothing against you personaly, what you wrote is: "GCC 4.4 is no longer supported, and the problem *seems* to be already fixed in current releases." and doesn't exactly show that you have investigate, I have also stated that with 4.7.3 works. Actualy the code I have submitted was tailored already I couldn't shrink more than I did. To be honest with the real code instead to have a "pure virtual call" I had a simple core with gdb finding bogus data in the core, that was the smallest test I was able to make it reproducible. About the fact I didn't post the g++ -v output you are right, I have issued the command "g++ -v -save-temps ..." but somehow the output get lost in the archive attached. If you are interested in the output I will provide it. About the fact to pay you to find the patch/commit correcting it just send me a commercial proposal to my email address. Thank you for your time. Regards Gaetano Mendola
(In reply to comment #8) > Jonathan, I have nothing against you personaly, what you wrote is: > > "GCC 4.4 is no longer supported, and the problem *seems* to be already fixed in > current releases." > > and doesn't exactly show that you have investigate, I have also stated that > with 4.7.3 works. I investigated and couldn't find anything conclusive, so I said "seems" because I wasn't certain. If you assume I didn't investigate and reply with "time to adopt ICC" then feel free to do so, I don't volunteer my time to GCC for people with that attitude. > Actualy the code I have submitted was tailored already I couldn't shrink more > than I did. To be honest with the real code instead to have a "pure virtual > call" I had a simple core with gdb finding bogus data in the core, that was the > smallest test I was able to make it reproducible. http://gcc.gnu.org/bugs/minimize.html http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction > About the fact I didn't post the g++ -v output you are right, I have issued the > command "g++ -v -save-temps ..." but somehow the output get lost in the archive > attached. If you are interested in the output I will provide it. I'm not interested, the point is you provided an incomplete bug report but are then happy to complain about the effort put in by people who look at it. The bug was fixed by http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html so is fixed in 4.5.0 and later
(In reply to comment #9) > (In reply to comment #8) > > Jonathan, I have nothing against you personaly, what you wrote is: > > > > "GCC 4.4 is no longer supported, and the problem *seems* to be already fixed in > > current releases." > > > > and doesn't exactly show that you have investigate, I have also stated that > > with 4.7.3 works. > > I investigated and couldn't find anything conclusive, so I said "seems" because > I wasn't certain. > > If you assume I didn't investigate and reply with "time to adopt ICC" then feel > free to do so, I don't volunteer my time to GCC for people with that attitude. Well, I have to admit that was a poor and over reacted reply from my side, but as you spent your time to investigate the issue I have spent my time to understand why it was happening and some hours, no kidding, to shrink it as much I could to create the test case I have submitted, as you can see that code is useful to nothing. I was frustrated to see a short "it work/fixed in current release" after having work half noon to submit it, the fast it was working with a new gcc release was an information I already knew it, I'd expect something on the line: "o yes, it was an old bug we have already corrected", that's why I have submitted the bug not to drive someone else trying the same I did. As you can see from my first post I have tried to shrink more than that, and each piece I was removing was then making the test "passing". > I'm not interested, the point is you provided an incomplete bug report but are > then happy to complain about the effort put in by people who look at it. I'm not happy to complain, why would I? I'm happy when stuff works and when a submitted bug was a real bug helping to improve gcc quality. When I submitted it, for me the bug report was not incomplete otherwise I wouldn't have submitted it, I did follow the guide and the only piece missing, my fault, was the output of g++ -v -save-temps because I forgot to redirect the output to a file. I would have provided it immediately if you would have pointed it out earlier. > The bug was fixed by http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html so is > fixed in 4.5.0 and later Thank you for it. May I say now then: "time to upgrade gcc" ? I'm sorry it was not my intention to hurt anyone.