More test results...

[Gabriel Dos Reis]

Jason Merrill <jason@redhat.com> writes:

| >>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:
| 
| >> No, but the patch under discussion changes several static data members to
| >> be inherited, so the mangled name is different.  If the default is wrong
| >> for a type, it must be overridden in the (derived) specialization, so the
| >> mangled name depends on whether or not the default is correct.
| 
| > Hmm. Well, numeric_limits only has meaning as a specialization. For the
| > required specializations, no derivation is required. It stands to reason
| > that non-required, user-defined specializations would also not be
| > derivations.
| 
| True.  But if it only has meaning as a specialization, why was the change
| useful in the first place?

On first sight, it was thought (admitely, wrongly) that the
ducplicate-symbol problem was coming from the library side whereas, in
fact, it was a compiler problem.  
A reason why I approved it is that it contributes to reduce the footprint.

| > The idea that now __numeric_limits_base* is in the exported symbols list 
| > is the bit that personally makes me nervous. I thought this was the part 
| > that you were nervous about.
| 
| I was concerned about changing the mangled name of, say,
| 
|   std::numeric_limits<std::string>::is_integer

How can a conforming program be affected, now that the corresponding
symbol definition is kept in a single place? 

-- Gaby