Re: 1st draft: PRs fixed in 3.1.1

[Joe Buck <Joe dot Buck at synopsys dot com>]

I wrote:
> > Of your list, 6641 isn't really "fixed", it's just documented that
> > the user must rebuild libstdc++ with __USE_MALLOC defined if s/he
> > wishes to use it.
> 
> >> PR libstdc++/6641 -D__USE_MALLOC doesn't link

Loren James Rittle writes:

> I think we did something beyond merely changing the documentation as
> you state:
> 
>         libstdc++/6641
>         * include/bits/c++config (__USE_MALLOC): Report case where
>         the user improperly defined it on the command line.

You are correct.  However, I could still see why some folks might consider
it a regression from 2.9x.

> As you know, just because something used to "link" does not mean it
> "worked".

Correct, but I personally used the feature to track down a memory leak
problem in the past.  I am fully aware of the issues with the
one-definition rule, and I would never ship a binary that mixed code with
__USE_MALLOC with other code.  Just the same, once the change was made,
Purify was immediately enlightening.  I understand why I now have to
rebuild the library, but this was not required before.

> It is possible that there was
> a time (perhaps with v2) when the definition of __USE_MALLOC affected
> none of the code actually compiled within libstdc++ and thus it was
> safe to recompile only the user application code and not the entire
> library but I assure you that this hasn't been true since libstdc++-v3
> as released circa GCC 3.0.

Right, that's it exactly.  But most of the GCC user world is still using
2.x.

> The reported compile-time error just enforces a rule that was
> unchecked before.

I think that the fix was the right thing to do, and I'll describe it
somehow.