Re: A TOT bug in handling volatile vars?

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Sep 06, 2002 at 05:33:26PM -0700, Ziemowit Laski wrote:
> I'm combing through my backlog of Apple/NeXT gcc bugs :-), and
> ran into the following long-standing ditty:
> 
>   #include <stdio.h>
>   #include <setjmp.h>
> 
>   jmp_buf jenv;
> 
>   int main(int ac, char *av[])
>   {
>     volatile char *v1 = 0; /* declare volatile so compiler knows we may 
> do
>                             things with this variable that it can not
>                             detect.  It should, therefore tread very
>                             lightly when optimizing code that uses this.
>                             */
> 
>     printf("v1 (%d) %s\n",
>                 v1, v1);
> 
>         if (!setjmp(jenv))    {
>                 v1 = new char[25];
> 
>                 printf("v1 (%d) %s\n", v1, "should not be null");
> 
>                 delete (v1);
>                 v1=NULL;
>                 longjmp(jenv,1);
>         } else {
>                 printf("v1 (%d) %s\n", v1, "should be null");
>         }
>   }
> 
> When built without optimizations on i686-pc-linux-gnu, the program
> produces
> 
>   v1 (0) (null)
>   v1 (134935784) should not be null
>   v1 (0) should be null
> 
> as I would expect.  But the moment you supply -O, the output changes
> to
> 
>   v1 (0) (null)
>   v1 (134935784) should not be null
>   v1 (134935784) should be null
> 
> which is somewhat less to my liking (in spite of the fact that
> previous gcc releases apparently generated this for many, many years).
> 
> So my question for the experts is, is this a bug?  Personally, I
> think so.  Had v1 _not_ been marked volatile, I could see the
> compiler deciding that 'v1=NULL;' is dead code (assuming that
> it does not recognize the magical powers of longjmp -- does it
> have to, anyway?).  But since v1 _is_ volatile, I would expect
> the store to be emitted anyway.  Or am I off in the weeds somewhere?

You're off in the weeds somewhere :)  Volatile is a qualifier on char,
not a qualifier on *.  There's nothing special about v1 at all, only
about what it points to.

If I use:
  volatile char *volatile v1 = 0; 

it behaves as you expect.  Heck, even turn on warnings:
tst.c:6: warning: variable `volatile char * v1' might be clobbered by `longjmp' or `vfork'


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer