This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: out of bounds access in insn-automata.c


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]