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
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
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 th
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
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 be
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
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
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 variou
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 i
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 back
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.
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 d
12 matches
Mail list logo
