[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:

[hjl.tools at gmail dot com]

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?