Re: [google] Add support for delete operator that takes the size of the object as a parameter
ok. David On Sat, Dec 17, 2011 at 11:44 AM, Easwaran Raman wrote: > 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 > > * common.opt (fsized-delete): New option. > > cp/ChangeLog.google-main: > > 2011-12-17 Easwaran Raman > > * 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 > > * g++.dg/other/sized-delete-1.C: New test. > > libstdc++-v3/ChangeLog.google-main: > > 2011-12-17 Easwaran Raman > > * 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 > wrote: >> Hi, >> >>> On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini >>> 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.
Re: [google] Add support for delete operator that takes the size of the object as a parameter
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 * common.opt (fsized-delete): New option. cp/ChangeLog.google-main: 2011-12-17 Easwaran Raman * 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 * g++.dg/other/sized-delete-1.C: New test. libstdc++-v3/ChangeLog.google-main: 2011-12-17 Easwaran Raman * 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 wrote: > Hi, > >> On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini >> 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. Index: libstdc++-v3/libsupc++/del_op.cc === --- libstdc++-v3/libsupc++/del_op.cc (revision 182251) +++ libstdc++-v3/libsupc++/del_op.cc (working copy) @@ -46,3 +46,11 @@ operator delete(void* ptr) throw () if (ptr)
Re: [google] Add support for delete operator that takes the size of the object as a parameter
Hi, On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini 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.
Re: [google] Add support for delete operator that takes the size of the object as a parameter
On Mon, Dec 12, 2011 at 1:52 PM, Easwaran Raman wrote: > On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini > 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. > >> >>> 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? 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. > > Thanks, > Easwaran It looks like running 'make new-abi-baseline' under TARGET/libstdc++-v3/testsuite generates the baseline file. Should I check in that? What about other targets? Thanks, Easwaran > >> Paolo.
Re: [google] Add support for delete operator that takes the size of the object as a parameter
On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini 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. > >> 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? 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. Thanks, Easwaran > Paolo.
Re: [google] Add support for delete operator that takes the size of the object as a parameter
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. 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. Paolo.
Re: [google] Add support for delete operator that takes the size of the object as a parameter
Thanks for the comments Paolo. I have attached the new patch. I have
bumped the version to 3.4.18 and used _ZdlPv[jmy] in gnu.ver. I have
also added the symbol to baseline_symbols.txt of other targets.
-Easwaran
2011-12-11 Easwaran Raman
* common.opt (fsized-delete): New option.
cp/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman
* 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-4_6:
2011-12-11 Easwaran Raman
* g++.dg/other/sized-delete-1.C: New test.
libstdc++-v3/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman
* 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/post/i386-linux-gnu/baseline_symbols.txt: Add
new symbol _ZdlPvm@@GLIBCXX_3.4.18.
* config/abi/post/sparc-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/mips64-linux-gnu/64/baseline_symbols.txt: Likewise.
* config/abi/post/mips64-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/s390-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Likewise.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/mips-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Likewise.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Likewise.
* config/abi/post/ia64-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/solaris2.10/amd64/baseline_symbols.txt: Likewise.
* config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt: Likewise.
* config/abi/post/solaris2.10/baseline_symbols.txt: Likewise.
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Likewise.
* config/abi/post/solaris2.8/sparcv9/baseline_symbols.txt: Likewise.
* config/abi/post/solaris2.8/baseline_symbols.txt: Likewise.
* config/abi/pre/gnu.ver: Add new symbol _ZdlPv[jmy] at version
GLIBCXX_3.4.18.
On Mon, Dec 12, 2011 at 5:25 AM, Paolo Carlini wrote:
> On 12/12/2011 02:21 PM, Diego Novillo wrote:
>>
>> Ah, right. I missed the ABI implications.
>
> For possible inclusion in mainline too, things don't seem completely ok:
> nothing should be added to the baseline and very likely the export should be
> adjusted to accommodate for different size_t on the various targets, by
> using [] in the pattern. See, eg, the existing operator new[](size_t).
>
> Paolo.
Index: libstdc++-v3/libsupc++/del_op.cc
===
--- libstdc++-v3/libsupc++/del_op.cc (revision 182251)
+++ libstdc++-v3/libsupc++/del_op.cc (working copy)
@@ -46,3 +46,11 @@ operator delete(void* ptr) throw ()
if (ptr)
std::free(ptr);
}
+
+_GLIBCXX_WEAK_DEFINITION void
+operator delete(void* ptr,
+std::size_t bytes __attribute__((__unused__))) throw ()
+{
+ if (ptr)
+std::free(ptr);
+}
Index: libstdc++-v3/libsupc++/new
===
--- libstdc++-v3/libsupc++/new (revision 182251)
+++ libstdc++-v3/libsupc++/new (working copy)
@@ -93,6 +93,7 @@ namespace std
void* operator new(std::size_t) throw (std::bad_alloc);
void* operator new[](std::size_t) throw (std::bad_alloc);
void operator delete(void*) throw();
+void operator delete(void*, std::size_t) throw();
void operator delete[](void*) throw();
void* operator new(std::size_t, const std::nothrow_t&) throw();
void* operator new[](std::size_t, const std::nothrow_t&) throw();
Index: libstdc++-v3/testsuite/util/testsuite_abi.cc
===
--- libstdc++-v3/testsuite/util/testsuite_abi.cc (revision 182251)
+++ libstdc++-v3/testsuite/util/testsuite_abi.cc (working copy)
@@ -195,6 +195,7 @@ check_version(symbol& test, bool added)
known_versions.push_back("GLIBCXX_3.4.15");
known_versions.push_back("GLIBCXX_3.4.16");
known_versions.push_back("GLIBCXX_3.4.17");
+ known_
Re: [google] Add support for delete operator that takes the size of the object as a parameter
On 12/12/2011 02:21 PM, Diego Novillo wrote: Ah, right. I missed the ABI implications. For possible inclusion in mainline too, things don't seem completely ok: nothing should be added to the baseline and very likely the export should be adjusted to accommodate for different size_t on the various targets, by using [] in the pattern. See, eg, the existing operator new[](size_t). Paolo.
Re: [google] Add support for delete operator that takes the size of the object as a parameter
On Mon, Dec 12, 2011 at 08:17, Paolo Carlini wrote: > On 12/12/2011 02:14 PM, Diego Novillo wrote: >> >> On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote: >> >>> Bootstraps and no test regressions. OK for google/gcc-4_6 branch? >> >> Any reason not to put this in google/main for future trunk inclusion. >> Should this be backported to gcc-4_6-branch? > > 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) Ah, right. I missed the ABI implications. Thanks. Diego.
Re: [google] Add support for delete operator that takes the size of the object as a parameter
On 12/12/2011 02:14 PM, Diego Novillo wrote: On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote: Bootstraps and no test regressions. OK for google/gcc-4_6 branch? Any reason not to put this in google/main for future trunk inclusion. Should this be backported to gcc-4_6-branch? 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) Paolo.
Re: [google] Add support for delete operator that takes the size of the object as a parameter
On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote: > Bootstraps and no test regressions. OK for google/gcc-4_6 branch? Any reason not to put this in google/main for future trunk inclusion. Should this be backported to gcc-4_6-branch? Diego.
[google] Add support for delete operator that takes the size of the object as a parameter
In the tcmalloc memory
allocator(http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html),
deallocation involves a costly lookup to get the size of the deleted
object. The size is required to find the right free list to release
back the object. By passing the size of the object to the delete
call, this lookup can be avoided. This patch adds support for operator
delete(void*, size_t) guarded by a -fsized-delete flag. It also adds a
default implementation of delete(void *, size_t) that ignores the size
parameter.
Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
---
2011-12-11 Easwaran Raman
* common.opt (fsized-delete): New option.
cp/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman
* 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-4_6:
2011-12-11 Easwaran Raman
* g++.dg/other/sized-delete-1.C: New test.
libstdc++-v3/ChangeLog.google-4_6:
2011-12-11 Easwaran Raman
* 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.17.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Add
new symbol _ZdlPvm@@GLIBCXX_3.4.17.
* config/abi/pre/gnu.ver: Add new symbol _ZdlPvm at version
GLIBCXX_3.4.17.
Index: libstdc++-v3/libsupc++/del_op.cc
===
--- libstdc++-v3/libsupc++/del_op.cc (revision 182213)
+++ libstdc++-v3/libsupc++/del_op.cc (working copy)
@@ -46,3 +46,11 @@ operator delete(void* ptr) throw ()
if (ptr)
std::free(ptr);
}
+
+_GLIBCXX_WEAK_DEFINITION void
+operator delete(void* ptr,
+std::size_t bytes __attribute__((__unused__))) throw ()
+{
+ if (ptr)
+std::free(ptr);
+}
Index: libstdc++-v3/libsupc++/new
===
--- libstdc++-v3/libsupc++/new (revision 182213)
+++ libstdc++-v3/libsupc++/new (working copy)
@@ -93,6 +93,7 @@ namespace std
void* operator new(std::size_t) throw (std::bad_alloc);
void* operator new[](std::size_t) throw (std::bad_alloc);
void operator delete(void*) throw();
+void operator delete(void*, std::size_t) throw();
void operator delete[](void*) throw();
void* operator new(std::size_t, const std::nothrow_t&) throw();
void* operator new[](std::size_t, const std::nothrow_t&) throw();
Index: libstdc++-v3/testsuite/util/testsuite_abi.cc
===
--- libstdc++-v3/testsuite/util/testsuite_abi.cc (revision 182213)
+++ libstdc++-v3/testsuite/util/testsuite_abi.cc (working copy)
@@ -194,6 +194,7 @@ check_version(symbol& test, bool added)
known_versions.push_back("GLIBCXX_3.4.14");
known_versions.push_back("GLIBCXX_3.4.15");
known_versions.push_back("GLIBCXX_3.4.16");
+ known_versions.push_back("GLIBCXX_3.4.17");
known_versions.push_back("GLIBCXX_LDBL_3.4");
known_versions.push_back("GLIBCXX_LDBL_3.4.7");
known_versions.push_back("GLIBCXX_LDBL_3.4.10");
@@ -560,4 +561,3 @@ demangle(const std::string& mangled)
}
return name;
}
-
Index: libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
===
--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt (revision 182213)
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt (working copy)
@@ -2422,6 +2422,7 @@ FUNC:_ZTv0_n24_NSt9strstreamD1Ev@@GLIBCXX_3.4
FUNC:_ZdaPv@@GLIBCXX_3.4
FUNC:_ZdaPvRKSt9nothrow_t@@GLIBCXX_3.4
FUNC:_ZdlPv@@GLIBCXX_3.4
+FUNC:_ZdlPvm@@GLIBCXX_3.4.17
FUNC:_ZdlPvRKSt9nothrow_t@@GLIBCXX_3.4
FUNC:_Znam@@GLIBCXX_3.4
FUNC:_ZnamRKSt9nothrow_t@@GLIBCXX_3.4
Index: libstdc++-v3/config/abi/pre/gnu.ver
===
--- libstdc++-v3/config/abi/pre/gnu.ver (revision 182213)
+++ libstdc++-v3/config/abi/pre/gnu.ver (working copy)
@@ -1279,6 +1279,13 @@ GLIBCXX_3.4.16 {
} GLIBCXX_3.4.15;
+GLIBCXX_3.4.17 {
+
+# operator delete(void*, , unsigned long)
+_ZdlPvm;
+
+} GLIBCXX_3.4.16;
+
# Symbols in the support library (libsupc++) have their own tag.
CXXABI_1.3 {
Index: gcc/testsuite/g++.dg/other/sized-delete-1.C
===
--- gcc/testsuite/g++.dg/other/sized-delete-1.C (revision 0)
+++ gcc/testsuite/g++.dg/other/sized-delete-1.C (revision 0)
@@ -0,0 +1,14 @@
+// { dg-do link}
+// { dg-opt
