Re: Serious bug in auto-import

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Charles Wilson wrote:


> 
> Therefore, I *much* prefer recommending the second of your alternatives 
> -- I wasn't aware that volatile would "fix" it for us. 


To clarify, 'volatile' is not a magic bullet.  It just prevents gcc from 
optimizing our workaround out of existence.  In the absence of 
optimization, this works just as well:
   extern_array[1] --> { type *t=extern_array; t[1] }
   extern_struct.field --> { struct s *t=&extern_struct; t->field }

> (And you can use 
> volatile for ALL THREE cases on cygwin; static, DLL(build), and 
> DLL(linkto) -- I think. I will test this tonight.).  


Yep.  Works fine.  (I know, I know, should be obvious -- but at this 
point, I'm in the "trust nothing unless you've tested it" mode.)

> One question, 
> though:  you say:
> 
>  > /* This stupid workaround is for win32 - do not "optimize" */
>  > volatile int *parr = arr;
> 
> Does your comment mean
>   "Future programmer editing this client code, do not replace references 
> to 'parr' with 'arr'."


After testing with various optimization settings, it is obvious you mean 
this ^^^^

> or
>   "When compiling this source code, do not specify -O{n}"


and not this ^^^^^^^^^

> Therefore, ld's error message should at least HINT at the "use a local 
> variable" possibility.  Your original wording does that.  Then, more 
> detailed stuff would go in the .info file (I'll base my ld.texinfo patch 
> on your explanation below).


In the patch I will soon be posting, I've reversed the order of the two 
solutions, to present the 'auxilliary variable' first, the __declspec() 
second.

 
> 
> Actually, given the "volatile" fix, I like it.  This usage seems to be 
> pretty uncommon, so the bug (and error message) will rarely be hit. 
> Recommending "volatile" markers means when only need to #ifdef on 
> __CYGWIN__ , not a bunch of FOO_STATIC/FOO_DLL_BUILD/FOO_DLL_LINKTO 
> variables.
> 
> Getting rid of THAT garbage was my primary goal in advocating your 
> auto-import stuff in the first place!
> 
> So: we have a rarely triggered bug.  Your patch warns the user and 
> prevents buggy code from being generated. My forthcoming documentation 
> patch (based on your stuff, above) will explain how a user hit by this 
> bug can work around it.  And we still don't need 
> FOO_STATIC/FOO_DLL_BUILD/etc.
> 
> I'm happy.


Okay, combined patch (with ld.texinfo stuff) coming up...

--Chuck