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
The test code in the issue #181 makes me think of this issue, and I add the following printf() calls to execute the code and observe the potential bug:
$ gcc -o test test.c
$ ./test
D
D
D
D
raw = 28863040
data->raw = 28863040
&raw[0] = 28863040
&data->raw[0] = 28863040
data = 5f8d62a0
&data[0] = 5f8d62a0
shecc
$ qemu-arm out/shecc-stage2.elf -o test test.c
$ qemu-arm test
D
D
�
D
raw = 407ffdcc
data->raw = 407ffdcc
&raw[0] = 407ffdcc
&data->raw[0] = 4080400c
data = 4080400c
&data[0] = 4080400c
It is obvious that &data->raw[0] equals &data[0].
After observing the code snippets in this comment and the comment in the issue #181, I think the potential bug is that using arrow operator and subscripting operator (-> and [ ]) simultaneously may obtain an incorrect object.
In this comment, &data->raw[0] is equivalent to &data[0].
For my comment in the issue (#181) , the statement cur = map->buckets[0] in the for loop equals cur = map->buckets.
After using git bisect to find which commit starts causing this issue (thanks visitorckw for suggesting this strategy), it appears that this bug have already persisted throughout whole commit history (some of old commits are not reproducible due to ICE).
Considering the following code:
Using gcc to compile the program and run it, it would output:
But using shecc, it would output:
This happens because of the incorrect deference assembly code.
The text was updated successfully, but these errors were encountered: