Bug 88409 - [9 Regression] FAIL at line 4429, options --format=gnu-v3:
Summary: [9 Regression] FAIL at line 4429, options --format=gnu-v3:
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 9.0
: P3 normal
Target Milestone: 9.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-07 16:14 UTC by H.J. Lu
Modified: 2018-12-11 12:03 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2018-12-07 00:00:00


Attachments
Proposed patch (1.45 KB, patch)
2018-12-07 16:26 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2018-12-07 16:14:01 UTC
r266886 caused:

./test-demangle < /export/gnu/import/git/sources/gcc/libiberty/testsuite/demangle-expected
FAIL at line 4429, options --format=gnu-v3:
in:  _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_
out: (null)
Comment 1 Nick Clifton 2018-12-07 16:26:52 UTC
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...
Comment 2 H.J. Lu 2018-12-07 16:33:18 UTC
(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.
Comment 3 Nick Clifton 2018-12-07 16:44:41 UTC
(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<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> ><modc::parser::ExtractParserType<modc::astParser::LocatedParser<modc::parser::ParserRef<modc::astParser::{lambda(modc::astParser::TokenParserInput&)#1}> > >::InputType, modc::parser::MaybeRef<modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, modc::Maybe<modc::parser::Parser>&&)#21}>::Type, modc::parser::RepeatedParser<modc::parser::ParserRef<modc::parser::TransformParser<modc::parser::ParserRef<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> ><modc::astParser::TokenParserInput<modc::parser::ParserRef<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser<modc::parser::ParserRef<modc::parser::Parser<modc::astParser::TokenParserInput, modc::ast::Expression> > ><modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Annotation::Relationship> >, modc::parser::ExactElementParser> >, modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, modc::Maybe<modc::parser::Parser>&&)#21}> >, false><modc::parser::OptionalParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser<modc::parser::ParserRef<modc::parser::Parser<modc::astParser::TokenParserInput, modc::ast::Expression> > > > >::Type, modc::parser::RepeatedParser<modc::parser::ParserRef<modc::parser::TransformParser<modc::parser::ParserRef<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> ><modc::astParser::TokenParserInput<modc::parser::ParserRef<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser<modc::parser::ParserRef<modc::parser::Parser<modc::astParser::TokenParserInput, modc::ast::Expression> > ><modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Annotation::Relationship> >, modc::parser::ExactElementParser> >, modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, modc::Maybe<modc::parser::Parser>&&)#21}> >, false><modc::astParser::LocatedParser<modc::parser::ParserRef<modc::astParser::{lambda(modc::astParser::TokenParserInput&)#1}> ><modc::parser::ParserRef<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> > > >::Type, modc::parser::RepeatedParser<modc::parser::ParserRef<modc::parser::TransformParser<modc::parser::ParserRef<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> ><modc::astParser::TokenParserInput<modc::parser::ParserRef<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser<modc::parser::ParserRef<modc::parser::Parser<modc::astParser::TokenParserInput, modc::ast::Expression> > ><modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Annotation::Relationship> >, modc::parser::ExactElementParser> >, modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, modc::Maybe<modc::parser::Parser>&&)#21}> >, false><modc::parser::SequenceParser<modc::astParser::TokenParserInput<modc::parser::ExactElementParser<modc::astParser::TokenParserInput>, modc::astParser::LocatedParser<modc::parser::ParserRef<modc::astParser::{lambda(modc::astParser::TokenParserInput&)#1}> ><modc::ast::Expression> > > >::Type, modc::parser::RepeatedParser<modc::parser::ParserRef<modc::parser::TransformParser<modc::parser::ParserRef<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> ><modc::astParser::TokenParserInput<modc::parser::ParserRef<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser<modc::parser::ParserRef<modc::parser::Parser<modc::astParser::TokenParserInput, modc::ast::Expression> > ><modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Annotation::Relationship> >, modc::parser::ExactElementParser> >, modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, modc::Maybe<modc::parser::Parser>&&)#21}> >, false><modc::parser::RepeatedParser<modc::parser::ParserRef<modc::parser::TransformParser<modc::parser::ParserRef<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> ><modc::astParser::TokenParserInput<modc::parser::ParserRef<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser<modc::parser::ParserRef<modc::parser::Parser<modc::astParser::TokenParserInput, modc::ast::Expression> > ><modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Annotation::Relationship> >, modc::parser::ExactElementParser> >, modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, modc::Maybe<modc::parser::Parser>&&)#21}> >, false> >::Type> modc::parser::sequence<modc::astParser::LocatedParser<modc::parser::ParserRef<modc::astParser::{lambda(modc::astParser::TokenParserInput&)#1}> >, modc::parser::OptionalParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser<modc::parser::ParserRef<modc::parser::Parser<modc::astParser::TokenParserInput, modc::ast::Expression> > > >, modc::astParser::LocatedParser<modc::parser::ParserRef<modc::astParser::{lambda(modc::astParser::TokenParserInput&)#1}> ><modc::parser::ParserRef<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> > >, modc::parser::SequenceParser<modc::astParser::TokenParserInput<modc::parser::ExactElementParser<modc::astParser::TokenParserInput>, modc::astParser::LocatedParser<modc::parser::ParserRef<modc::astParser::{lambda(modc::astParser::TokenParserInput&)#1}> ><modc::ast::Expression> > >, modc::parser::RepeatedParser<modc::parser::ParserRef<modc::parser::TransformParser<modc::parser::ParserRef<modc::astParser::OneOfKeywordsToTParser<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Style> ><modc::astParser::TokenParserInput<modc::parser::ParserRef<modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser<modc::parser::ParserRef<modc::parser::Parser<modc::astParser::TokenParserInput, modc::ast::Expression> > ><modc::astParser::ListParserTemplate<(modc::tokens::Token::Type)4, &modc::tokens::{unnamed type#1}::parenthesized>::Parser::Annotation::Relationship> >, modc::parser::ExactElementParser> >, modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, modc::Maybe<modc::parser::Parser>&&)#21}> >, false> >(modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, modc::Maybe<modc::parser::Parser>&&)#21}&&, (modc::parser::ExtractParserType<modc::astParser::LocatedParser<modc::parser::ParserRef<modc::astParser::{lambda(modc::astParser::TokenParserInput&)#1}> > >&&)...)

I would have thought that that would be extremely unlikely.  Am I wrong ?
Comment 4 H.J. Lu 2018-12-07 16:48:59 UTC
(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?
Comment 5 Nick Clifton 2018-12-07 16:53:56 UTC
(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_EEEEEINS0_14OptionalParserINS2_18ListParserTemplateIL
> NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesizedEEEE6ParserINS4_INS0_6Par
> serIS5_NS_3ast10ExpressionEEEEEEEEENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ
> _5StyleEEEEEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_
> EEEEENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1
> 0Annotation12RelationshipEEEEESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE
> EEELb0EEEEEENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T
> ypeEDpNS1I_IT0_E4TypeEEEEOS1F_DpOS1L_
> 
> continues to work.  Does it work with your patch?

No.

But "c++filt -r <that-mangled-string>" will work.

Is that string an example of a real world mangled symbol name, or was it just
invented to test the demangler ?
Comment 6 H.J. Lu 2018-12-07 17:25:57 UTC
(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_EEEEEINS0_14OptionalParserINS2_18ListParserTemplateIL
> > NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesizedEEEE6ParserINS4_INS0_6Par
> > serIS5_NS_3ast10ExpressionEEEEEEEEENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ
> > _5StyleEEEEEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_
> > EEEEENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1
> > 0Annotation12RelationshipEEEEESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE
> > EEELb0EEEEEENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T
> > ypeEDpNS1I_IT0_E4TypeEEEEOS1F_DpOS1L_
> > 
> > continues to work.  Does it work with your patch?
> 
> No.
> 
> But "c++filt -r <that-mangled-string>" 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
Comment 7 Ian Lance Taylor 2018-12-07 17:44:21 UTC
It looks like that was a real symbol from a real program.  What happens if we double the recursion limit?
Comment 8 Nick Clifton 2018-12-11 12:00:43 UTC
Author: nickc
Date: Tue Dec 11 11:59:53 2018
New Revision: 267020

URL: https://gcc.gnu.org/viewcvs?rev=267020&root=gcc&view=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
Comment 9 Nick Clifton 2018-12-11 12:03:18 UTC
fixed by increasing the recursion limit to 2048.