out of bounds access in insn-automata.c
Vladimir Makarov
vmakarov@redhat.com
Wed Mar 23 16:34:00 GMT 2016
On 03/23/2016 02:32 AM, Aldy Hernandez wrote:
> Howdy!
>
> I'm working on enhancements to our out-of-bounds warnings in VRP, such
> that we can warn and isolate conditionally out-of-bound accesses
> (similar to what we do in gimple-ssa-isolate-paths.c for NULL accesses).
>
> With my WIP I have found the following out of bounds in the array
> access at the end of maximal_insn_latency:
>
> int
> maximal_insn_latency (rtx insn)
> {
> int insn_code;
>
> if (insn == 0)
> insn_code = DFA__ADVANCE_CYCLE;
>
>
> else
> {
> insn_code = dfa_insn_code (as_a <rtx_insn *> (insn));
> if (insn_code > DFA__ADVANCE_CYCLE)
> return 0;
> }
> return internal_maximal_insn_latency (insn_code, insn);
> }
>
> In the case where insn==0, insn_code is set to the size of
> default_latencies[] which will get accessed in the return.
>
> Does insn==0 never happen? Are we reading past the end of
> default_latencies[]? What am I missing?
>
> Perhaps we can do:
>
> if (insn == 0) {
> gcc_unreachable();
> return 1;
> }
>
> Or is insn==0? In which case, what should we return?
Sorry, Aldy. The code is > 15 years old. When I wrote the code, I
thought about a lot of extensions (like reversed automata, automata for
cycled reservations etc). So honestly, I don't remember why I wrote it.
So I'd recommend what Bernd proposed -- add the assert as `insn==0`
should never happen for the current code.
More information about the Gcc
mailing list