On Sat, Aug 22, 2020 at 02:43:08AM +0200, Thomas Gleixner wrote: > On Fri, Aug 21 2020 at 16:16, Nick Desaulniers wrote: > > On Fri, Aug 21, 2020 at 4:04 PM Arvind Sankar <nived...@alum.mit.edu> wrote: > >> On Fri, Aug 21, 2020 at 02:37:48AM +0200, Thomas Gleixner wrote: > >> The gcc bug I linked to earlier is only fixed in gcc-6 onwards. Is that > > > > (based on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602#c14) > > > >> good enough to remove force_order? I can test gcc-4.9 and gcc-5 to check > >> if it would currently have any impact. > > And that test tells you what exactly? That your particular build of > those compilers does not have the problem. A truly scientific approach.
More that the current kernel code doesn't have that problem, but yeah, it might creep in later. > > > I think checking the disassemblies with a pre-gcc-6 would be good > > enough then; that bug isn't specific to this particular case. > > What? I clearly want a statement from the GCC people that this won't > happen on pre gcc6 compilers and not just some 'works for me' statement > based on a randomly picked compiler build. Presumably also from clang that the compiler does have protections against this, as opposed to doesn't happen today. > > Thanks, > > tglx Cc Segher. Segher, we were looking at gcc PR82602, where IRA could reorder volatile asm's (reported on ARM). The fix was backported to gcc-6. Do you know if there is any reason the problem couldn't occur on x86 on older gcc without the fix? Thanks. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602