| This looked like it *might* a GEM bug so I entered a bug report, #5972.
Turns out to be a front end problem.
Here is the pertinent info from that string...
================================================================================
Note 5972.1 Pascal: Fetch moved before store of pointer aliased variable 1 of 6
GEMEVN::GLOSSOP "Only the paranoid survive" 6 lines 7-FEB-1997 16:53
--------------------------------------------------------------------------------
The store through "myptr" is to a variable called '"Heap"'. The load
reference for the write is from a variable called 'myvar'. Distinct
non-parameter base symbols are *always* disjoint, regardless of anything
else. If you want to take addresses of variables and assign them
to pointers, then you can't describe pointers dereferences as being
to an independent base variable called '"Heap"'...
================================================================================
Note 5972.2 Pascal: Fetch moved before store of pointer aliased variable 2 of 6
GEMEVN::GLOSSOP "Only the paranoid survive" 14 lines 7-FEB-1997 16:58
--------------------------------------------------------------------------------
Note that you have a choice here. If you are only compiling "real"
Pascal programs where pointers only point to the heap, you can continue
to use the '"heap'" symbol. If people are going to take the address
of variables and stuff them into pointers, then the references need
to be unidentified.
(Basically, you can't have optimization based on knowledge that pointers
"normally" point into the heap. Either they *always* do, in which case
using the '"heap"' symbol is a valid description, or they might not,
in which case it isn't.)
If enabling the use of "address()" requires a compiler option, you could
tie your annotation (or not) of pointer dereferences to that option.
If not, then the description isn't ever valid.
================================================================================
Note 5972.4 Pascal: Fetch moved before store of pointer aliased variable 4 of 6
GEMEVN::GLOSSOP "Only the paranoid survive" 3 lines 7-FEB-1997 17:00
--------------------------------------------------------------------------------
One final note. This program can be made to work if the pointer reference
is also declared as a pointer to [volatile] integer, since volatile
references are kept strictly in order, regardless of any other considerations.
================================================================================
Note 5972.5 Pascal: Fetch moved before store of pointer aliased variable 5 of 6
TLE::REAGAN "All of this chaos makes perfect sense" 6 lines 9-FEB-1997 14:21
--------------------------------------------------------------------------------
So having BASE_SYMBOL set to 0 is something valid and meaningful?
We invented the "heap" symbol way back when to make sure that all our
stores and fetches pointed to a base-symbol.
-John
================================================================================
Note 5972.6 Pascal: Fetch moved before store of pointer aliased variable 6 of 6
GEMEVN::GLOSSOP "Only the paranoid survive" 15 lines 9-FEB-1997 15:36
--------------------------------------------------------------------------------
> So having BASE_SYMBOL set to 0 is something valid and meaningful?
Yes.
During the execution of a routine, all non-parameter-aliased-parameters
and non-parameter base symbols are disjoint, by definition. Things that
are parameter aliased may interact with references to parameters, and
things that are pointer aliased may interact with unidentified references.
Note that while there is "is_a_parameter", there is no equivalent
"is_a_pointer", which is what "Heap" would need to be to get the semantics
you would want for ADDRESS(x) being allowed, since it really isn't a symbol
representing just the heap in that case, but rather the heap plus anything
that was pointer aliased. Currently, the is_a_pointer case is represented
by a null base symbol.
|