1. 09 Feb, 2017 1 commit
  2. 11 Dec, 2016 1 commit
  3. 25 Oct, 2016 1 commit
  4. 12 Sep, 2016 1 commit
  5. 03 Aug, 2016 3 commits
  6. 02 Aug, 2016 1 commit
  7. 25 Jul, 2016 1 commit
  8. 24 Jul, 2016 1 commit
  9. 03 Jul, 2016 2 commits
  10. 27 Jun, 2016 1 commit
  11. 16 May, 2016 1 commit
  12. 27 Apr, 2016 1 commit
    • Thomas Petazzoni's avatar
      gcc: add support for gcc 6 · 519d83bf
      Thomas Petazzoni authored
      This commit adds the support for gcc 6. This release allows to remove
      a large number of our gcc patches, mainly thanks to the Xtensa and
      musl related patches being merged upstream.
      Patches kept with no changes:
      Patches dropped because they have been merged upstream, or were
      already upstream backports:
       120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged)
       850-libstdcxx-uclibc-c99.patch (merged in a different form, see
       870-xtensa-add-mauto-litpools-option.patch (upstream backport)
       871-xtensa-reimplement-register-spilling.patch (upstream backport)
       872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport)
       873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport)
       874-xtensa-add-uclinux-support.patch (upstream backport)
       900-libitm-fixes-for-musl-support.patch (upstream backport)
       901-fixincludes-update-for-musl-support.patch (upstream backport)
       902-unwind-fix-for-musl.patch (upstream backport)
       903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport)
       904-musl-libc-config.patch (upstream backport)
       905-add-musl-support-to-gcc.patch (upstream backport)
       905-add-musl-support-to-gcc.patch (upstream backport)
       906-mips-musl-support.patch (upstream backport)
       907-x86-musl-support.patch (upstream backport)
       908-arm-musl-support.patch (upstream backport)
       909-aarch64-musl-support.patch (upstream backport)
      Successfully build-time and run-time tested with
      qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
  13. 20 Apr, 2016 1 commit
  14. 18 Apr, 2016 1 commit
  15. 20 Mar, 2016 1 commit
    • Thomas Petazzoni's avatar
      toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMIC · 42735cb9
      Thomas Petazzoni authored
      Until now, we were assuming that whenever you have gcc 4.8, libatomic
      is available. It turns out that this is not correct, since libatomic
      will not be available if thread support is disabled in the toolchain.
      Therefore, __atomic_*() intrinsics may not be available even if the
      toolchain uses gcc 4.8.
      To solve this problem, we introduce a BR2_TOOLCHAIN_HAS_LIBATOMIC
      boolean, which indicates whether the toolchain has libatomic. It is
      the case when you are using gcc >= 4.8 *and* thread support is
      enabled. We then use this new BR2_TOOLCHAIN_HAS_LIBATOMIC to define
      As explained in the comment, on certain architectures, libatomic is
      technically not needed to provide the __atomic_*() intrinsics since
      they might be all built-in. However, since libatomic is only absent in
      non-thread capable toolchains, it is not worth making things more
      complex for such seldomly used configuration.
      Note that we are introducing the intermediate
      BR2_TOOLCHAIN_HAS_LIBATOMIC option because it will be useful on its
      own for certain packages.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      [Thomas: improve Config.in comment using a suggestion from Yann.]
  16. 14 Mar, 2016 1 commit
  17. 06 Feb, 2016 1 commit
    • Thomas Petazzoni's avatar
      toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans · 6856e417
      Thomas Petazzoni authored
      Currently, Buildroot provides one BR2_ARCH_HAS_ATOMICS boolean option
      to indicate whether the architecture supports atomic operations or
      not. However, the reality of atomic operations support is much more
      complicated and requires more than one option to be expressed
      There are in fact two types of atomic built-ins provided by gcc:
       (1) The __sync_*() family of functions, which have been in gcc for a
           long time (probably gcc 4.1). They are available in variants
           operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some
           architectures implement a number of variants, some do not
           implement any, some implement all of them.
           They are now considered "legacy" by the gcc developers but are
           nonetheless still being used by a significant number of userspace
           libraries and applications.
       (2) The __atomic_*() family of functions, which have been introduced
           in gcc 4.7. They have been introduced in order to support C++11
           atomic operations. In gcc 4.8, they are available on all
           architectures, either built-in or in the libatomic library part
           of the gcc runtime (in which case the application needs to be
           linked with -latomic). In gcc 4.7, the __atomic_*() intrinsics
           are only supported on certain architectures, since libatomic did
           not exist at the time.
      For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because
      depending on the architecture, some variants may or may not be
      available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the
      variant is missing would cause a large number of packages to become
      unavailable, even if they in fact use only more common variants
      available on a large number of architectures. For this reason, we've
      chosen to introduce four new Config.in options:
      Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte
      and 8-byte __sync_*() built-ins respectively.
      For (2), we introduce a BR2_TOOLCHAIN_HAS_ATOMIC, which indicates if
      the __atomic_*() built-ins are available. Note that it is up to the
      package to link with -latomic when gcc is >= 4.8. Since __atomic_*()
      intrinsics for all sizes are supported starting
      We conducted a fairly large analysis about various architectures
      supported by Buildroot, as well as with a number of different
      toolchains, to check which combinations support which variant. To do,
      we linked the following program with various toolchains:
      int main(void)
      	uint8_t a;
      	uint16_t b;
      	uint32_t c;
      	uint64_t d;
      	__sync_fetch_and_add(&a, 3);
      	__sync_fetch_and_add(&b, 3);
      	__sync_fetch_and_add(&c, 3);
      	__sync_fetch_and_add(&d, 3);
      	__sync_val_compare_and_swap(&a, 1, 2);
      	__sync_val_compare_and_swap(&b, 1, 2);
      	__sync_val_compare_and_swap(&c, 1, 2);
      	__sync_val_compare_and_swap(&d, 1, 2);
      	__atomic_add_fetch(&a, 3, __ATOMIC_RELAXED);
      	__atomic_add_fetch(&b, 3, __ATOMIC_RELAXED);
      	__atomic_add_fetch(&c, 3, __ATOMIC_RELAXED);
      	__atomic_add_fetch(&d, 3, __ATOMIC_RELAXED);
      	__atomic_compare_exchange_n(&a, &a, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
      	__atomic_compare_exchange_n(&b, &b, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
      	__atomic_compare_exchange_n(&c, &c, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
      	__atomic_compare_exchange_n(&d, &d, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
      	return 0;
      And looked at which symbols were unresolved. For the __atomic_*()
      ones, we tested with and without -latomic to see which variants are
      built-in, which variants require libatomic. This testing effort has
      led to the following results:
                      __sync       __atomic    gcc
                     1  2  4  8    1  2  4  8
      ARC            Y  Y  Y  -    Y  Y  Y  L   4.8 [with BR2_ARC_ATOMIC_EXT]
      ARC            -  -  -  -    L  L  L  L   4.8 [without BR2_ARC_ATOMIC_EXT]
      ARM            Y  Y  Y  X    Y  Y  Y  Y   4.8, 4.7
      ARM            Y  Y  Y  -                 4.5
      AArch64        Y  Y  Y  Y    Y  Y  Y  Y   4.9, 5.1
      Bfin           -  -  Y  -                 4.3
      i386 (i386)    -  -  -  -    L  L  L  L   4.9
      i386 (i486..)  Y  Y  Y  -    L  L  L  L   4.9 [i486, c3, winchip2, winchip-c6]
      i386 (> i586)  Y  Y  Y  Y    L  L  L  L   4.9
      Microblaze     -  -  Y  -    L  L  Y  L   4.9
      MIPS           Y  Y  Y  -    Y  Y  Y  L   4.9
      MIPS64         Y  Y  Y  Y    Y  Y  Y  Y   4.9
      NIOS 2         Y  Y  Y  -    Y  Y  Y  L   4.9, 5.2
      PowerPC        Y  Y  Y  -    Y  Y  Y  L   4.9
      SuperH         Y  Y  Y  -    Y  Y  Y  L   4.9
      SPARC          -  -  -  -    L  L  L  L   4.9
      SPARC64        Y  Y  Y  Y    Y  Y  Y  Y   4.9
      x86_64         Y  Y  Y  Y    Y  Y  Y  Y   4.7, 4.9
      Xtensa         Y  Y  Y  -    Y  Y  Y  Y   4.9
       * __atomic built-ins appeared in gcc 4.7, so for toolchais older than
         that, the __atomic column is empty.
       * Y means 'supported built-in'
       * L means 'supported via linking to libatomic' (only for __atomic
       * X indicates a very special case for 8 bytes __sync built-ins on
         ARM. On ARMv7, there is no problem, starting from gcc 4.7, the
         __sync built-in for 8 bytes integers is implemented, fully in
         userspace. For cores < ARMv7, doing a 8 bytes atomic operation
         requires help from the kernel. Unfortunately, the libgcc code
         implementing this uses the __write() function to display an error,
         and this function is internal to glibc. Therefore, if you're using
         glibc everything is fine, but if you're using uClibc or musl, you
         cannot link an application that uses 8 bytes __sync
         operations. This has been fixed as part of gcc PR68095, merged in
         the gcc 5 branch but not yet part of any gcc release.
       * - means not supported
      This commit only introduces the new options. Follow-up commits will
      progressively change the packages using BR2_ARCH_HAS_ATOMICS to use
      until the point where BR2_ARCH_HAS_ATOMICS can be removed.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
  18. 30 Jan, 2016 1 commit
    • Thomas Petazzoni's avatar
      package, toolchain: remove BR2_TOOLCHAIN_HAS_GCC_BUG_* options · 07bb65c6
      Thomas Petazzoni authored
      Quite some time ago, we added the options
      indicate if the toolchain was affected by those gcc bugs, which were
      causing build failure with a number of packages.
      With the recent change in the external toolchain logic to provide only
      the latest version of each toolchain "family", all the toolchains
      which were affected by those issues disappeared from Buildroot. Those
      options are no longer being selected anywhere, and being blind
      options, it means their value is always going to be "disabled".
      Conquently, this commit removes those options completely, and updates
      all the packages where they were used.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
  19. 11 Jan, 2016 1 commit
  20. 02 Nov, 2015 1 commit
  21. 01 Sep, 2015 1 commit
  22. 05 Aug, 2015 1 commit
  23. 22 Jun, 2015 1 commit
  24. 09 Jun, 2015 1 commit
  25. 22 Apr, 2015 2 commits
  26. 13 Apr, 2015 1 commit
  27. 01 Apr, 2015 2 commits
  28. 09 Feb, 2015 1 commit
  29. 21 Dec, 2014 1 commit
    • Yann E. MORIN's avatar
      toolchain: get rid of -pipe from optimisations · 01c34b38
      Yann E. MORIN authored
      -pipe is causing some build failures in Linux kernel >= 3.17.
      Also, nowadays, using -pipe does not gain as much as it used to back in
      the days:
      Measurements made with a 3.16.7 Linux kernel:
          make linux-depends
          time sh -c 'make linux-build >/dev/null 2>&1'
      Without -pipe:
          716.32user 54.44system 3:42.12elapsed 346%CPU
          721.22user 54.47system 3:41.81elapsed 349%CPU
          722.44user 54.00system 3:42.13elapsed 349%CPU
          721.03user 53.81system 3:41.92elapsed 349%CPU
          713.21user 53.63system 3:40.51elapsed 347%CPU
          706.67user 52.42system 3:38.40elapsed 347%CPU
          714.40user 53.18system 3:40.16elapsed 348%CPU
          706.01user 53.09system 3:37.87elapsed 348%CPU
          705.98user 53.01system 3:38.03elapsed 348%CPU
          714.17user 53.55system 3:39.98elapsed 348%CPU
      Average:                   3:40.29elapsed
      With -pipe:
          720.13user 53.90system 3:41.98elapsed 348%CPU
          713.38user 53.69system 3:40.44elapsed 347%CPU
          711.60user 52.81system 3:39.06elapsed 348%CPU
          708.66user 53.09system 3:38.59elapsed 348%CPU
          711.76user 53.00system 3:38.48elapsed 350%CPU
          717.85user 53.97system 3:41.77elapsed 348%CPU
          716.77user 53.77system 3:40.91elapsed 348%CPU
          717.48user 53.65system 3:41.24elapsed 348%CPU
          721.44user 55.67system 3:43.45elapsed 347%CPU
          724.61user 55.63system 3:43.35elapsed 349%CPU
      Average:                   3:40.93elapsed
      The delta is well in the measurement noise.
      Just get rid of it.
      Signed-off-by: default avatar"Yann E. MORIN" <yann.morin.1998@free.fr>
      Cc: Romain Naour <romain.naour@openwide.fr>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
  30. 08 Dec, 2014 1 commit
  31. 21 Nov, 2014 2 commits
  32. 06 Oct, 2014 1 commit
  33. 18 Aug, 2014 2 commits