Re: [PATCH] Warn about compile-time detected freeing of automatic/static variables (PR c/36970)

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Aug 06, 2008 at 12:32:33PM -0700, Mark Mitchell wrote:
> Richard Guenther wrote:
> 
> >>2008-07-30  Jakub Jelinek  <jakub@redhat.com>
> >>
> >>       PR c/36970
> >>       * builtins.c (maybe_emit_free_warning): New function.
> >>       (expand_builtin): Process BUILT_IN_FREE even at -O0.  Call
> >>       maybe_emit_free_warning for BUILT_IN_FREE.
> >>
> >>       * gcc.dg/free-1.c: New test.
> >>       * gcc.dg/free-2.c: New test.
> 
> I realize I'm late commenting on this, but I think it's unfortunate that 
> we're doing this in the middle end.  Even ignoring my usual rant about 
> middle-end warnings, this is something where giving more linguistic 
> context might be helpful.  For example, talking about "free"-ing things 
> might not make sense in all languages.   So, I'd rather have seen this 
> go into the front ends.
> 
> I suppose the counter-argument is that the middle-end can see through 
> inlining, etc., so that it can tell you about cases the front end can't 
> know about.

Yes, that's precisely the reason why it is done in the middle end and not in
FE.  The FE could only catch the most simple cases where the array is passed
to free, while in the middle end it can catch things like
char buf[10];
char *p = buf;
// big chunk of code
free (p);
If __builtin_free isn't a standard C free in some frontend, then it really shouldn't
be __builtin_free, but just free.

Surely if the FE want to do some reporting earlier, it could do that and
just replace __builtin_free call with a non-builtin one or __builtin_trap,
or set TREE_NO_WARNING and let maybe_emit_free_warning honor it.

	Jakub