1. 29 Jun, 2015 1 commit
  2. 22 Jun, 2015 1 commit
  3. 06 Jun, 2015 2 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.80 · 14a86b32
      Greg Kroah-Hartman authored
      14a86b32
    • Kirill A. Shutemov's avatar
      kernel: use the gnu89 standard explicitly · c7c86748
      Kirill A. Shutemov authored
      commit 51b97e354ba9fce1890cf38ecc754aa49677fc89 upstream.
      
      Sasha Levin reports:
       "gcc5 changes the default standard to c11, which makes kernel build
        unhappy
      
        Explicitly define the kernel standard to be gnu89 which should keep
        everything working exactly like it was before gcc5"
      
      There are multiple small issues with the new default, but the biggest
      issue seems to be that the old - and very useful - GNU extension to
      allow a cast in front of an initializer has gone away.
      
      Patch updated by Kirill:
       "I'm pretty sure all gcc versions you can build kernel with supports
        -std=gnu89.  cc-option is redunrant.
      
        We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me"
      
      Note by Andrew Pinski:
       "Yes it was reported and both problems relating to this extension has
        been added to gnu99 and gnu11.  Though there are other issues with the
        kernel dealing with extern inline have different semantics between
        gnu89 and gnu99/11"
      
      End result: we may be able to move up to a newer stdc model eventually,
      but right now the newer models have some annoying deficiencies, so the
      traditional "gnu89" model ends up being the preferred one.
      Signed-off-by: 's avatarSasha Levin <sasha.levin@oracle.com>
      Singed-off-by: 's avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c7c86748
  4. 17 May, 2015 1 commit
  5. 15 May, 2015 1 commit
  6. 13 May, 2015 1 commit
  7. 06 May, 2015 1 commit
  8. 29 Apr, 2015 1 commit
  9. 19 Apr, 2015 1 commit
  10. 13 Apr, 2015 1 commit
  11. 26 Mar, 2015 1 commit
  12. 18 Mar, 2015 1 commit
  13. 06 Mar, 2015 1 commit
  14. 27 Feb, 2015 1 commit
  15. 11 Feb, 2015 1 commit
  16. 06 Feb, 2015 1 commit
  17. 30 Jan, 2015 1 commit
  18. 27 Jan, 2015 1 commit
  19. 16 Jan, 2015 1 commit
  20. 08 Jan, 2015 1 commit
  21. 16 Dec, 2014 1 commit
  22. 06 Dec, 2014 1 commit
  23. 21 Nov, 2014 1 commit
  24. 14 Nov, 2014 1 commit
  25. 30 Oct, 2014 1 commit
  26. 15 Oct, 2014 1 commit
  27. 09 Oct, 2014 1 commit
  28. 05 Oct, 2014 1 commit
  29. 17 Sep, 2014 1 commit
  30. 05 Sep, 2014 1 commit
  31. 14 Aug, 2014 1 commit
  32. 07 Aug, 2014 1 commit
  33. 31 Jul, 2014 2 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.51 · 10a62249
      Greg Kroah-Hartman authored
      10a62249
    • Linus Torvalds's avatar
      Fix gcc-4.9.0 miscompilation of load_balance() in scheduler · e1d8240b
      Linus Torvalds authored
      commit 2062afb4f804afef61cbe62a30cac9a46e58e067 upstream.
      
      Michel Dänzer and a couple of other people reported inexplicable random
      oopses in the scheduler, and the cause turns out to be gcc mis-compiling
      the load_balance() function when debugging is enabled.  The gcc bug
      apparently goes back to gcc-4.5, but slight optimization changes means
      that it now showed up as a problem in 4.9.0 and 4.9.1.
      
      The instruction scheduling problem causes gcc to schedule a spill
      operation to before the stack frame has been created, which in turn can
      corrupt the spilled value if an interrupt comes in.  There may be other
      effects of this bug too, but that's the code generation problem seen in
      Michel's case.
      
      This is fixed in current gcc HEAD, but the workaround as suggested by
      Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
      when compiling the kernel, which disables the gcc code that causes the
      problem.  This can result in slightly worse debug information for
      variable accesses, but that is infinitely preferable to actual code
      generation problems.
      
      Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
      non-debug builds to verify that the debug build would be identical: we
      can do
      
          export GCC_COMPARE_DEBUG=1
      
      to make gcc internally verify that the result of the build is
      independent of the "-g" flag (it will make the compiler build everything
      twice, toggling the debug flag, and compare the results).
      
      Without the "-fno-var-tracking-assignments" option, the build would fail
      (even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
      compare failure.
      
      See also gcc bugzilla:
      
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801Reported-by: 's avatarMichel Dänzer <michel@daenzer.net>
      Suggested-by: 's avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1d8240b
  34. 28 Jul, 2014 1 commit
  35. 17 Jul, 2014 1 commit
  36. 09 Jul, 2014 1 commit
  37. 07 Jul, 2014 1 commit
  38. 01 Jul, 2014 1 commit