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 w
are trying
> to test. Try use Sparse 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
Subject: [PATCH] ./Makefile: tell gcc optimi
ad.
How reliable is this format across GCC versions? GCC manpage doesn't seem
to list it as a valid alternative.
--
Jiri Kosina
SUSE Labs
dify "log_first_seq" in parallel.
===
I believe that the best course of action is both
- building kernel (and anything multi-threaded, I guess) with that
optimization turned off
- persuade gcc folks to change the default for future releases
Thanks,
--
Jiri Kosina
SUSE Labs
tween respective run-times.
Hopefully the default will be changed in newer gccs, but let's force
it for kernel builds so that we are on a safe side even when older
gcc are used.
Cc: Martin Jambor
Cc: Petr Mladek
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Andrew M
st8 [r32]=r14
0x45e1 <+33>: nop.i 0x0
0x45e2 <+34>:br.ret.sptk.many b0;;
In my opinion, this is a clear bug in gcc (while the original problem,
without explitict volatile, is not a C spec violation per se, it's just
very inconvenient :) ).
--
Jiri Kosina
SUSE Labs
