Last known to work with: "Fri Dec 30 21:24:33 UTC 2005 (revision 109181M)". Known to fail with: "Wed Jan 11 14:14:27 UTC 2006 (revision 109585M)". FAIL: ext/pb_assoc/example/erase_if.cc execution test With the message in the .log being: ... PASS: ext/pb_assoc/example/erase_if.cc (test for excess errors) /home/hp/combined41/combined/libstdc++-v3/testsuite/ext/pb_assoc/example/erase_if.cc:89: void some_op_sequence(Cntnr) [with Cntnr\ = pb_assoc::tree_assoc_cntnr<int, char, std::less<int>, pb_assoc::rb_tree_ds_tag, pb_assoc::null_node_updator, std::allocator<ch\ ar> >]: Assertion `c.size() == 20' failed.^M program stopped with signal 6.^M FAIL: ext/pb_assoc/example/erase_if.cc execution test There were changes to both the c++ and libstdc++ in this time-frame. Let's start with blaming libstdc++ as "component".
For sure, no changes to the concerned library code. Considering that, to my best knowledge, nobody among the library maintainers has got such kind of system and that the problem is not reproducable elsewhere, it's highly unlikely that the problem will be fixed, be warned ;)
In response to comment #1: For the record, *all* library maintainers have access to such a system, AFAIK. I don't expect anyone to look into this, since it involves a few extra steps, some of which involve considerable machine time (installing a glibc port) if the host system isn't FC or Debian for ix86 or installing in /usr/local/cris isn't an option; however the test was performed _using a simulator_ with code publically available. Should anyone wish to actually repeat the problem, there are some notes in PR 22382 to get and install the glibc port (2.2.4-ish). The cris-sim.exp file is available from the dejagnu CVS, see head of PR 19745. Again, I don't expect anyone else to look at this; the PR is mostly for my own record-keeping. Use or ignore it as you please.
Created attachment 10657 [details] Draft for an aliasing issue
Can you check whether this patch helps you in any way? Is the only pending issue I'm aware of in the involved code and we are going to have something similar anyway. -fno-strict-aliasing should also tell you something.
By the way, no need to run the entire testsuite: example/erase_if.cc can be compiled and run standalone as-is.
Sorry, the patch in comment #3 did not help. Same error, same assertion error message. (No regressions though, tested cross to cris-elf, cris-axis-linux-gnu, mmix-knuth-mmixware.)
(In reply to comment #6) > Sorry, the patch in comment #3 did not help. > Same error, same assertion error message. > (No regressions though, tested cross to > cris-elf, cris-axis-linux-gnu, mmix-knuth-mmixware.) Thanks for your testing. Can you also confirm that most likely it is not an aliasing issue (i.e., -fno-strict-aliasing doesn't help either)? In that case, I really believe we are dealing with a miscompilation.
Confirmed that compiling the test-case with -fno-strict-aliasing yields the same error.
HP, I also don't know what is going on here, but it seems unlikely that the libstdc++ code is to blame, just because there's been no change to this part of libstdc++ in quite a while. One thing you could check, if you have various compilers for cris around, is to try to compile newer libstdc++ sources with a known good cris compiler. That would at least let you know where things are problematic, without digging too far into this. -benjamin
Hardly a regression, considering that ext/pb_assoc has been released for the first time in 4.1.0 ;)
Uh, make no mistake, this *is* a regression; see the original description. There's a revision before which this test worked and a revision after which it does not work. This happened in 4.1 era, so it's a 4.1 regression. Whether or not the code that the ext/pb_assoc test is *intended* to test is part of any gcc release is not central; it has no bearing on whether the behavior is a regression. It'd be like saying whether miscompilation of a piece of code being a regression depends on whether that code was part of the gcc release that miscompiled it. I changed the PR component to a historically more probable one, to avoid blaming libstdc++, as it seems that's an conclusion you're trying to avoid.
(In reply to comment #11) > I changed the PR component to a historically more probable one, to avoid > blaming libstdc++, as it seems that's an conclusion you're trying to avoid. Agreed, *as a miscompilation*, can be a regression. And, yes, I'm trying to avoid that conclusion, because, really, the chances that something show up in the libstdc++ side, without some help from you, a reduced testcase of sort, are close to zero, given the evidence we have got to date. Again, in my opinion, in such cases, it would be better to have available in Bugzilla an "unclassified" component.
Until/unless this is shown to be a problem on a primary/secondary platform, I'm going to downgrade it to P5.
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Closing 4.1 branch. The log suggests this was only ever a problem on the branch, not trunk; if it's actually present with more recent versions, please reopen and mark accordingly.