block: fix some fiops derps
Makefile: add some optimization flags for ARM

Signed-off-by: faux123 <reioux@gmail.com>

Conflicts:

	Makefile
Makefile: update to work with GCC 4.7 toolchain

Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: unalgined access: disable ARM unaligned access

Samsung's surfaceflinger is causing unexpected alignment trap
exceptions.  This shouldn't happen but it did :(

Disable for now pending further investigations

Signed-off-by: Paul Reioux <reioux@gmail.com>
add support for gcc 4.8
Update build flags
Revert "ARM: unalgined access: disable ARM unaligned access"

This reverts commit b4ccc1f431a353ffa03caa035e28f14b34b2f211.
Update compiler flags
Build optimizations
Fix build with sm-toolchain 4.8.x in the Makefile
-Use CC instead of REAL_CC
-Remove the wrapper, archheaders and archscripts
-Add missing-syscalls

Signed-off-by: Paul Beeler <sparksco@gmail.com>
Build flags tune-up
Makefiles: compiler option overhaul

 - Use default compiler option for HOSTCFLAGS & HOSTCXXFLAGS

   Programs that uses HOSTCFLAGS and HOSTCXXFLAGS are used to generate zImage.
   Those do not provides any speed improvements to the zImage itself,
   and can actually result in zImage corruption by using cutting-edge flags.

 - Remove "-w" flag

   The Linux kernel absolutely NEEDS "-Werror-implicit-function-declaration" flag
   for invalid function checkings.
   Assume 'main.c' is calling non-existing 'testing()'.
   "-Werror-implicit-function-declaration" will stop the compilation and forces you
   to make your kernel call the existing, "SANE" function.
   To make "-Werror-implicit-function-declaration" flag working properly, remove "-w" flag.

 - Remove "-Wno-sizeof-pointer-memaccess" flag

   The new GCC 4.8 guidelines recommends us to fix those "sizeof-pointer-memaccess" warnings
   for cleaner code generation.
   Reference : https://gcc.gnu.org/gcc-4.8/porting_to.html

 - Disable neon and enable hard-float code generation.

   Neon gives the generated code a speed bump, only noticeable for A/V(Audio / Video) calculations.
   On the other hand, hard-float(armhf) uses hardware for floating point calculation.
   Using hard-float can bump up speed upto 200%.
   So use hard-float instead of neon (both are incompatible anyways).
   This usually needs a hard-float toolchain, but since the Linux kernel is not being linked
   against any of the prebuilt toolchain's libraries, we can safely build codes
   with hard-float with soft-float toolchains.
   Reference : https://wiki.linaro.org/Linaro-arm-hardfloat

 - Use "-s" flag

   This forces GCC to generate pre-stripped codes for removing the necessity of stripping
   the binaries later.

 - Remove cutting-edge flags

   Cutting-edge flags are mostly giving less-to-none improvements and rather results in
   code corruption, alignment errors and kernel panics.
   So, remove the followings :
   -fgcse-after-reload -fgcse-sm -fgcse-las -ftree-loop-im -ftree-loop-ivcanon -fivopts

 - Add more optimization flags

   -Ofast : equivalent to -O3 -ffast-math
   -fno-tree-vectorize : recommended by Debian(https://wiki.debian.org/ArmHardFloatPort/VfpComparison)
   -fmodulo-sched -fmodulo-sched-allow-regmoves : recommended by Linaro(http://www.linaro.org/blog/android-blog/compiler-flags-used-to-speed-up-linaro-android-2011-10-and-future-optimizations)
   -funroll-loops : increases the binary size, but gives a speed bump(https://wiki.linaro.org/MichaelHope/Sandbox/CoreMark1)

 - Add "-Wno-unused" flag

   Unused variables, functions are already being stripped by GCC automatically.
   Those warnings are not necessary at all.

Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Revert "Makefiles: compiler option overhaul"

This reverts commit ae8985dd05e999a46795cc1ecaf4152736293ab8.
Disable -fconserve-stack on ARM v2

There are reports that -fconserve-stack misaligns variables on the stack.
Disable it for ARM to work around this gcc bug.

v2: Move top level flags definition up
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Revert "Disable -fconserve-stack on ARM v2"

This reverts commit 8babbc159bda6fc6ffa0b891c21aae3e1bd058bd.
Makefiles: compiler option overhaul

 - Use default compiler option for HOSTCFLAGS & HOSTCXXFLAGS

   Programs that uses HOSTCFLAGS and HOSTCXXFLAGS are used to generate zImage.
   Those do not provides any speed improvements to the zImage itself,
   and can actually result in zImage corruption by using cutting-edge flags.

 - Remove "-w" flag

   The Linux kernel absolutely NEEDS "-Werror-implicit-function-declaration" flag
   for invalid function checkings.
   Assume 'main.c' is calling non-existing 'testing()'.
   "-Werror-implicit-function-declaration" will stop the compilation and forces you
   to make your kernel call the existing, "SANE" function.
   To make "-Werror-implicit-function-declaration" flag working properly, remove "-w" flag.

 - Remove "-Wno-sizeof-pointer-memaccess" flag

   The new GCC 4.8 guidelines recommends us to fix those "sizeof-pointer-memaccess" warnings
   for cleaner code generation.
   Reference : https://gcc.gnu.org/gcc-4.8/porting_to.html

 - Disable neon and enable hard-float code generation.

   Neon gives the generated code a speed bump, only noticeable for A/V(Audio / Video) calculations.
   On the other hand, hard-float(armhf) uses hardware for floating point calculation.
   Using hard-float can bump up speed upto 200%.
   So use hard-float instead of neon (both are incompatible anyways).
   This usually needs a hard-float toolchain, but since the Linux kernel is not being linked
   against any of the prebuilt toolchain's libraries, we can safely build codes
   with hard-float with soft-float toolchains.
   Reference : https://wiki.linaro.org/Linaro-arm-hardfloat

 - Use "-s" flag

   This forces GCC to generate pre-stripped codes for removing the necessity of stripping
   the binaries later.

 - Remove cutting-edge flags

   Cutting-edge flags are mostly giving less-to-none improvements and rather results in
   code corruption, alignment errors and kernel panics.
   So, remove the followings :
   -fgcse-after-reload -fgcse-sm -fgcse-las -ftree-loop-im -ftree-loop-ivcanon -fivopts

 - Add more optimization flags

   -Ofast : equivalent to -O3 -ffast-math
   -fno-tree-vectorize : recommended by Debian(https://wiki.debian.org/ArmHardFloatPort/VfpComparison)
   -fmodulo-sched -fmodulo-sched-allow-regmoves : recommended by Linaro(http://www.linaro.org/blog/android-blog/compiler-flags-used-to-speed-up-linaro-android-2011-10-and-future-optimizations)
   -funroll-loops : increases the binary size, but gives a speed bump(https://wiki.linaro.org/MichaelHope/Sandbox/CoreMark1)

 - Add "-Wno-unused" flag

   Unused variables, functions are already being stripped by GCC automatically.
   Those warnings are not necessary at all.

Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
hlte: add flag -Wno-sizeof-pointer-memaccess for now

Change-Id: Ia88c75c2fa30a864c5dc8ceb36effc992a6cd809

Conflicts:
	Makefile
kernel: use the gnu89 standard explicitly

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: Sasha Levin <sasha.levin@oracle.com>
Singed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:
	Makefile

Conflicts:
	Makefile
./Makefile: tell gcc optimizer to never introduce new data races

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 particular code did not happen when
never gccs were used.  I've brought this up with our gcc folks, as I
wanted to make sure that this can't really happen again, and it turns
out it actually can.

Quoting Martin Jambor <mjambor@suse.cz>:
 "More current GCCs are more careful when it comes to replacing a
  conditional load with a non-conditional one, most notably they check
  that a store happens in each iteration of _a_ loop but they assume
  loops are executed.  They also perform a simple check whether the
  store cannot trap which currently passes only for non-const
  variables.  A simple testcase demonstrating it on an x86_64 is for
  example the following:

  $ cat cond_store.c

  int g_1 = 1;

  int g_2[1024] __attribute__((section ("safe_section"), aligned (4096)));

  int c = 4;

  int __attribute__ ((noinline))
  foo (void)
  {
    int l;
    for (l = 0; (l != 4); l++) {
      if (g_1)
        return l;
      for (g_2[0] = 0; (g_2[0] >= 26); ++g_2[0])
        ;
    }
    return 2;
  }

  int main (int argc, char* argv[])
  {
    if (mprotect (g_2, sizeof(g_2), PROT_READ) == -1)
      {
        int e = errno;
        error (e, e, "mprotect error %i", e);
      }
    foo ();
    __builtin_printf("OK\n");
    return 0;
  }
  /* EOF */
  $ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=0
  $ ./a.out
  OK
  $ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=1
  $ ./a.out
  Segmentation fault

  The testcase fails the same at least with 4.9, 4.8 and 4.7.  Therefore
  I would suggest building kernels with this parameter set to zero. I
  also agree with Jikos that the default should be changed for -O2.  I
  have run most of the SPEC 2k6 CPU benchmarks (gamess and dealII
  failed, at -O2, not sure why) compiled with and without this option
  and did not see any real difference between 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.

The code in question was out-of-tree printk-in-NMI (yeah, surprise
suprise, once again) patch written by Petr Mladek, let me quote his
comment from our internal bugzilla:

 "I have spent few days investigating inconsistent state of kernel ring buffer.
  It went out that it was caused by speculative store generated by
  gcc-4.3.4.

  The problem is in assembly generated for make_free_space(). The functions is
  called the following way:

  + vprintk_emit();
      + log = MAIN_LOG; // with logbuf_lock
         or
         log = NMI_LOG; // with nmi_logbuf_lock
         cont_add(log, ...);
          + cont_flush(log, ...);
              + log_store(log, ...);
                    + log_make_free_space(log, ...);

  If called with log = NMI_LOG then only nmi_log_* global variables are safe to
  modify but the generated code does store also into (main_)log_* global
  variables:

  <log_make_free_space>:
         55                      push   %rbp
         89 f6                   mov    %esi,%esi

         48 8b 05 03 99 51 01    mov    0x1519903(%rip),%rax       # ffffffff82620868 <nmi_log_next_id>
         44 8b 1d ec 98 51 01    mov    0x15198ec(%rip),%r11d      # ffffffff82620858 <log_next_idx>
         8b 35 36 60 14 01       mov    0x1146036(%rip),%esi       # ffffffff8224cfa8 <log_buf_len>
         44 8b 35 33 60 14 01    mov    0x1146033(%rip),%r14d      # ffffffff8224cfac <nmi_log_buf_len>
         4c 8b 2d d0 98 51 01    mov    0x15198d0(%rip),%r13       # ffffffff82620850 <log_next_seq>
         4c 8b 25 11 61 14 01    mov    0x1146111(%rip),%r12       # ffffffff8224d098 <log_buf>
         49 89 c2                mov    %rax,%r10
         48 21 c2                and    %rax,%rdx
         48 8b 1d 0c 99 55 01    mov    0x155990c(%rip),%rbx       # ffffffff826608a0 <nmi_log_buf>
         49 c1 ea 20             shr    $0x20,%r10
         48 89 55 d0             mov    %rdx,-0x30(%rbp)
         44 29 de                sub    %r11d,%esi
         45 29 d6                sub    %r10d,%r14d
         4c 8b 0d 97 98 51 01    mov    0x1519897(%rip),%r9	# ffffffff82620840 <log_first_seq>
         eb 7e                   jmp    ffffffff81107029	<log_make_free_space+0xe9>
  [...]
         85 ff                   test   %edi,%edi                  # edi = 1 for NMI_LOG
         4c 89 e8                mov    %r13,%rax
         4c 89 ca                mov    %r9,%rdx
         74 0a                   je     ffffffff8110703d	<log_make_free_space+0xfd>
         8b 15 27 98 51 01       mov    0x1519827(%rip),%edx       # ffffffff82620860 <nmi_log_first_id>
         48 8b 45 d0             mov    -0x30(%rbp),%rax
         48 39 c2                cmp    %rax,%rdx                  # end of loop
         0f 84 da 00 00 00       je     ffffffff81107120 <log_make_free_space+0x1e0>
  [...]
         85 ff                   test   %edi,%edi                  # edi = 1 for NMI_LOG
         4c 89 0d 17 97 51 01    mov    %r9,0x1519717(%rip)        # ffffffff82620840 <log_first_seq>
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
                                 KABOOOM
         74 35                   je     ffffffff81107160		 <log_make_free_space+0x220>

  It stores log_first_seq when edi == NMI_LOG. This instructions are used also
  when edi == MAIN_LOG but the store is done speculatively before the condition
  is decided.  It is unsafe because we do not have "logbuf_lock" in NMI context
  and some other process migh modify "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

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Martin Jambor <mjambor@suse.cz>
Cc: Petr Mladek <pmladek@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Marek Polacek <polacek@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Steven Noonan <steven@uplinklabs.net>
Cc: Richard Biener <richard.guenther@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:
	Makefile

Conflicts:
	Makefile
Makefile: enable -Werror=implicit-int and -Werror=strict-prototypes by default

The common error found in forward-ported/backported patches is missing
headers.  One recent example (files and function names are mangled):

    void foo(){}
    EXPORT_SYMBOL(foo);

gave only warning

    foo.c:12345678:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
    void foo(){}
         ^

    foo.c:12345679:5: warning: data definition has no type or storage class [enabled by default]
    EXPORT_SYMBOL(foo);
    foo.c:12345679:5: warning: type defaults to 'int' in declaration of 'EXORT_SYMBOL' [-Werror=implicit-int]

Now it's a fatal error. Tested on x86_64 allyesconfig.

[akpm@linux-foundation.org: fix typos in comments]
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>