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