[Gc] returning stack address without a warning

Eric Deplagne Eric.Deplagne at wanadoo.fr
Thu Oct 26 05:36:14 PDT 2006


On jeu, 26 oct 2006 13:24:01 +0100, Andrew Haley wrote:
> Eric Deplagne writes:
>  > 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 ?
> 
> Of course.  :-)
> 
> void *stackptr_v2(void)
> {
>   return __builtin_frame_address(0);
> }

  Great...

>  > >  >   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...
> 
> You said that already.  I'm asking why.  If you are prepared to cope
> with a warning at some time in the future, why not simply cope with it
> now?

  Simply because it feels too obvious...

  I really don't cope well with warnings, and I'm only prepared to cope
  with this one because it has a real reason to exist...

  Now the fact is I just tried to make gcc warn on that...
  I added the inline statements and -O3 -finline-functions...
  And gcc did inline as I can tell by the impact it had on the values...
  But gcc did never warn because no line of code is syntactically warnable...

  I'm not the dog trying to catch his tail...... Well, not too long...
  But as it happens I did catch it quite easily...
  So now I'll wait for the compiler to shorten it before I give up...

-- 
  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/fa22d4bd/attachment.pgp


More information about the Gc mailing list