[Gc] returning stack address without a warning

Eric Deplagne Eric.Deplagne at wanadoo.fr
Thu Oct 26 05:09:16 PDT 2006


On Thu, 26 Oct 2006 12:31:24 +0100, Andrew Haley wrote:
> Eric Deplagne writes:
>  > On Thu, 26 Oct 2006 11:33:20 +0100, Andrew Haley wrote:
>  > > Eric Deplagne writes:
>  > >  > > My goal with -Wall and similar is to at least document any remaining
>  > >  > > warnings in the source.  The collector inherently does a few things that
>  > >  > > should generate warnings in "normal" code, e.g. it returns the address
>  > >  > > of a local to get an upper bound on the stack pointer.  This also really
>  > >  > > applies only to gc7.
>  > >  > 
>  > >  > If there's nothing clever I didn't notice on the way, using an helper
>  > >  > function is enough to prevent the compiler from noticing what we're doing
>  > >  > to that poor local variable...
>  > > 
>  > > No, that's a bad idea.  Later versions of the compiler may well see
>  > > through this trick and you'll get the warning again.  It is better
>  > > either to use a properly supported way to the the stack address or to
>  > > live with the warning than to go through such contortions.
>  > 
>  >   Well... The first part of your "or" statement is obviouly false,
>  >   there is no supported way to get the stack address...
> 
> Well, I'm talking about gcc.  There is no official ISO way of doing
> it, true, but what is being done here isn't portable in any case.  (Of
> course there cannot be an ISO way of doing it, since ISO C doesn't
> even mandate the use of a stack.)  So, if you're using gcc you might
> as well do it in a properly supported way, and leave the warning for
> other compilers.

  Is there a supported way in gcc ?

>  >   As for a compiler noticing this trick, it might happen, but I really
>  >   doubt it, as long as the helper function doesn't get inlined...
> 
> Bingo.  It's perfectly reasonable for the compiler to inline very
> small functions.

  Yes... But it's doubtful it will do it without an "inline" statement...

  And it might even do it with some -O option, and not check this kind
  of things at that time...

>  >   IMHO one more function away is not such a "contortion" that it's not worth it...
>  >   And for the case a compiler was clever enough to still bark, I guess I would then
>  >   cope with the warning, having done what is possible to avoid it...
> 
> So, if you are prepared to cope with a warning at some time in the
> future, why not simply cope with it now?  Contorting code to avoid
> compiler warnings is, as they say, "the tail wagging the dog".

  The point is that the single function stackptr_v1() is in itself "odd"...

  Instead, each of the two functions stackptr_v2() and stackptr_v2_helper(),
  is perfectly ok... It's their interraction that does the odd thing...

  That should keep the compiler away from noticing in most cases...
  And in the case it does notice, then I have enough respect for that to cope
  with the warning...

-- 
  Eric Deplagne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20061026/f7335d38/attachment.pgp


More information about the Gc mailing list