On Tue, 10 Jun 2014, Jiri Kosina wrote:
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load into
a non-conditional one, and that broke correctness (the condition was met
only if lock was held) and
on linux-next to see the problem.
Alright, no word from gcc folks, so let's hope the undocumented format of
the parameter works better ... sigh.
Andrew, please use the updated one below.
From: Jiri Kosina jkos...@suse.cz
Subject: [PATCH] ./Makefile: tell gcc optimizer to never introduce new data
Adding --param allow-store-data-races=0 to the GCC options for the
kernel breaks C=1 because Sparse isn't expecting a GCC option with that
format.
It thinks allow-store-data-races=0 is the name of the file we are trying
to test. Try use Sparse on linux-next to see the problem.
$ make C=2
Dan Carpenter dan.carpen...@oracle.com writes:
Adding --param allow-store-data-races=0 to the GCC options for the
kernel breaks C=1 because Sparse isn't expecting a GCC option with that
format.
Please try --param=allow-store-data-races=0 instead.
Andreas.
--
Andreas Schwab, SUSE Labs,
On Mon, 16 Jun 2014, Andreas Schwab wrote:
Adding --param allow-store-data-races=0 to the GCC options for the
kernel breaks C=1 because Sparse isn't expecting a GCC option with that
format.
Please try --param=allow-store-data-races=0 instead.
How reliable is this format across GCC
On Mon, Jun 16, 2014 at 12:52:10PM +0200, Andreas Schwab wrote:
Dan Carpenter dan.carpen...@oracle.com writes:
Adding --param allow-store-data-races=0 to the GCC options for the
kernel breaks C=1 because Sparse isn't expecting a GCC option with that
format.
Please try
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load into
a non-conditional one, and that broke correctness (the condition was met
only if lock was held) and corrupted memory.
This particular problem with
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
+# Tell gcc to never replace conditional load with a non-conditional one
+KBUILD_CFLAGS+= $(call cc-option,--param allow-store-data-races=0)
+
Why do we not want: -fmemory-model=safe? And should we not at the very
least also
On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
+# Tell gcc to never replace conditional load with a non-conditional one
+KBUILD_CFLAGS += $(call cc-option,--param allow-store-data-races=0)
+
Why do we not
On Tue, Jun 10, 2014 at 05:04:55PM +0200, Marek Polacek wrote:
On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
+# Tell gcc to never replace conditional load with a non-conditional one
+KBUILD_CFLAGS+= $(call
On Tue, Jun 10, 2014 at 05:13:29PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 05:04:55PM +0200, Marek Polacek wrote:
On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
+# Tell gcc to never replace
On Tue, Jun 10, 2014 at 6:23 AM, Jiri Kosina jkos...@suse.cz wrote:
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load into
a non-conditional one, and that broke correctness (the condition was met
only if
On Tue, Jun 10, 2014 at 10:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Jun 10, 2014 at 6:23 AM, Jiri Kosina jkos...@suse.cz wrote:
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load
On Tue, 10 Jun 2014, Linus Torvalds wrote:
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load into
a non-conditional one, and that broke correctness (the condition was met
only if lock was held) and
On June 10, 2014 8:04:13 PM CEST, Steven Noonan ste...@uplinklabs.net wrote:
On Tue, Jun 10, 2014 at 10:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Jun 10, 2014 at 6:23 AM, Jiri Kosina jkos...@suse.cz wrote:
We have been chasing a memory corruption bug, which turned out to
15 matches
Mail list logo