Thanks for the clarification.
On 29-07-13 09:47, Yang Chen wrote:
Not all C-Reduce's passes know the C semantics, for example, the simple pass I
mentioned before. Here is my guess about what happened:
(1) the simple pass replaced "10" with "0", and we got tmp1.c;
(2) maybe the replacement made the bug-behavior disappear, so the tmp1.c was
discarded;
(3) the simple pass replaced "10" with "1", and we got tmp1.c where we had UB g_33[1]. Because there was no external UB-checker, and this UB could make the test script believe that the bug was
triggered by tmp1.c, then tmp1.c were saved as the current test case for the future reduction.
I agree that in most cases C-Reduce needs to avoid generating code like g_33[1] in this example, but it requires to replace existing perl transformations with corresponding Clang ones. Some are on
our TODO list.
- Yang
On 7/29/13 1:10 AM, Kees Bakker wrote:
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
