Ok for binutils 2.28

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

Ok for binutils 2.28

Tristan Gingold-2
Hello,

some people (they would recognise themselves :-) have recently committed patches for 2.28 while some others (who would also recognise themselves :-) have insisted to have the release.

Are we at a point where both agree ? Any reason not to release 2.28 *this* week ?

Tristan.
Reply | Threaded
Open this post in threaded view
|

Re: Ok for binutils 2.28

Maciej W. Rozycki-3
On Wed, 1 Mar 2017, Tristan Gingold wrote:

> Are we at a point where both agree ? Any reason not to release 2.28
> *this* week ?

 Fine with me as far as the MIPS port is concerned.  We'll have to live
with all the bugs that remained. ;)

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: Ok for binutils 2.28

Nick Clifton
In reply to this post by Tristan Gingold-2
Hi Tristan,

> Are we at a point where both agree ? Any reason not to release 2.28 *this* week ?

Personal opinion - go for release!

There will always be more bugs to fix and more patches that could go in, but you
have to draw the line somewhere.  Do it now, and let the complainers pester you
for a 2.28.1 point release some time down the road...

Cheers
  Nick


Reply | Threaded
Open this post in threaded view
|

Re: Ok for binutils 2.28

Alan Modra-3
In reply to this post by Tristan Gingold-2
On Wed, Mar 01, 2017 at 01:59:04PM +0100, Tristan Gingold wrote:
> Are we at a point where both agree ? Any reason not to release 2.28 *this* week ?

As far as I can tell, we're good to go.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Ok for binutils 2.28

Markus Trippelsdorf
In reply to this post by Tristan Gingold-2
On 2017.03.01 at 13:59 +0100, Tristan Gingold wrote:
> Hello,
>
> some people (they would recognise themselves :-) have recently
> committed patches for 2.28 while some others (who would also recognise
> themselves :-) have insisted to have the release.
>
> Are we at a point where both agree ? Any reason not to release 2.28
> *this* week ?

It would be good if someone could sync libiberty with gcc's. There are
several demangling fixes, that are needed for gcc-7.

--
Markus
Reply | Threaded
Open this post in threaded view
|

Re: Ok for binutils 2.28

Markus Trippelsdorf
On 2017.03.01 at 14:42 +0100, Markus Trippelsdorf wrote:

> On 2017.03.01 at 13:59 +0100, Tristan Gingold wrote:
> > Hello,
> >
> > some people (they would recognise themselves :-) have recently
> > committed patches for 2.28 while some others (who would also recognise
> > themselves :-) have insisted to have the release.
> >
> > Are we at a point where both agree ? Any reason not to release 2.28
> > *this* week ?
>
> It would be good if someone could sync libiberty with gcc's. There are
> several demangling fixes, that are needed for gcc-7.

Here is the patch:

libiberty/ChangeLog:

        Sync with gcc.

diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 15ef3b48785f..f0dbf9381c6b 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -1594,6 +1594,8 @@ d_unqualified_name (struct d_info *di)
     ret = d_source_name (di);
   else if (IS_LOWER (peek))
     {
+      if (peek == 'o' && d_peek_next_char (di) == 'n')
+ d_advance (di, 2);
       ret = d_operator_name (di);
       if (ret != NULL && ret->type == DEMANGLE_COMPONENT_OPERATOR)
  {
@@ -3609,7 +3611,11 @@ d_local_name (struct d_info *di)
     }
 }
 
-/* <discriminator> ::= _ <(non-negative) number>
+/* <discriminator> ::= _ <number>    # when number < 10
+                   ::= __ <number> _ # when number >= 10
+
+   <discriminator> ::= _ <number>    # when number >=10
+   is also accepted to support gcc versions that wrongly mangled that way.
 
    We demangle the discriminator, but we don't print it out.  FIXME:
    We should print it out in verbose mode.  */
@@ -3617,14 +3623,28 @@ d_local_name (struct d_info *di)
 static int
 d_discriminator (struct d_info *di)
 {
-  int discrim;
+  int discrim, num_underscores = 1;
 
   if (d_peek_char (di) != '_')
     return 1;
   d_advance (di, 1);
+  if (d_peek_char (di) == '_')
+    {
+      ++num_underscores;
+      d_advance (di, 1);
+    }
+
   discrim = d_number (di);
   if (discrim < 0)
     return 0;
+  if (num_underscores > 1 && discrim >= 10)
+    {
+      if (d_peek_char (di) == '_')
+ d_advance (di, 1);
+      else
+ return 0;
+    }
+
   return 1;
 }
 
diff --git a/libiberty/testsuite/demangle-expected b/libiberty/testsuite/demangle-expected
index b65dcd3450e9..c1cfa1545eca 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -4666,3 +4666,26 @@ void eat<int*, Foo()::{lambda(auto:1*, auto:2*)#6}>(int*&, Foo()::{lambda(auto:1
 
 _Z3eatIPiZ3BarIsEvvEUlPsPT_PT0_E0_EvRS3_RS5_
 void eat<int*, void Bar<short>()::{lambda(short*, auto:1*, auto:2*)#2}>(int*&, void Bar<short>()::{lambda(short*, auto:1*, auto:2*)#2}&)
+
+# PR 77489
+_ZZ3foovE8localVar_9
+foo()::localVar
+
+_ZZ3foovE8localVar_10
+foo()::localVar
+
+_ZZ3foovE8localVar__10_
+foo()::localVar
+
+_ZZ3foovE8localVar__9_
+_ZZ3foovE8localVar__9_
+
+_ZZ3foovE8localVar__12
+_ZZ3foovE8localVar__12
+
+# PR 70182
+_Z1gI1AEv1SIXadsrT_onplEE
+void g<A>(S<&A::operator+>)
+
+_Z1gI1AEv1SIXadsrT_plEE
+void g<A>(S<&A::operator+>)
--
Markus
Reply | Threaded
Open this post in threaded view
|

Re: Ok for binutils 2.28

Nick Clifton
Hi Markus,

> It would be good if someone could sync libiberty with gcc's. There are
> several demangling fixes, that are needed for gcc-7.

I have updated the mainline sources.  The branch decision is up to Tristan.

Cheers
  Nick