Out-of-bound access in the CUDA/SumReductionRevealed example

[cihe13375]

when running the CUDA/SumReductionRevealed example I got output like this:

 ====== ITREE_LEVEL 1 offset 64 ntX is 128 MIN_REDUCE_SYNC_SIZE 32 ====
 64  66  68  70  72  74  76  78  80  82  84  86  88  90  92  94  96  98 100 102 104 106 108 110 112 114 116 118 120 122 124 126 128 130 132 134 136 138 140 142 144 146 148 150 152 154 156 158 160 162 164 166 168 170 172 174 176 178 180 182 184 186 188 190    
320 322 324 326 328 330 332 334 136 137 1179 139 1027416214 1027423690 1381255598 1281312212 1279612629 1864380849 1702061816 875962631 1484025524 544434613 540553927 1598966244 1430537706 1398752732 1598246643 1163545070 540160956 1027423706 540553640 540619199 540029632 540095169 540160706 540226243 540291780 540357317 540422854 540488391 540553928 540619465 540029898 540095435 540160972 540226509 540292046 540357583 540423120 540488657 540554194 540619731 540030164 540095701 540161238 540226775 540292312 540357849 540423386 540488923 540554460 540619997 540030430 540095967    
Sum is 1482423102. Data count is reduced to 128
Sync threads when larger than warp

where the numbers in the second half go wild.
I think the problem is around line 40:

if (tiX < offset){
    array[giX]+=array[giX+offset];

when looping through the second grid, giX goes from 128 to 191, so giX+offset (offset=64 in the first round) goes beyond the size of array (200), leading to arbitrary numbers entering the summation. The real cuda example works because the array is first copied to spad with a boundary check, and spad was filled with 0 before copying.

A possible fix would be changing the if condition to e.g. if (tiX < offset && (giX+offset) < isize).