I think we breaks the compatibility of .B file time to time. For example,
the changes in TY_IDX for user specific alignment has broken the
compatibility.
2011/9/7 Gang <yugang...@gmail.com>
> **
> 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
>
>
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
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
