search

UpstandingHackers / hammer

Parser combinators for binary formats, in C. Yes, in C. What? Don't look at me like that.
GNU General Public License v2.0
431 stars 40 forks source link

Probable gcc bug with symptom in h_carray_append #121

Open mrdomino opened 9 years ago

mrdomino commented 9 years ago

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. 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.

mrdomino commented 9 years ago

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.

mrdomino commented 9 years ago

This is on Arch x64.

$ uname -a
Linux wooten 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014 x86_64 GNU/Linux
$ gcc --version |head -n1
gcc (GCC) 4.9.2 20141224 (prerelease)
mrdomino commented 9 years ago

And just to clarify, these are hammer compilation flags. The gist doesn't need any special flags at all.