Version script vs. mangled names on systems where size_type != unsigned int

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

    Hi all,

  PR42377 is a bug where we're building a 32/64-biarch multilibbed compiler on
the x86_64-w64-mingw32 target.  In the 64-bit version of the libstdc++ dll,
the std::string::reserve function is not getting exported.

  To cut a long story right down to the bare bones, the function prototype is

>       void
>       reserve(size_type __res_arg = 0);

and for the 32-bit arch, size_type is unsigned int, but for the 64-bit arch,
size_type is unsigned long long.

  This gives the 32-bit and 64-bit versions of std::string::reserve the
mangled names _ZNSs7reserveEj and _ZNSs7reserveEy respectively, and that is
where the problem arises, because the line in the libstdc++ version script
responsible for exporting these std::string functions looks like so:

>      _ZNSs[67][j-z]*E[PRcjmv]*;

and the trailing 'y' on the 64-bit version of the function's signature fails
to match that final character class.

  Should we just add a 'y' in there?  I think it might be that this hasn't
been a problem on any of the other 64-bit arches because win64 is the only
LLP64 target we support, and it's only just gained support for shared libstdc;
on all the other 64-bit targets the size_type will still be an unsigned
integer, but on this target the ABI says that size_type is a ULL, so that
means that the signatures of ABI functions are going to be different on this
machine from other machines.

    cheers,
      DaveK