Yes, it fixes the problem 2008/3/12, Mikhail Fursov <[EMAIL PROTECTED]>: > > Please check the patch if it fixes the problem > > > On Wed, Mar 12, 2008 at 3:18 PM, Nikolay Kurtov <[EMAIL PROTECTED]> wrote: > > > JIRA issue created > > https://issues.apache.org/jira/browse/HARMONY-5595 > > > > 2008/3/12, Mikhail Fursov <[EMAIL PROTECTED]>: > > > > > > Looks like the reason is that LabelInst gets its offset in IRBuilder > > only > > > after next HIR inst is added to the block. > > > In this case we see that ILOAD_0 is not represented as HIR inst, so > > > LabelInst gets its offset from the second inst. > > > This is bug in translator. > > > > > > The most simple fix is to move LabelInst bc-offset update from > > > Inst* IRBuilder::appendInst(Inst* inst) { > > > to > > > void IRBuilder::setBcOffset(uint32 bcOffset) > > > > > > Anyway I think this problem is worth creating a JIRA issue. > > > > > > > > > > > > > > > > > > On Wed, Mar 12, 2008 at 2:11 PM, Nikolay Kurtov <[EMAIL PROTECTED]> > > wrote: > > > > > > > Here is the method's code > > > > > > > > public static byte func(byte val) { > > > > byte result = 1; > > > > switch (val) { > > > > case 0: > > > > for (int i = 0; i < 54321; i++) { > > > > result += i; > > > > } > > > > break; > > > > case 1: > > > > result = (byte) (val + 45); > > > > break; > > > > case 4: > > > > result = (byte) (val + 21); > > > > break; > > > > default: > > > > result--; > > > > break; > > > > } > > > > if (result < 30) { > > > > result <<= 1; > > > > } else { > > > > result /= 2; > > > > } > > > > return result; > > > > } > > > > > > > > 2008/3/12, Mikhail Fursov <[EMAIL PROTECTED]>: > > > > > > > > > > Nikolay, could you post a Java method here to reproduce the issue? > > > > > > > > > > > > > > > On Wed, Mar 12, 2008 at 1:29 AM, Nikolay Kurtov <[EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > > > I compiled the same class with JET and OPT, and found a > difference > > > in > > > > > > bytecode-mapping > > > > > > > > > > > > One of branches of switch goes to this code: > > > > > > ;; 58) ILOAD_0 > > > > > > ;; 59) BIPUSH 45 > > > > > > ;; 61) IADD > > > > > > ;; 62) I2B > > > > > > ;; 63) ISTORE_1 > > > > > > .... > > > > > > So, after the recompilation by OPT, the block should begin from > > > > bcOffset > > > > > > 58 > > > > > > > > > > > > In OPT after translator I found in irdump the following block > > > > > > Block L5: > > > > > > Predecessors: ENTRY_L0 > > > > > > Successors: L8 > > > > > > I5:L5: bcmap:59 > > > > > > I34:ldci4 #45 -) t14:int32 > > > > > > I35:add t1, t14 -) t15:int32 > > > > > > I36:convi1 t15 -) t16:int32 > > > > > > I37:stvar t16 -) v1:int32 > > > > > > .... > > > > > > > > > > > > The block begins from bcOffset 59 > > > > > > I consider these values in JET and OPT should be equal. > > > > > > Is it a bug? > > > > > > > > > > > > Now I'm exploring the code of JavaByteCodeTranslator and > IRBuilder > > > but > > > > > > cannot figure out the cause of problem > > > > > > Can you advise me how to fix it? > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Nikolay > > > > > > > > > > > > mailto: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Mikhail Fursov > > > > > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > Nikolay > > > > > > > > mailto: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > -- > > > > > > Mikhail Fursov > > > > > > > > > > > -- > > Regards, > > Nikolay > > > > mailto: [EMAIL PROTECTED] > > > > > > > -- > > Mikhail Fursov >
-- Regards, Nikolay mailto: [EMAIL PROTECTED]
