Ok for binutils 2.28

Ok for binutils 2.28

[Tristan Gingold]

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.

Re: Ok for binutils 2.28

[Maciej W. Rozycki]

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

Re: Ok for binutils 2.28

[Nick Clifton]

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

Re: Ok for binutils 2.28

[Alan Modra]

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

Re: Ok for binutils 2.28

[Markus Trippelsdorf]

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

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

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