This is the mail archive of the
mailing list for the GCC project.
Patch to demangle-expected--remove the final error
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: dj at redhat dot com
- Date: 29 Nov 2003 01:09:23 -0500
- Subject: Patch to demangle-expected--remove the final error
The current version of the libiberty test file demangle-expected has
this test in it:
# This caused an infinite loop.
# We still don't demangle this correctly, but at least we don't hang.
This test fails.
When this test was added, it looked like this:
When written like this, the test passes.
The difference here is that the in the former case the demangler fails
to demangle the string. In the latter case, the demangler succeeds,
but the result is obviously nonsense.
However, although the result is nonsense, this is actually a correct
demangling. When using the GNU V2 mangling style, more or less any
string of random characters, which can not be demangled itself, and
which ends in "__7_Z1ZZ2Z8iterator", can be correctly demangled as
"_Z1ZZ2Z::<random string>(iterator)". This is because the GNU V2
mangling style does not clearly differentiate between a mangled string
and a user name which contains multiple underscore characters, so the
demangler must attempt to demangle any suffix of the mangled name
which starts with "__". So, for example, the demangler does the
following correct demanglings:
p__7_Z1ZZ2Z8iterator ==> _Z1ZZ2Z::p(iterator)
p__q__7_Z1ZZ2Z8iterator ==> _Z1ZZ2Z::p__q(iterator)
__p__q__7_Z1ZZ2Z8iterator ==> _Z1ZZ2Z::__p__q(iterator)
In other words, I believe that the test case as originally added was
correct. The result was a correct GNU V2 demangling of a function
with a very strange name.
The test case was changed with this ChangeLog entry:
2003-06-26 H.J. Lu <firstname.lastname@example.org>
* testsuite/demangle-expected: Add more GNU V3 testcases.
This particular part of that change is not correctly described by the
ChangeLog entry, since it never was a GNU V3 testcase.
That change was approved here, by DJ:
His comment is ``The addition of the demangler testcases portion of
your original patch was approved in April.''
I looked back there, and saw these notes:
From DJ: ``If some C++ person could verify the libiberty cases are
actually correct, then consider them approved by me.''
From Ben Kosnik: ``The libiberty cases for gnu-v3 are fine.''
It's not clear to me that anybody really considered what it meant to
change the meaning of this particular test case, which, as noted, was
not a GNU V3 test case.
So, I think the test case should be returned to its original form. In
this form, it will pass.
I also looked into whether it would be possible to demangle the string
correctly. It is an EDG mangled name. I don't know how EDG names are
mangled, and I couldn't find any spec online. Looking into it closely
bsaed on the current code, I concluded that a correct demangling would
require handling a construct which I do not know precisely how to
handle. I added comments describing my findings.
2003-11-29 Ian Lance Taylor <email@example.com>
* testsuite/demangle-expected: Revert one part of 2003-06-26 patch
to restore expected result of EDG test case to original expected
RCS file: /cvs/gcc/gcc/libiberty/testsuite/demangle-expected,v
retrieving revision 1.20
diff -u -r1.20 demangle-expected
--- testsuite/demangle-expected 26 Nov 2003 23:33:05 -0000 1.20
+++ testsuite/demangle-expected 29 Nov 2003 05:45:51 -0000
@@ -2889,10 +2889,21 @@
# This caused an infinite loop.
-# We still don't demangle this correctly, but at least we don't hang.
+# This is generated by an EDG compiler (kcc 4.0). To demangle it
+# correctly, I believe that we have to understand that the J37J deep
+# in the string somehow refers back to the type starting 37 characters
+# in from some starting point, so that it winds up being the type
+# starting with 41THandle.... However, lacking a spec for EDG
+# demangling, it's hard to implement this.
+# In the meantime, this symbol can be successfully demangled in GNU
+# mode. Of course the result is more or less nonsense, but an older
+# version of g++ would indeed generate this mangled name given the
+# appropriate input, so the demangling is correct.
# This used to cause a crash. It doesn't follow the C++ encoding so
# the demangled name should be identical to the original symbol name.