[LLVMdev] Possible bug in DFAPacketizer::ReadTable

[Carlos Sánchez de La Lama]

Hi Anshu,

no, I did not fill a bug report. It is not so easy to make the code fail
noticeably; during Hexagon CodeGen tests it happens silently and tests
pass. I am working on another VLIW backend which uses DFAPacketizer and
compiling llvm with gcc-4.4 makes it segfault, but with gcc-4.7 the bug
gets hidden again (it still happens, but values after DFAStateEntryTable in
memory are such that ReadTable does not break bad).

If you find more info will help you track it down just let me know :)

BR

Carlos


2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org>

>  Hi Carlos,
>
> Thanks for identifying the bug. I'll confirm and fix. Is there a bug
> report open for this?
>
> -Anshu
>
> ---
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
>
>
> On 12/10/2012 4:48 AM, Carlos Sánchez de La Lama wrote:
>
> Hi all,
>
> I have found what I think it is a bug in DFAPacketizer::ReadTable.
>
> When finding NextStateInTable to cache all transitions belonging to a
> state into CachedTable, ReadTable does not check bounds:
>
>  unsigned ThisState =
> DFAStateEntryTable[state];
> |
> unsigned NextStateInTable = DFAStateEntryTable[state+1];
>
> which makes NextStateInTable get a random value when state == <last state
> in table>. Behaviour changes depending on gcc version / platform / ..., but
> in some cases might lead to segmentation faults.
>
> I have checked the problem happens in Hexagon tests (for example fadd.ll
> test) but does not break badly there (though CachedTable will get some
> unneded and random data rows).
>
> Probably making tblgen add an end-of-table marker in
> <Target>DFAStateEntryTable is the easiest solution.
>
> BR
>
> Carlos
>
>
>  _______________________________________________
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121210/4b8f0f49/attachment.html>