On 6/13/19 10:46 AM, Tom Tromey wrote:
>> "Jeff" == Jeff Law writes:
>
> Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
> Jeff> not sure we can realistically do that.
>
> Are there still platforms or compilers in use where it's needed?
>
> For gdb I was
On 6/13/19 10:46 AM, Tom Tromey wrote:
>> "Jeff" == Jeff Law writes:
>
> Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
> Jeff> not sure we can realistically do that.
>
> Are there still platforms or compilers in use where it's needed?
>
> For gdb I was
On 6/13/19 10:46 AM, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
Jeff> not sure we can realistically do that.
Are there still platforms or compilers in use where it's needed?
For gdb I was planning to just remove
On 6/13/19 10:46 AM, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
Jeff> not sure we can realistically do that.
Are there still platforms or compilers in use where it's needed?
For gdb I was planning to just remove
> "Jeff" == Jeff Law writes:
Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
Jeff> not sure we can realistically do that.
Are there still platforms or compilers in use where it's needed?
For gdb I was planning to just remove these calls.
Tom
> "Jeff" == Jeff Law writes:
Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
Jeff> not sure we can realistically do that.
Are there still platforms or compilers in use where it's needed?
For gdb I was planning to just remove these calls.
Tom
On Thu, Jun 13, 2019 at 03:59:33PM +, Michael Matz wrote:
> without running the risk of unlimited stack use. But of course this would
> promote a programming style that'd only work with our alloca (and not even
> C-alloca), and we want to avoid that. I thought it a cute idea, but was
>
On Thu, Jun 13, 2019 at 03:59:33PM +, Michael Matz wrote:
> without running the risk of unlimited stack use. But of course this would
> promote a programming style that'd only work with our alloca (and not even
> C-alloca), and we want to avoid that. I thought it a cute idea, but was
>
Hi,
On Thu, 13 Jun 2019, Jeff Law wrote:
> > (In fact I think our builtin_alloca implementation could benefit when we
> > added that behaviour as well; it's a natural wish to be able to free
> > memory that you allocated).
>
> Also note that simply sprinkling alloca(0) calls won't magically
Hi,
On Thu, 13 Jun 2019, Jeff Law wrote:
> > (In fact I think our builtin_alloca implementation could benefit when we
> > added that behaviour as well; it's a natural wish to be able to free
> > memory that you allocated).
>
> Also note that simply sprinkling alloca(0) calls won't magically
On 6/12/19 10:40 AM, Jakub Jelinek wrote:
> On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
>> But GCC doesn't support such an implementation, does it?
>
> Why would that be relevant? The warning would cause people to make portable
> code less portable (by removing the alloca (0)
On 6/12/19 10:40 AM, Jakub Jelinek wrote:
> On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
>> But GCC doesn't support such an implementation, does it?
>
> Why would that be relevant? The warning would cause people to make portable
> code less portable (by removing the alloca (0)
On 6/12/19 9:25 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 12 Jun 2019, Martin Sebor wrote:
>
>>> Otherwise LGTM as the patch, but I'd like to hear from others whether
>>> it is kosher to add such a special case to the warn_unused_result
>>> attribute warning. And if the agreement is yes, I
On 6/12/19 9:25 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 12 Jun 2019, Martin Sebor wrote:
>
>>> Otherwise LGTM as the patch, but I'd like to hear from others whether
>>> it is kosher to add such a special case to the warn_unused_result
>>> attribute warning. And if the agreement is yes, I
On 6/12/19 10:40 AM, Jakub Jelinek wrote:
On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
But GCC doesn't support such an implementation, does it?
Why would that be relevant?
Obviously because it makes no sense to cater to all conceivable
extensions provided by all sorts of
On 6/12/19 10:40 AM, Jakub Jelinek wrote:
On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
But GCC doesn't support such an implementation, does it?
Why would that be relevant?
Obviously because it makes no sense to cater to all conceivable
extensions provided by all sorts of
On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
> But GCC doesn't support such an implementation, does it?
Why would that be relevant? The warning would cause people to make portable
code less portable (by removing the alloca (0) calls that were added there
for portability
On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
> But GCC doesn't support such an implementation, does it?
Why would that be relevant? The warning would cause people to make portable
code less portable (by removing the alloca (0) calls that were added there
for portability
On 6/12/19 9:25 AM, Michael Matz wrote:
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
Otherwise LGTM as the patch, but I'd like to hear from others whether
it is kosher to add such a special case to the warn_unused_result
attribute warning. And if the agreement is yes, I think it should be
On 6/12/19 9:25 AM, Michael Matz wrote:
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
Otherwise LGTM as the patch, but I'd like to hear from others whether
it is kosher to add such a special case to the warn_unused_result
attribute warning. And if the agreement is yes, I think it should be
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
> > Otherwise LGTM as the patch, but I'd like to hear from others whether
> > it is kosher to add such a special case to the warn_unused_result
> > attribute warning. And if the agreement is yes, I think it should be
> > documented somewhere that
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
> > Otherwise LGTM as the patch, but I'd like to hear from others whether
> > it is kosher to add such a special case to the warn_unused_result
> > attribute warning. And if the agreement is yes, I think it should be
> > documented somewhere that
On 6/12/19 5:37 AM, Jakub Jelinek wrote:
On Wed, Jun 12, 2019 at 01:30:14PM +0200, Martin Liška wrote:
@@ -9447,10 +9448,19 @@ do_warn_unused_result (gimple_seq seq)
location_t loc = gimple_location (g);
if (fdecl)
- warning_at (loc, OPT_Wunused_result,
On 6/12/19 5:37 AM, Jakub Jelinek wrote:
On Wed, Jun 12, 2019 at 01:30:14PM +0200, Martin Liška wrote:
@@ -9447,10 +9448,19 @@ do_warn_unused_result (gimple_seq seq)
location_t loc = gimple_location (g);
if (fdecl)
- warning_at (loc, OPT_Wunused_result,
On Wed, Jun 12, 2019 at 01:30:14PM +0200, Martin Liška wrote:
> @@ -9447,10 +9448,19 @@ do_warn_unused_result (gimple_seq seq)
> location_t loc = gimple_location (g);
>
> if (fdecl)
> - warning_at (loc, OPT_Wunused_result,
> - "ignoring
On Wed, Jun 12, 2019 at 01:30:14PM +0200, Martin Liška wrote:
> @@ -9447,10 +9448,19 @@ do_warn_unused_result (gimple_seq seq)
> location_t loc = gimple_location (g);
>
> if (fdecl)
> - warning_at (loc, OPT_Wunused_result,
> - "ignoring
On 6/12/19 1:22 PM, Jakub Jelinek wrote:
> On Wed, Jun 12, 2019 at 01:11:09PM +0200, Martin Liška wrote:
>> 2019-06-12 Martin Liska
>>
>> * calls.c (special_function_p): Make it global.
>> * calls.h (special_function_p): Declare.
>
> Why?
Not needed any longer.
>
>> *
On 6/12/19 1:22 PM, Jakub Jelinek wrote:
> On Wed, Jun 12, 2019 at 01:11:09PM +0200, Martin Liška wrote:
>> 2019-06-12 Martin Liska
>>
>> * calls.c (special_function_p): Make it global.
>> * calls.h (special_function_p): Declare.
>
> Why?
Not needed any longer.
>
>> *
On Wed, Jun 12, 2019 at 01:11:09PM +0200, Martin Liška wrote:
> 2019-06-12 Martin Liska
>
> * calls.c (special_function_p): Make it global.
> * calls.h (special_function_p): Declare.
Why?
> * tree-cfg.c (do_warn_unused_result): Do not
> warn for alloca(0).
> ---
On Wed, Jun 12, 2019 at 01:11:09PM +0200, Martin Liška wrote:
> 2019-06-12 Martin Liska
>
> * calls.c (special_function_p): Make it global.
> * calls.h (special_function_p): Declare.
Why?
> * tree-cfg.c (do_warn_unused_result): Do not
> warn for alloca(0).
> ---
On 6/11/19 6:03 PM, Jakub Jelinek wrote:
> On Tue, Jun 11, 2019 at 03:58:27PM +, Michael Matz wrote:
>> On Tue, 11 Jun 2019, Martin Liška wrote:
>>
>>> I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are
>>> properly
>>> guarded within:
>>>
>>> # ifdef C_ALLOCA
>>>
On 6/11/19 6:03 PM, Jakub Jelinek wrote:
> On Tue, Jun 11, 2019 at 03:58:27PM +, Michael Matz wrote:
>> On Tue, 11 Jun 2019, Martin Liška wrote:
>>
>>> I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are
>>> properly
>>> guarded within:
>>>
>>> # ifdef C_ALLOCA
>>>
32 matches
Mail list logo
