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 plannin
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 t
> "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
> car
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 re
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) ca
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 thi
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 imp
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 reasons),
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
doc
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 a
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
) == 0)
>
> && integer_zerop (gimple_call_arg (g, 0))
>
> instead?
Yep.
>
> Plus you need a comment explaining why we don't warn about alloca with
> constant 0 argument.
Also done.
Is it fine now?
Martin
>
> Jakub
>
>From dfdb688206
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).
> --- a/gcc/
yet another attribute that will
> be used for alloca only.
>
> Jakub
>
Ok, I've got a patch for it.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From b659c00e54ff3bee736f502e7fa4dc233a814b66 Mon Sep 17 00
16 matches
Mail list logo
