On 2014.07.28 at 10:27 -0700, Alexei Starovoitov wrote:
On Mon, Jul 28, 2014 at 09:45:45AM -0700, Linus Torvalds wrote:
On Mon, Jul 28, 2014 at 5:26 AM, Frank Ch. Eigler f...@redhat.com wrote:
Please note that the data produced by -g -fvar-tracking is consumed
by tools like systemtap,
On 2014.07.28 at 11:28 -0700, Linus Torvalds wrote:
On Mon, Jul 28, 2014 at 11:09 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
It shouldn't be too hard to implement a simple check for the bug in the
next release. Just compile the gcc/testsuite/gcc.target/i386/pr61801.c
testcase
On 2014.07.26 at 11:39 -0700, Linus Torvalds wrote:
On Sat, Jul 26, 2014 at 11:28 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
That's a bit worrisome. I haven't actually checked if the code
generation differs in significant ways yet..
Nope. Just three instructions that got
On 2014.07.26 at 15:55 -0400, Theodore Ts'o wrote:
On Sat, Jul 26, 2014 at 09:35:57PM +0200, Markus Trippelsdorf wrote:
But fortunately the workaround for the new inode.c bug is the same as
for the original bug: -fno-var-tracking-assignments.
It would make sense to enabled
On 2014.07.26 at 12:56 -0700, Linus Torvalds wrote:
On Sat, Jul 26, 2014 at 12:35 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
But fortunately the workaround for the new inode.c bug is the same as
for the original bug: -fno-var-tracking-assignments.
It would make sense
5 matches
Mail list logo