[Info-vax] yet another sys$qiow question

[Bob Gezelter]

On Friday, August 21, 2015 at 4:02:44 PM UTC-4, Craig A. Berry wrote:
> On 8/21/15 1:07 PM, Stephen Hoffman wrote:
> > On 2015-08-21 16:26:04 +0000, Craig A. Berry said:
> >
> 
> >> The only thing the discussion of volatile has added is yet another
> >> reason not to do it that way [polling IOSB].
> >
> > Unfortunately and AFAICT, omitting volatile for any of the completion
> > paths means that any of the IOSB paths can potentially pick up a bogus
> > value.  That seems very unlikely, but it is permissible behavior for the
> > compilers.
> 
> According to the C standard, everything is effectively volatile when it
> crosses from one "translation unit" to another, i.e., not in the same
> pre-processed source file.[1] As long as SYS$SYNCH is a real routine and
> not a macro or inlined function, it's always going to be in a different
> translation unit from user code, so when passing the IOSB by reference
> to SYS$SYNCH, it would be redundant to make it volatile.
> 
> AST completion routines that check an IOSB declared as a file scope or
> otherwise global struct *might* get into trouble. I'm not sure about
> that case. But the more normal method would be to have the IOSB hanging
> off the AST parameter, and in this case, volatile would also be
> redundant because function parameters and anything they point to are
> required to be interpreted according to "abstract semantics,", i.e., the
> code as written, without any optimizations.
> 
> My footnotes reference the C99 standard, section 5.1.2.3 item 10. It's a
> description of a possible implementation, but the only alternative
> implementation described is one that performs no optimizations at all.
> So I'm considering what I've quoted as an indication of what must happen
> in a compiler that does any optimizations. I'm sure someone will point
> it out if I've misread anything.
> 
> 
> [1] "an implementation might perform various optimizations within each
> translation unit, such that the actual semantics would agree with the
> abstract semantics only when making function calls across translation
> unit boundaries."
> 
> 
> [2] "at the time of each such function entry the values of the
> parameters of the called function and of all objects accessible via
> pointers therein would agree with the abstract semantics."

Craig,

I do not recall what the C standard says on the subject offhand, but in general, one must presume when generating code that variables in a global scope are subject to change when invoking an out-of-line subroutine (This was the reasoning behind my previous comments that an out-of-line invocation ends a basic block).

- Bob Gezelter, http://www.rlgsc.com