search for: dfastateentrytable

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 proble...

...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...

...M, 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....

...; 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 > <mailto:adasgupt at codeaurora.org>> &...

...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, >> >> T...

...ail 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> >&g...