Re: Odd problem with shared array

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Wed Jan 28 2009 - 17:17:12 PST

  • Next message: Steven Vormwald: "Re: Odd problem with shared array"
    Sorry for the incorrect implication in my email.
    I wanted to convey that no compiler person was likely to respond to the 
    email that SAME DAY (my intent when I said "actively working").
    I see now that my wording conveyed something different.
    
    That said, *I* am looking at the bug right now and will be adding more 
    info to the bug report soon.
    
    -Paul
    
    Kathy Yelick wrote:
    > Just a correction --  Costin Iancu is still working on compiler bug 
    > fixes, and we are also adding a new compiler person to the team later 
    > this spring.  The rest of Paul's mail was correct-- please go ahead 
    > with the bug report.
    >
    >    Kathy
    >
    > ------------------------------------------------
    > Katherine Yelick
    > Lawrence Berkeley National Laboratory
    > One Cyclotron Rd., MS 50B-4230
    > Berkeley, CA  94720
    > Email: kayelick_at_lbl_dot_gov
    > Phone: 510-495-2431
    >
    > On Jan 26, 2009, at 11:18 PM, Paul H. Hargrove wrote:
    >
    >> Steven,
    >>
    >> Thanks for the bug report.  I am pretty sure you have found a bug in 
    >> our UPC compiler.  However, there is nobody actively working on 
    >> compiler bugs right now.  So, if you could please go to 
    >> http://upc-bugs.lbl.gov/bugzilla/ and enter your information in a bug 
    >> report, that will ensure we don't loose track of it.  The initial bug 
    >> entry page does not allow attachments, but once the initial report 
    >> has been entered, you will have the option to attach files.
    >>
    >> Thanks,
    >> -Paul
    >>
    >> Steven Vormwald wrote:
    >>> Hello,
    >>>
    >>> I've come across an odd problem that seems to only come up with 
    >>> structs with 2-dimensional arrays of size 1x1.  The attached code 
    >>> provides an example of this.  When run with N=1 (and 4 threads), the 
    >>> output is unexpectedly:
    >>>       0       1
    >>> 0       0       1
    >>> 1       2       3
    >>>
    >>>       0       1
    >>> 0       0       1
    >>> 1       2       3
    >>>
    >>>       0       1
    >>> 0       0       704643072
    >>> 1       2752512 10752
    >>>
    >>> instead of
    >>>
    >>>       0       1
    >>> 0       0       1
    >>> 1       2       3
    >>>
    >>>       0       1
    >>> 0       0       1
    >>> 1       2       3
    >>>
    >>>       0       1
    >>> 0       2       3
    >>> 1       6       11
    >>>
    >>> Using any value of N other than 1 generates the correct output for 
    >>> the number of threads.  Even more odd is when I enabled the 
    >>> debugging output from the code:
    >>>       0       1
    >>> 0       0       1
    >>> 1       2       3
    >>>
    >>>       0       1
    >>> 0       0       1
    >>> 1       2       3
    >>>
    >>> C[00].local_block[00][00] = 0 + 0 * 0
    >>>                         = 0 + 0
    >>>                         = 0
    >>> C[00].local_block[00][00] = 0 + 1 * 2
    >>>                         = 0 + 0
    >>>                         = 0
    >>> C[01].local_block[00][00] = 0 + 0 * 1
    >>>                         = 0 + 0
    >>>                         = 704643072
    >>> C[01].local_block[00][00] = 704643072 + 1 * 3
    >>>                         = 704643072 + 0
    >>>                         = 704643072
    >>> C[02].local_block[00][00] = 0 + 2 * 0
    >>>                         = 0 + 0
    >>>                         = 2752512
    >>> C[02].local_block[00][00] = 2752512 + 3 * 2
    >>>                         = 2752512 + 0
    >>>                         = 2752512
    >>> C[03].local_block[00][00] = 0 + 2 * 1
    >>>                         = 0 + 0
    >>>                         = 10752
    >>> C[03].local_block[00][00] = 10752 + 3 * 3
    >>>                         = 10752 + 0
    >>>                         = 10752
    >>>
    >>>       0       1
    >>> 0       0       704643072
    >>> 1       2752512 10752
    >>>
    >>> Note that the values of A[] and B[] are printed correctly on the 
    >>> first line, but the results of the multiplication and store in C[] 
    >>> are incorrect.
    >>>
    >>> Changing the code to use floats or doubles instead of ints generates 
    >>> similar problems.  However, if the arrays are allocated dynamically 
    >>> with upc_all_alloc(), the program works correctly.  I tested the 
    >>> code on versions 2.4 (mpi), 2.6 (smp,ibv), and 2.8 (smp,ibv) of the 
    >>> Berkeley UPC compiler, all of which produce the same problem.  I 
    >>> haven't been able to test it on another machine, so it might be a 
    >>> configuration issue, or a problem with the local C compiler (gcc 
    >>> (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)).
    >>>
    >>> Attached is the source code that was used, the output of 'upcc 
    >>> -version' for each of the versions of the compiler used, as well as 
    >>> the output run on 4 threads with N=1,2.  I fixed the order of the 
    >>> output lines so they lined up properly, but otherwise did not change 
    >>> the output.
    >>>
    >>> Steven Vormwald
    >>
    >>
    >> -- 
    >> Paul H. Hargrove                          PHHargrove_at_lbl_dot_gov
    >> Future Technologies Group                 Tel: +1-510-495-2352
    >> HPC Research Department                   Fax: +1-510-486-6900
    >> Lawrence Berkeley National Laboratory
    >
    
    
    -- 
    Paul H. Hargrove                          PHHargrove_at_lbl_dot_gov
    Future Technologies Group                 Tel: +1-510-495-2352
    HPC Research Department                   Fax: +1-510-486-6900
    Lawrence Berkeley National Laboratory     
    

  • Next message: Steven Vormwald: "Re: Odd problem with shared array"