You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That segfaults (dereferencing 0) on -O3 and exits normally on -O2. Trial elimination of optimization flags reveals that -O -fvect-cost-model(=(dynamic|unlimited)|) -ftree-loop-vectorize is sufficient to trigger the bad behavior. Adding fprintf(stderr, "%zu\n", i); to the loop at datastructures.c:30 (the h_carray_append array->used loop) also causes the code to exit normally.
This always fails at exactly 33 elements or greater (so at the capacity jump to 64), and completes successfully on 32 or fewer elements. It has nothing to do with the size of thingy.data, but seems to depend on act_thingy getting a TT_SEQUENCE.
The text was updated successfully, but these errors were encountered:
Experimentally, the attached gist doesn't fail at -O3, but does fail at -O2 -fvect-cost-model=unlimited -ftree-loop-vectorize. The parser the example is extracted from fails at -O3.
Minimalish example: https://gist.github.com/mrdomino/5f7de7b4aa9f74d13747
That segfaults (dereferencing 0) on -O3 and exits normally on -O2. Trial elimination of optimization flags reveals that
-O -fvect-cost-model(=(dynamic|unlimited)|) -ftree-loop-vectorize
is sufficient to trigger the bad behavior. Addingfprintf(stderr, "%zu\n", i);
to the loop at datastructures.c:30 (the h_carray_append array->used loop) also causes the code to exit normally.This always fails at exactly 33 elements or greater (so at the capacity jump to 64), and completes successfully on 32 or fewer elements. It has nothing to do with the size of thingy.data, but seems to depend on act_thingy getting a TT_SEQUENCE.
The text was updated successfully, but these errors were encountered: