C++: Non-virtual thunks to dtors no longer being emitted in comdat sections?
Evening all, Something has changed in the last few weeks that has resulted in, as the subject says, non-virtual thunks (in this case, all specifically to dtors, but I don't know if that is relevant or mere accident) no longer being emitted as comdat for i686-pc-cygwin; I haven't checked other targets. Instead they are emitted in the .text section - of every object file that includes the related class definition header file. Naturally this leads to multiple definition errors at link-time(*). Can anyone think of a recent change which might have impacted on the way these thunks are emitted? Or alternatively point me at the responsible area of the code for further debugging? cheers, DaveK -- (*) - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218
Re: Bug triage
Thanks for the feedback. > Moving the test case into an attachment won't be useful. What would be > useful is recasting the test case into a form which can be used in the > gcc testsuite, if possible Whilst I would like to be able to submit new test cases as I go, as you (Ian) pointed out this may be too difficult for missed-optimization bugs as I cannot confirm if the assembler is fixed - I can only confirm if it shows the inefficiency as listed in the bug description. Anyway, I will see what I can manage. Out of interest, is there a way of linking bugs in the bug database with their test case in the gcc test-suite, and vice-versa? There doesn't appear to be a field for this in the bug report. > > 5. Similarly, if I mark a bug as known to work in 4.5.2, will this > > lead to it eventually being closed? Just to clarify what Joseph was saying on this point, it seems that in order to help close off any bugs, I would need to run the test on 4 versions of gcc; 4.3.5, 4.4.5, 4.5.2 and trunk (4.6.0), and confirm it works for all of them. What exact gcc code should I use for this? - the latest stable build for each version? - or, the latest code from each branch? - or, the latest snapshot release for each branch? It seems to me there are pros and cons of each, so it isn't clear which is the best one. In particular, if I don't use a stable release branch, then what version should I put for the "Known to fail/work"? For example, if I use the trunk and I mark bugs as "Known to fail" in "4.6.0", and the bug is eventually fixed before 4.6.0 is shipped, then the field will be incorrectly set. > There are very many UNCONFIRMED bugs. If you can confirm that such a > bug really is a bug in GCC and is still present on trunk, then moving it to > NEW is useful. Whilst I would like to be able to do this, as a first time contributor to the project do I really have the authority to mark a bug as NEW? Otherwise what is stopping the original reporter from just marking the bug as NEW and effectively skipping the UNCONFIRMED state all together? I have a few more questions about the whole bug management process and how I may contribute... To take a random example, enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26902 has been open since 2006, it has a fairly comprehensive list of "known to fail" versions (presumably versions that were current at the time), and it has several comments. However it remains in the UNCONFIRMED state, and has never had the "Target Milestone" set. I appreciate that optimizing inline asm may be a rare use case, especially when it works without using inline asm (as per comments), however it is a valid enhancement nonetheless (and presumably the actual use case is more complicated than reported in the bug description). If I were to test this enhancement on the 4 versions of gcc and confirm it is still an open enhancment, then should it be marked as NEW, with a "Target Milestone" of 4.6.0, and the priority potentially lowered to P4 or P5 (given it is rare and old)? Regards, Tony
Re: Bug triage
On Thu, 6 Jan 2011, Ian Lance Taylor wrote: > > 5. Similarly, if I mark a bug as known to work in 4.5.2, will this > > lead to it eventually being closed? > > Yes, when the 4.4 release is closed, bugs known to work in 4.5 will be > closed. That's not how it works. I did the last couple of branch closures (4.1 and 4.2); I only went through the regression bugs or open bugs with a milestone on the closed branch, and for those bugs interpreted the bug log to determine whether they should be retargetted or closed. For any other bug (i.e. any non-regression), if it works on 4.5 and trunk it should be closed, and if it works on 4.5 but not on trunk it should be marked as a regression. So marking a bug as known to work in 4.5 is only useful if you also mark it as a regression in 4.6 (which of course means testing on trunk) (or, as the case may be, as a 4.3/4.4 regression from some older release that was fixed in 4.5 but may yet be fixed in 4.3/4.4). If it works in 4.5 and is not a regression on trunk or an open branch, it should just be closed; we don't keep bugs open for things that work on trunk unless they are regressions in a release branch. There are very many UNCONFIRMED bugs. If you can confirm that such a bug really is a bug in GCC and is still present on trunk, then moving it to NEW is useful. -- Joseph S. Myers jos...@codesourcery.com
Re: Bug triage
On 7 January 2011 04:59, Tony Poppleton wrote: > Hi, > > I would like to help with some gcc bug triage, and have a few > questions about doing so. Excellent, thanks for volunteering your time. > For example, in cases where a bug doesn't have a test case as an > attachment, but instead embedded in the description, would it be of > use for me to create the attachment? I can't speak for anyone else, but personally I prefer testcases embedded in the description or comments, as long as they're a reasonable size (20 or 30 lines is fine) That lets me see the code without having to download the attachment, which depending on the content-type might need to be saved and then I have to open a terminal or file manager to open the file, just to see what the test looks like. If it's in a comment I can glance at it and if I want to test it just copy and paste it into a terminal.
Re: Bug triage
On Thu, Jan 06, 2011 at 10:31:28PM -0800, Ian Lance Taylor wrote: > > 2. A large number of bugs seem to not be targetted for any particular > > release, e.g. of the 4389 open bugs, only 296 are listed as targetted > > for 4.6.0. Why is there such a discrepency? > > > > Incidentally, my main focus will be on these untargetted bugs rather > > than on bugs that are already scheduled to be fixed. > > For an open bug, a target of 4.6.0 means only that the bug is known to > fail on current mainline. It doesn't mean that the bug is more likely > to be fixed for 4.6.0 than any other current bug. At least, as far as I > know; the release managers or bugmasters may have a better idea. target field is mainly used for tracking the regressions (the canned queries from gcc.gnu.org homepage). For a regression (with [4.x/4.y/4.z Regression] in the subject) it should be set to the next patchlevel version of the gcc release in which we'd like it to be fixed, if it is decided that it won't be fixed say in 4.4 because the fix is too invasive there, target will be changed to 4.5.3 etc. > > 3. If I mark a bug as known to fail in 4.5.2, will someone else then > > schedule it to be fixed in 4.6.0? > > No. People choose bugs to work on based mainly on the priority and on > whether the bug is a regression or not. As far as I know people do not > look at the target field. The queries do though. Jakub
Re: Unrecognized option '-Wl,-rpath' for jv-convert
On 01/06/2011 09:28 PM, Gerald Pfeifer wrote: On Thu, 6 Jan 2011, Ralf Wildenhues wrote: Could be libtool issue or lib-link.m4 one (or gcj one). Can you send ./libtool --tag=GCJ --config output? I assume you mean from libjava in the build tree? Attached. (Note this is now x86_64-portbld-freebsd8.2, newer than the original report, but the same failure.) Does passing '-Wl,-rpath -Wl,/foo' to gcj work for a small example program for you? I played around, and modifying the failing command line (that is, with all those -B, -L,... options) I still got the same failure. Note, if I remove -Wl,-rpath from that invocation, the failure is still the same, so that seems to come from gcj itself? It looks as though the -rpath arg isn't being passed correctly. I just can't figure out why this should be different on bsd. I think this just needs to be debugged. It should be pretty obvious what's happening. Andrew.
