Re: [Open64-devel] Request for Code Review: bug #707

2011-02-28 Thread Feng Zhou
Hello, all I have attached an updated version of bug fix to #707. -- The following code snippet: loc = 0; buffer[limit] = 33; while (buffer[loc] == 32 |

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Min Zhao
in opt_ssa.cxx (starting line 1595): 1589 // === 1590 // Resurrect_chi - A chi node that was dead has to be resurrected 1591 // because ILOAD to LDID folding introduces a real use of the result of the 1592 // chi; need

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Sun Chan
Can you show the code for resurrect_chi? The proposed source change is quite big, yet, standard, I'd like to know if something is missing, or if there is already existing code that does similar thing Sun On Thu, Feb 10, 2011 at 8:52 AM, Min Zhao wrote: > > You mean the source code of iload foldin

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Min Zhao
You mean the source code of iload folding? It is in opt_htable.cxx (from line 2874). Here is where to do resurrect,opt_htable.cxx : 2875 // go thru chi list to find the scalar var version 2876 CHI_NODE *cnode; 2877 CHI_LIST_ITER chi_iter; 2878 FOR_ALL_NODE(cnode, chi_i

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Sun Chan
can you include the code in iload folding that tries to do the same thing, i.e. resurrect the version? Thx! Su On Thu, Feb 10, 2011 at 8:08 AM, Min Zhao wrote: > > Yes. > > On Wed, Feb 9, 2011 at 4:08 PM, Sun Chan wrote: >> >> S2 doms S5? >> Sun >> >> On Thu, Feb 10, 2011 at 7:55 AM, Min Zhao w

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Min Zhao
Yes. On Wed, Feb 9, 2011 at 4:08 PM, Sun Chan wrote: > S2 doms S5? > Sun > > On Thu, Feb 10, 2011 at 7:55 AM, Min Zhao wrote: > > > > Sorry, I should NOT use v0 as an example version. For better explanation, > > using the real verions in the code: > > > > S1: loc = 0; > > S2: buffer[limit] = 33

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Sun Chan
S2 doms S5? Sun On Thu, Feb 10, 2011 at 7:55 AM, Min Zhao wrote: > > Sorry, I should NOT use v0 as an example version. For better explanation, > using the real verions in the code: > > S1: loc = 0; > S2: buffer[limit] = 33; >    sym3v18 = chi (sym3v11) // buffer >    sym5v19 = chi

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Min Zhao
Sorry, I should NOT use v0 as an example version. For better explanation, using the real verions in the code: S1: loc = 0; S2: buffer[limit] = 33; sym3v18 = chi (sym3v11) // buffer sym5v19 = chi (sym5v13) // buffer scalar var -> NOT LIVE by DSE -> LIVE by ILOAD_FOLD S3: if (

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Sun Chan
i still don't understand why you think you can use v1, the more precise version, instead of zero version? This is more than just a versioning problem. It is a precision problem, isn't it? Sun On Thu, Feb 10, 2011 at 2:56 AM, Min Zhao wrote: > More explanations. > > Here is the failing test case:

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-09 Thread Min Zhao
More explanations. Here is the failing test case: S1: loc = 0; S2: buffer[limit] = 33; sym3v1 = chi (sym3v0) // buffer sym5v1 = chi (sym5v0) // buffer scalar var -> NOT LIVE by DSE -> LIVE by ILOAD_FOLD S3: if (buffer[loc] != 10) mu(sym3v1) // change

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-08 Thread Shin-Ming Liu
Sorry, I do see a reduced case in the bug report, created on 12/28/10. the variable 'buffer' is defined as: typedef unsigned char ASCIIcode; ASCIIcode buffer[(500) + 1]; the variable 'loc' is an integer, got initialized at line 15: loc = 0; on line 16 there is: buffer[limit] = 33; T

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-08 Thread Shin-Ming Liu
Feng, Is it possible to reduce the test case weave.i to a few number of lines to demonstrate the problem? Shin On Mon, Feb 7, 2011 at 11:23 AM, Feng Zhou wrote: > Sun, > > For bug #707, the symptom is compile-time assertion: > ### Assertion failure at line 921 of > > /wsp/fzhou/open64/dbg-objd

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-07 Thread Sun Chan
I guess I didn't make myself clear. Can you please explain your example in more detail? The original one, not traces. I don't fully understand your example. Sun On Tue, Feb 8, 2011 at 3:23 AM, Feng Zhou wrote: > Sun, > > For bug #707, the symptom is compile-time assertion: > ### Assertion failure

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-07 Thread Feng Zhou
Sun, For bug #707, the symptom is compile-time assertion: ### Assertion failure at line 921 of /wsp/fzhou/open64/dbg-objdir/osprey/../../open64/osprey/be/opt/opt_verify.cxx: ### Compiler Error in file test.c during Global Optimization -- Verify Live-Range phase: ### sym8v2(cr13) live range overlap

Re: [Open64-devel] Request for Code Review: bug #707

2011-02-03 Thread Sun Chan
sorry, can you state your problem clearer? What is before? What is after? In a running example? This problem is quite fundamental. Code in DSE and iload folding has not been touched for a very long time. I'd like to understand your problem better first. Sun On Fri, Feb 4, 2011 at 6:11 AM, Feng Zho

[Open64-devel] Request for Code Review: bug #707

2011-02-03 Thread Feng Zhou
Hello, Can gatekeeper review the attached fix for bug #707(https://bugs.open64.net/show_bug.cgi?id=707) please? Thank you. = In WOPT, after SSA pointer alias analysis, DSE is performed. So, you will have code