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 cor

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

2014-06-17 Thread Jiri Kosina
On Mon, 16 Jun 2014, Dan Carpenter 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. > > It thinks allow-store-data-races=0 is the name of the file we are trying > to test. Try use Spa

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

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

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

2014-06-16 Thread Andreas Schwab
Dan Carpenter 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, sch...@suse.de GPG Key f

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 mm/sl

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 wrote: >On Tue, Jun 10, 2014 at 10:46 AM, Linus Torvalds > wrote: >> On Tue, Jun 10, 2014 at 6:23 AM, 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 turne

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)

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 wrote: > On Tue, Jun 10, 2014 at 6:23 AM, 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 br

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

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 replac

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+=

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

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 als

[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 that