https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Nick Clifton from comment #3) > (In reply to H.J. Lu from comment #2) > > Hi H.J. > > > > The attached patch resolves the problem by adding a --no-recurse-limit > > > option to the demangler testser and then using it for the problematic > > > test case. I felt that this was a better solution than raising the > > > recursion limit, as it means that the limit detecting code will actually > > > be exercised by the testsuite. > > > This will cause a regression since this input will fail now. > > Umm, sorry ? The change means that the old behaviour of the demangler > is restored. Ie the recursion limit is not enforced, and thus the test > will behave exactly as it used to do. > > Unless you mean that there would be a problem if the test input (or > something similar) is ever generated by the compilation of a real-world > program. In which case I agree, there would be a problem. But are you > ever going to get a real-world mangled version of: > > I am expecting that [hjl@gnu-cfl-1 libiberty]$ c++filt _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRNS2_16TokenParserInputEE_EEEEEINS0_14OptionalParserINS2_18ListParserTemplateILNS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesizedEEEE6ParserINS4_INS0_6ParserIS5_NS_3ast10ExpressionEEEEEEEEENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ_5StyleEEEEEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_EEEEENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_10Annotation12RelationshipEEEEESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EEEEELb0EEEEEENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4TypeEDpNS1I_IT0_E4TypeEEEEOS1F_DpOS1L_ continues to work. Does it work with your patch?
