[google] Add support for delete operator that takes the size of the object as a parameter

[Easwaran Raman]

Based on Paolo's comments I am dropping the changes to
baseline_symbols.txt. As far as minor version, I am bumping it up to
18. Assuming that this patch will be able to go in gcc 4.8 (with minor
version 18), I want to keep it at the same version in google/main and
google/gcc-4_6.

Bootstraps and no test regression. OK for google/main and
google/gcc-4_6 branches?

---------
011-12-17  Easwaran Raman  <eraman@google.com>

	* common.opt (fsized-delete): New option.

cp/ChangeLog.google-main:

2011-12-17  Easwaran Raman  <eraman@google.com>

	* decl.c (cxx_init_decl_processing): Specify a function that
	  takes a void* and size_t for DELETE_EXPR.
	* call.c (build_op_delete_call): If fsized-delete is used, use
	  the variant that takes size_t as the second parameter except
	  when deleteting a pointer of type void *.

testsuite/ChangeLog.google-main:

2011-12-17  Easwaran Raman  <eraman@google.com>

	* g++.dg/other/sized-delete-1.C: New test.

libstdc++-v3/ChangeLog.google-main:

2011-12-17  Easwaran Raman  <eraman@google.com>

	* libsupc++/del_op.cc (delete): Define a new variant
	  void operator delete(void*, std::size_t).
	* libsupc++/new (delete): Declare
	  void operator delete(void*, std::size_t) throw();
	* testsuite/util/testsuite_abi.cc (check_version): Add new
	  known version GLIBCXX_3.4.18.
	* config/abi/pre/gnu.ver: Add new symbol _ZdlPv[jmy] at version
	  GLIBCXX_3.4.18.

On Wed, Dec 14, 2011 at 3:31 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
>> On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini
>> <paolo.carlini@oracle.com>  wrote:
>>>
>>> On 12/12/2011 09:37 PM, Easwaran Raman wrote:
>>>>
>>>> Thanks for the comments Paolo. I have attached the new patch. I have
>>>> bumped the version to 3.4.18
>>>
>>> You shouldn't: 4.7 is not out yet, thus no reason to increase the minor
>>> version beyond the current 17.
>>
>> Ok, I then don't understand your comment
>>  "Note that backporting the patch as-is to 4_6-branch would be very
>> wrong in terms of ABI (in mainline we already have a 3.4.17)".
>> My original patch added the new symbol in version 3.4.17. Since we
>> don't want to add the symbol to 3.4.16 (if we have a situation where
>> the new runtime is not available when running a program compiled with
>> -fsized-delete) and you   said I shouldn't be using 3.4.17, I assumed
>> I had to bump up the version.
>
> Note this is going to be an academic discussion, because it's too late for
> 4.7 anyway, and I'm not even sure it's conforming to add overloads like this
> for operators.
>
> Anyway.
>
> For 4.6 branch at this point the situation would be very difficult. We could
> have a small time window before 4.7 is out to move **all** its new symbols
> vs 4.6, currently in 3.4.17,  to a new 3.4.18 and then we could bump 4.6 to
> 3.4.17. You see, after a minor is delivered you cannot add anything to it,
> and also you have the general requirement that the minor version is the
> minor ersion, thus irrespective whether we are talking about gcc4.6 or
> gcc4.7, a specific minor version number defines which symbols are exported.
> I hope now the issues are more clear.You must be always very careful.
>
>>>>  and used _ZdlPv[jmy] in gnu.ver.  I have
>>>> also added the symbol to baseline_symbols.txt of other targets.
>>>
>>> You should not, just read again what I wrote. And you don't have to
>>> believe
>>> me: just browse the libstdc++ ChangeLogs and see if somebody ever does
>>> that
>>> when the linker map is touched.
>>
>> Sorry, I again misunderstood this as well (and still don't have a good
>> picture). Is the part which adds _ZdlPv[jmy] in gnu.ver ok?
>
> Looks fine yes. But I didn't really check the letters. General rule of thumb
> when fiddling with linker scripts: double check what you are doing with a
> multilib system, like x86_64, at least you can catch errors when you are
> mistakenly not accounting for the 32-bit version of the symbols. In the case
> at issue, size_t can boil down be unsigned int, unsigned long, unsigned long
> long, make sure the pattern includes all three.
>
>> I added
>> that by mimicking the symbol  _Znw[jmy] found in the same file. From
>> the log, it looks like the baseline_symbols.txt seems to be generated,
>> but I am not sure how that is to be done. For example, r145437 says a
>> bunch of these baseline_symbols.txt are regenerated, but I don't see
>> any other change from which this might be generated.
>
> General rule of thumb: normally, if you aren't a release manager, or a
> maintainer, **never** regenerate the baseline_symbols files. Just add
> symbols to the linker script, that is normally fine, doesn't break anything
> per se, adding is fine (subtracting/changing is not, of course).
>
> Paolo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sized_delete.patch
Type: text/x-patch
Size: 6470 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20111217/8e61637f/attachment.bin>