Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-08-20 Thread Jiri Kosina
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-17 Thread Jiri Kosina
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-16 Thread Dan Carpenter
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-16 Thread Andreas Schwab
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,

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-16 Thread Jiri Kosina
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-16 Thread Mark Brown
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

[PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Jiri Kosina
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Peter Zijlstra
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Marek Polacek
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Peter Zijlstra
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Jakub Jelinek
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Linus Torvalds
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Steven Noonan
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Jiri Kosina
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

Re: [PATCH] tell gcc optimizer to never introduce new data races

2014-06-10 Thread Richard Biener
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