Hello,
Csmith r2124 recently generated the attached program.
What is notable about it is the rather large local l_666, of
size (90 * 1908) 171720 bytes.
This is quite a large array to put in the stack.
The array is const. This may save it from being allocated
in the stack, but it does not have to.
It is local to a block that doesn't appear to be reachable.
If the block is unreachable on purpose, and if such a large
array would never be generated for a reachable block,
please ignore this remark.
Otherwise, while this unusual-sized array may reveal issues
in compilers, it may also cause unrelated valid issues to
be dismissed. Stack allocation of large arrays, either
variable-length or not, gets a bad rap because it may
silently fail, even on platforms with MMUs (a single 4KiB page
may be used to detect stack overflows. An uninitialized
local array larger than that may jump over the sentinel
page without noticing it), and as opposed to
malloc which indicates when allocation fails.
A C compiler developer might look at a bug report containing
such an array and mistake it for the root of the issue.
So as to avoid this, perhaps there should be an option for limiting
the size of local variables?
This said, the attached program revealed a performance issue
in Frama-C that is now fixed, so we're thankful to have had it
generated once. We are fine with this kind of program.
This is not a feature wish, just a remark.
Pascal