On Thu, Aug 4, 2011 at 3:50 PM, Gabriel Dos Reis
wrote:
> On Thu, Aug 4, 2011 at 8:43 AM, Jason Merrill wrote:
>> On 08/04/2011 08:58 AM, Gabriel Dos Reis wrote:
>>>
>>> Do you intend to rule out garbage collectors?
>>
>> No, I suppose the rule should be that interleaved access through the
>> ret
On Thu, Aug 4, 2011 at 8:43 AM, Jason Merrill wrote:
> On 08/04/2011 08:58 AM, Gabriel Dos Reis wrote:
>>
>> Do you intend to rule out garbage collectors?
>
> No, I suppose the rule should be that interleaved access through the
> returned pointer and other ways is undefined.
OK.
>> Should not ac
On 08/04/2011 08:58 AM, Gabriel Dos Reis wrote:
Do you intend to rule out garbage collectors?
No, I suppose the rule should be that interleaved access through the
returned pointer and other ways is undefined.
Should not access as raw memory (e.g. through char* or void*) be allowed?
No, ac
On Thu, Aug 4, 2011 at 3:01 PM, Richard Guenther
wrote:
> On Thu, Aug 4, 2011 at 2:58 PM, Gabriel Dos Reis
> wrote:
>> On Wed, Aug 3, 2011 at 1:14 PM, Jason Merrill wrote:
>>> On 08/03/2011 08:46 AM, Richard Guenther wrote:
If that's reasonable then adding the malloc attribute should b
On Thu, Aug 4, 2011 at 2:58 PM, Gabriel Dos Reis
wrote:
> On Wed, Aug 3, 2011 at 1:14 PM, Jason Merrill wrote:
>> On 08/03/2011 08:46 AM, Richard Guenther wrote:
>>>
>>> If that's reasonable then adding the malloc attribute should be, too.
>>> Finally. Please. Doesn't C++0x maybe "fix" the issu
On Wed, Aug 3, 2011 at 1:14 PM, Jason Merrill wrote:
> On 08/03/2011 08:46 AM, Richard Guenther wrote:
>>
>> If that's reasonable then adding the malloc attribute should be, too.
>> Finally. Please. Doesn't C++0x maybe "fix" the issue we were
>> discussing to death?
>
> Nope, as far as I can tel
On 08/03/2011 02:26 PM, Jakub Jelinek wrote:
As for the properties which the middle-end would like to assume or not
from the operator new/operator new[]:
1) for alloc_size it is whether the returned pointer has exactly the
requested bytes defined, i.e. can't return a buffer where only fewer bytes
On Wed, Aug 03, 2011 at 02:31:17PM +0200, Jakub Jelinek wrote:
> 2011-08-03 Jakub Jelinek
>
> PR middle-end/49905
> * decl.c (cxx_init_decl_processing): Add alloc_size (1) attribute
> for operator new and operator new [].
Unfortunately the patch caused a bunch of regressions,
On 08/03/2011 08:46 AM, Richard Guenther wrote:
If that's reasonable then adding the malloc attribute should be, too.
Finally. Please. Doesn't C++0x maybe "fix" the issue we were
discussing to death?
Nope, as far as I can tell nobody raised it with the committee. I have now.
I think we ough
On Wed, Aug 03, 2011 at 03:55:39PM +0200, Richard Guenther wrote:
> On Wed, Aug 3, 2011 at 3:06 PM, Paolo Bonzini wrote:
> > On 08/03/2011 02:46 PM, Richard Guenther wrote:
> >>
> >> If that's reasonable then adding the malloc attribute should be, too.
> >
> > Making aliasing stricter for -D_FORTI
On Wed, Aug 3, 2011 at 3:06 PM, Paolo Bonzini wrote:
> On 08/03/2011 02:46 PM, Richard Guenther wrote:
>>
>> If that's reasonable then adding the malloc attribute should be, too.
>
> Making aliasing stricter for -D_FORTIFY_SOURCE=2 sounds wrong though.
The patch unconditionally adds malloc_size.
On 08/03/2011 02:46 PM, Richard Guenther wrote:
If that's reasonable then adding the malloc attribute should be, too.
Making aliasing stricter for -D_FORTIFY_SOURCE=2 sounds wrong though.
Paolo
On Wed, Aug 3, 2011 at 2:31 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in PR49905, -D_FORTIFY_SOURCE{,=2} handles e.g.
> malloc (4) or malloc (16) well, knowing that the resulting pointer
> has object size 4 resp. 16, but for new int or new int[4], it currently
> doesn't assume anything (i.e.
Hi!
As mentioned in PR49905, -D_FORTIFY_SOURCE{,=2} handles e.g.
malloc (4) or malloc (16) well, knowing that the resulting pointer
has object size 4 resp. 16, but for new int or new int[4], it currently
doesn't assume anything (i.e. __builtin_object_size (new int, 0) returns
-1). While I see the
14 matches
Mail list logo
