ok. David
On Sat, Dec 17, 2011 at 11:44 AM, Easwaran Raman <era...@google.com> 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 <era...@google.com> > > * common.opt (fsized-delete): New option. > > cp/ChangeLog.google-main: > > 2011-12-17 Easwaran Raman <era...@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 <era...@google.com> > > * g++.dg/other/sized-delete-1.C: New test. > > libstdc++-v3/ChangeLog.google-main: > > 2011-12-17 Easwaran Raman <era...@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.carl...@oracle.com> > wrote: >> Hi, >> >>> On Mon, Dec 12, 2011 at 12:41 PM, Paolo Carlini >>> <paolo.carl...@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.
