Re: patches to move to gcc-3_2-branch

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20021204232050.1d0425e7.bkoz@redhat.com>,
Benjamin Kosnik<bkoz@redhat.com> writes:

>> Upon looking at it closely, it is really hard for me to consider this
>> a regression.  User's use of __USE_MALLOC has always been problematic
>> in v3. 

> This is a regression against 2.95 era compilers (v2), where __USE_MALLOC
> was possible. I thought these still counted, or do all regressions have
> to be against 3.x series compilers? Perhaps I'm just confused.

> I'm in favor of this patch. It resolves longstanding issues with
> the allocators, improves (aye, makes possible) debugging, and in a sane
> way. 

I will not complain if you install it.  I just got cold feet from
doing it myself.

>> I probably would have moved it without any thought but the merge of
>> include/bits/stl_alloc.h produced a large conflict because many patches
>> were made to formatting, etc on mainline.

> I have moved this patch as well, in my sources, and just moved the
> formatting as well.

OK, had I known that was allowed, I might have proceeded. ;-)

> Do you think a better solution is to put it on the rhl8 branch, instead?
> I am open to this possibility, but consider it less appealing.

> Note that the added symbol has to be in GLIBCPP_3.2.2 now for the
> branch, since 3.2.1 has now been released

Yes, of course.  I hope I would have known to do that version bump
when transferring it.  I think I would have.  I did remember that you
had to follow-up my patch with a symbol export.

If you have the final patch form that you are happy with, then please
commit it under the rule that it is a regression from 2.95.  Whether
it is a regression or not, it has surely produced PRs as if it were a
regression.

Regards,
Loren