On 09/07/2011 07:51 AM, Gang wrote:
On 09/07/2011 10:59 AM, Jian-Xin Lai wrote:
3. In osprey/common/com/opcode_gen_core.h, since OPR_ZDLBR is
added for all targets, why not move it out of the #ifdef and
change the value for the later OPRs?
This is mainly for maintainance, we can add it as the number
of last commonly shared operators. But the operator sequence of
the target-specific operators are changed. So, wopt may not dump
the right output for pre-built intermediates.
I don't understand this well. Is that means we can only append the
new operator to the end of the enum? In opcode_gen_core.cxx, it's
unnecessary to add the new OPR to the end of array. You can insert it
after the "OPR_COMPOSE_BITS".
I am mainly concerned with the consistent problem. Considered the
following case, one build some applications with open64-4.2.4, while
he keeps the intermediate .B files for further investigation. If we
break the operator sequences by inserting new op at the middle, then,
when the .B files are read by the new compiler, semantics are changed,
this introduces the inconsistent.
Fred, would you please kindly input to this?
Thanks
Gang
I concur with Gang that we should add the new operator at the end to
avoid breaking compatibility unnecessarily.
Fred
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
