[LLVMdev] Possible bug in DFAPacketizer::ReadTable
adasgupt at codeaurora.org
Mon Dec 10 14:50:00 PST 2012
I committed a fix in r169783. Thanks for catching this.
However, I could not reproduce an invalid read or a segfault even with
fadd.ll. Is there a test case you can check in that reproduces this bug?
Even if the segfault occurs intermittently, that's better than no test
case at all.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
On 12/10/2012 1:01 PM, Carlos Sánchez de La Lama wrote:
> 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 :)
> 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org
> <mailto:adasgupt at codeaurora.org>>
> Hi Carlos,
> Thanks for identifying the bug. I'll confirm and fix.Is there a
> bug report open for this?
> 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
>> 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.
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev