Well, it should be replaced with &g_33[0]. On 26-07-13 17:44, Yang Chen wrote:
No, I think it's not a reduce-array-size bug. Some other pass running before reduce-array-size could simply replace an expression with 0 or 1. In this case, that pass could just turn"uint32_t *l_32 = &g_33[10];" into "uint32_t *l_32 = &g_33[1];" - Yang On 7/26/13 8:51 AM, Kees Bakker wrote:Could this be a bug with reduce-array-size? If I step through the clang_delta code I don't see it visit ReduceArraySizeCollectionVisitor::VisitArraySubscriptExpr And that may be the reason why the resulting dimension is alway 1. Just guessing. On 26-07-13 13:49, Kees Bakker wrote:Hi, Does anyone have suggestions how to avoid reduction that reads/writes outside an array. The reason I ask, after creduce is finished I get this code uint32_t g_33[1]; // <==== uint32_t g_202[4]; int8_t func_1 () { uint32_t *l_32 = &g_33[1]; // <=== uint32_t *l_972 = &g_202[0]; ++*l_32, *l_972 = g_708.f1; return 0; } This fails because the program writes outside the g_33 array. My own compiler tools have boundary checks, but this is a cross compiler and I'm using a simulator to run the result. It's doable but slow. So far, with clang, gcc, valgrind I couldn't find a method to detect array boundary violations. (( BTW I'm not sure if this is a creduce bug. ))
-- Kees
