[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Nick Clifton --- fixed by increasing the recursion limit to 2048.
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #8 from Nick Clifton --- Author: nickc Date: Tue Dec 11 11:59:53 2018 New Revision: 267020 URL: https://gcc.gnu.org/viewcvs?rev=267020=gcc=rev Log: Fix a failure in the libiberty testsuite by increasing the demangle recursion limit to 2048. PR 88409 * demangle.h (DEMANGLE_RECURSION_LIMIT): Increase to 2048. Modified: trunk/include/ChangeLog trunk/include/demangle.h
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #7 from Ian Lance Taylor --- It looks like that was a real symbol from a real program. What happens if we double the recursion limit?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #6 from H.J. Lu --- (In reply to Nick Clifton from comment #5) > (In reply to H.J. Lu from comment #4) > > > I am expecting that > > > > [hjl@gnu-cfl-1 libiberty]$ c++filt > > _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRN > > S2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateIL > > NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6Par > > serIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ > > _5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ > > ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1 > > 0Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE > > EEELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T > > ypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ > > > > continues to work. Does it work with your patch? > > No. > > But "c++filt -r " will work. > > Is that string an example of a real world mangled symbol name, or was it just > invented to test the demangler ? It came from the fix for https://sourceware.org/bugzilla/show_bug.cgi?id=14065
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #5 from Nick Clifton --- (In reply to H.J. Lu from comment #4) > I am expecting that > > [hjl@gnu-cfl-1 libiberty]$ c++filt > _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRN > S2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateIL > NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6Par > serIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ > _5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ > ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1 > 0Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE > EEELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T > ypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ > > continues to work. Does it work with your patch? No. But "c++filt -r " will work. Is that string an example of a real world mangled symbol name, or was it just invented to test the demangler ?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #4 from H.J. Lu --- (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_EINS0_14OptionalParserINS2_18ListParserTemplateILNS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6ParserIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ_5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_10Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_ELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4TypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ continues to work. Does it work with your patch?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Nick Clifton changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Nick Clifton ---
(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:
modc::parser::ParserRef::Parser::Style>
>
> >::InputType,
modc::parser::MaybeRef&&)#21}>::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>::Parser > > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>
>::Parser::Style> > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>,
modc::astParser::LocatedParser
> > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >, false> >::Type>
modc::parser::sequence
>,
modc::parser::OptionalParser::Parser > > >,
modc::astParser::LocatedParser
>::Parser::Style> > >,
modc::parser::SequenceParser,
modc::astParser::LocatedParser
> > >,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >, false>
>(modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}&&,
(modc::parser::ExtractParserType
> >&&)...)
I would have thought that that would be extremely unlikely. Am I wrong ?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-07 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- (In reply to Nick Clifton from comment #1) > Created attachment 45184 [details] > Proposed patch > > *sigh* Yes, I forgot to run the libiberty testsuite, and of course > there is one test that actually breaches the demangling limit. > > 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. > > Currently waiting for review of the patch... This will cause a regression since this input will fail now.
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- Created attachment 45184 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45184=edit Proposed patch *sigh* Yes, I forgot to run the libiberty testsuite, and of course there is one test that actually breaches the demangling limit. 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. Currently waiting for review of the patch...
