summarylogtreecommitdiffstats
path: root/fix-insn-delay_cycles_32x.patch
AgeCommit message (Collapse)Author
2017-07-26Updated to latest version.vonPalitroque
Updated to latest upstream version. Small caveat: The bug described in pr79242 is still not resolved and activity on it seems to be of low interest. Unfortunately, I do not have the time to look into it that much. As such, instead of delaying the update until the bug is resolved, I have opted to instead revert the change that exposed the bug [2]. Yes, this means that the bug is still there and may be triggered a different way, I have yet to find a scenario where it happens though. I will ask then the community: if such case is found, please let me know and/or add it to [1]. I will then prepare and release a PKGBUILD based on gcc 6.4 instead. Cheers, Orlando. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
2016-09-12Fixed bug in delay_cycles_32x insn.vonPalitroque
There is a bug in the insn that generates the delay loop for the instrinsic __delay_cycles() function. This bug is noticeable under some circumstances, where the target is an MSP430X core and the cycle count is representable as a 32 bit number. This bug results in the corruption of r14 in a function that utilizes the instrinsic under the above conditions. A bug report has been filed at [1] with a patch submitted. The same patch is applied here. Although it is improbable that this instrinsic is used in newlib, it is suggested to recompile it just in case. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77570