Re: gcc-4_1-branch backports of the long double changes

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Feb 06, 2006 at 12:30:32AM -0200, Alexandre Oliva wrote:
> On Feb  5, 2006, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> > +++ libstdc++-v3/include/bits/localefwd.h	2006-02-04 10:50:30.000000000 +0100
> > +    // 22.1.1 Locale
> > +    class locale;
> > +  
> > +
> >    // 22.1.1 Locale
> >    class locale;
>  
> 
> I don't think there's any good reason to duplicate the forward
> declaration of locale here.

Oops, you're right, fixed in my tree.  The trunk version of the patch didn't
have this problem, it was just a reject resolution bug.

> > +++ libstdc++-v3/src/limits.cc	2006-02-04 11:07:20.000000000 +0100
> > +#define _GLIBCXX_NUM_LIM_COMPAT(type, member, len) \
> > +  extern "C" type _ZNSt14numeric_limitsIeE ## len ## member ## E \
> > +  __attribute__ ((alias ("_ZNSt14numeric_limitsIdE" #len #member "E")))
> 
> Some platforms can't do strong aliases.  Shouldn't this be weak, like
> all other aliases added in this patchset?

We know very well which platforms are ever defining
_GLIBCXX_LONG_DOUBLE_COMPAT, all of them are using ELF, GNU as and GNU ld.
The reason I used strong aliases in some places is that I wanted to have
the same type of symbols as there were previously, i.e. when the symbol
used to be weak, it is a weak alias, when it was strong, it is a strong
alias.  In libstdc++.so.6 it doesn't matter much, but in libstdc++.a it
can.

> Also, shouldn't all of these take the possibility of a leading
> underscore into account?

Again, none of the platforms that compile this code have leading underscore.

> The rest all looked reasonable to me, but I haven't been able to check
> the long mangled names.  I hope you have some automated way of
> generating and checking them.

I used a simple abilist script:
#!/bin/sh
readelf -Ws $1 | sed -n '/\.symtab/,$d;/ UND /d;/@GLIBC_PRIVATE/d;/\(GLOBAL\|WEAK\)/p' | awk '{ if ($4 == "OBJECT") { printf "%s %s %s %s %s\n", $8, $4, $5, $6, $3 } else { printf "%s %s %s %s\n", $8, $4, $5, $6 }}' | LC_ALL=C sort -u
and did a lot of diffing, grepping etc. between output from various
libstdc++.so.6 versions (one from unpatched compiler,
--without-long-double-128 built libstdc++.so.6 (which is identical in
the abilist output) and --with-long-double-128 one).
Some of the checks involved e.g. verifiying that no symbol has been lost
(the only allowable diff -u line starting with - is the --- line
and lines changing say asinl@@GLIBCXX_3.4 into asinl@GLIBCXX_3.4),
verying that all newly added symbols have GLIBCXX_LDBL_* or CXXABI_LDBL_*
symbol versions (_LDBL substring used to signify that the symbol versions
are for an optionally configurable symbol set, even in GCC 4.2 or 4.3
when using old glibc you'd need to not support them), that with the
exception of 4 _Z*__do_put* and 4 _Z*__do_get* symbols that are added
only in _ZNKSt17__gnu_cxx_ldbl128{7num_get,7num_put,9money_get,9money_put}*
there is one to one correspondency between
std::{money,num}_{get,put} and std::__gnu_cxx_ldbl128::{money,num}_{get,put}
symbols (only the former ones use e mangling for long double and the latter
g mangling).

	Jakub