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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

            Bug ID: 88409
           Summary: [9 Regression] FAIL at line 4429, options
                    --format=gnu-v3:
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: nickc at redhat dot com
  Target Milestone: ---

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)
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

Nick Clifton <nickc at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at gcc dot gnu.org

--- Comment #1 from Nick Clifton <nickc at gcc dot gnu.org> ---
Created attachment 45184
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45184&action=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...
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-12-07
     Ever confirmed|0                           |1

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
(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.
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

Nick Clifton <nickc at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #3 from Nick Clifton <nickc at gcc dot gnu.org> ---
(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 ?
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
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?
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

--- Comment #5 from Nick Clifton <nickc at gcc dot gnu.org> ---
(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 ?
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
(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
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #7 from Ian Lance Taylor <ian at airs dot com> ---
It looks like that was a real symbol from a real program.  What happens if we
double the recursion limit?
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.0
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

--- Comment #8 from Nick Clifton <nickc at gcc dot gnu.org> ---
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
Reply | Threaded
Open this post in threaded view
|

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

mpolacek at gcc dot gnu.org
In reply to this post by mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409

Nick Clifton <nickc at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Nick Clifton <nickc at gcc dot gnu.org> ---
fixed by increasing the recursion limit to 2048.