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
------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
