gcc stable version upgraded from v13.2 to v13.3
Dropped CVE-2023-4039.patch, CVE-2024-0151.patch and 0026-aarch64-Fix-loose-ldpstp-check-PR111411.patch
because its been taken to gcc-13.3 with below commits 71a2aa2127283f450c623d3604dbcabe0e14a8d4, 5550214b58e95320b54e42ef0e37c6479e04b27b
and 4bb1ae3c13ce4fb72129229de66f5ffbcd45fe4c respectively.
For changes in v13.3 see: https://gcc.gnu.org/onlinedocs/gcc-13.3.0/gcc/
Below is the bug fix list for v13.3
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&list_id=429106&resolution=FIXED&target_milestone=13.3
There are a total 173 bugs are fixed in this release, below is the list of bugs fixed excluding the regression fixes.
ID Product Comp Assignee▲ Summary
114408 gcc analyzer dmalcolm ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
109251 gcc analyzer dmalcolm -Wanalyzer-deref-before-check false positives seen in Linux kernel due to check in macros
114473 gcc analyzer dmalcolm ICE: in deref_rvalue, at analyzer/region-model.cc:2780 with -fanalyzer -fanalyzer-call-summaries
100988 gcc fortran anlauf Missed optimization: RESTRICT missing for optional arguments
112764 gcc fortran anlauf Associating entity does not have target attribute if selector has pointer attribute in associate block
114001 gcc fortran anlauf is_contiguous considers unlimited polymorphic dummy always as contiguous
112787 gcc target avieira Codegen regression of large GCC vector extensions when enabling SVE
114160 gcc target cmuellner ICE on RISCV (-mcpu=thead-c906) when building glibc in dwarf2out_frame_debug_cfa_offset
110882 gcc analyzer dmalcolm ICE with -fanalyzer on zero-sized array
111289 gcc analyzer dmalcolm Unwarranted -Wanalyzer-va-arg-type-mismatch warning
112790 gcc analyzer dmalcolm Wanalyzer-deref-before-check false positives seen in Linux kernel due to inlining
112792 gcc analyzer dmalcolm Wanalyzer-out-of-bounds false positives seen on Linux kernel with certain unions
114316 gcc libstdc+ fdumont assert failure with _GLIBCXX_DEBUG and empty range of singular iterators passed to std:: algorithm
108121 gcc modula2 gaius Failing tests on x86_64-linux-gnu
110754 gcc middle-e jakub assume create spurious load for volatile variable
105456 gcc libfortr jvdelisle Child I/O does not propage iostat
114747 gcc target kito Wrong SEW set for mixed-size intrinsics
104831 gcc target patrick RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST
108174 gcc target pinskia ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349
114314 gcc driver pinskia ICE: in common_handle_option, at opts.cc:3356 with -fno-multiflags
99493 gcc c++ ppalka Address of template parameter object is not a valid template argument
99631 gcc c++ ppalka decltype of non-type template-parameter shouldn't be const
104634 gcc c++ ppalka Explicit template instantiation does not work when there are multiple partial template specialization using concepts
110809 gcc c++ ppalka ICE: in unify, at cp/pt.cc:25226 with floating-point NTTPs
110927 gcc c++ ppalka GCC fails to parse dependent type in concept through partial specialization
111493 gcc c++ ppalka multidimensional subscript operator inside requires is broken
113242 gcc c++ ppalka g++ rejects-valid template argument of class type containing an lvalue reference
113529 gcc c++ ppalka Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`
108046 gcc libstdc+ redi The dot in the floating-point alternative form has wrong position
110708 gcc libstdc+ redi std::format("{:%EEC %OOd}", std::chrono::system_clock::now()) should be rejected 2023-07-28
110719 gcc libstdc+ redi Should chrono formatters always use std::time_put for locale's representation?
110860 gcc libstdc+ redi std::format("{:f}",2e304) invokes undefined behaviour
110862 gcc libstdc+ redi format out of bounds read on format string "{0:{0}"
110917 gcc libstdc+ redi std::format_to(int*, ...) fails to compile because of _S_make_span
110944 gcc libstdc+ redi std::variant & optional GDB representation is too verbose
110968 gcc libstdc+ redi format out of bounds read on format("{:05L}",-1.f)
110970 gcc libstdc+ redi clang / c++23 missing 'typename' prior to dependent type name
110990 gcc libstdc+ redi `format_to_n` returns wrong value
111511 gcc libstdc+ redi Incorrect ADL in std::to_array in GCC 11/12/13
111826 gcc libstdc+ redi __cpp_lib_format should be 202110, not 202106
111948 gcc libstdc+ redi subrange modifies a const size object
112607 gcc libstdc+ redi _Normalize does not consider char_type for the basic_string_view case
112832 gcc libstdc+ redi Broken non-SFINAE-friendly `set_debug_format()` for `const char *` formatter
113500 gcc libstdc+ redi Using std::format with float or double based std::chrono::time_point causes error: no match for 'operator<<'
13512 gcc libstdc+ redi Incorrect results for std::format("{:#.3g}", flt)
114103 gcc libstdc+ redi FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)
114152 gcc libstdc+ redi Wrong exception specifiers for LFTSv3 scope guard destructors
114863 gcc libstdc+ redi std::format applying grouping to nan's and inf's
115063 gcc libstdc+ redi compilation error: std::basic_stracktrace::max_size()
105523 gcc target saaadhu Wrong warning array subscript [0] is outside array bounds
93370 gcc target unassigned Aarch64 accepts but ignores target("+sm4") unless ARMv8.2-A is enabled
93762 gcc fortran unassigned Truncation of deferred-length string when passing as optional
100285 gcc libstdc+ unassigned experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)
106037 gcc ada unassigned internal error with Aggregate aspect on array type
110127 gcc c++ unassigned -fimplicit-constexpr leads to extremely slow and memory intensive compilation
110133 gcc libstdc+ unassigned System error message should ideally use strerror_r over strerror
110974 gcc libstdc+ unassigned format out of bounds read on invalid format string "{:{}."
111102 gcc libstdc+ unassigned illegal pointer arithmetic invoked by std::format("L{:65536}",1)
112480 gcc libstdc+ unassigned optional<T>::reset emits inefficient code when T is trivially-destructible
113294 gcc libstdc+ unassigned constexpr error from accessing inactive union member in basic_string after move assignment
113815 gcc ada unassigned error: there is no applicable operator "*" for a string type
113824 gcc target unassigned AVR: ATA5795 in wrong multilib set 2024-02-08
113850 gcc libgcc unassigned condition variables timed wait does a lot of spurious wakeups on Win32 threading implementation
113927 gcc target unassigned Sets up a stack-frame even for trivial code
114136 gcc middle-e unassigned wrong code for c23 fully anonymous arg lists on arm
97245 gcc fortran anlauf ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used
101135 gcc fortran anlauf Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
110825 gcc fortran anlauf TYPE(*) dummy argument to generate an unused hidden argument
110826 gcc fortran anlauf Fortran array of derived type with a pointer to function with dimensional arguments fails
113799 gcc fortran anlauf gfc_replace_expr: double free detected ?
114012 gcc fortran anlauf overloaded unary operator called twice
113601 gcc target gjl avr: Wrong SRAM start for ATmega3208 and ATmega3209
107201 gcc target unassigned -nodevicelib not working for devices -mmcu=avr...
114024 gcc fortran unassigned ICE allocate statement with source=cmp%re and z an array
53372 gcc target unassigned Section attribute ignored with address space
112952 gcc target unassigned avr: attribute address not working with -fdata-sections -fno-common
114752 gcc target unassigned AVR: internal compiler error. Unknown mode: const_double:DF
114794 gcc target unassigned Speed up udivmodqi4
(From OE-Core rev: 20b94a6f3681afc9d5f7c07d571fcc47efcc9827)
Signed-off-by: Deepthi Hemraj <Deepthi.Hemraj@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In testing websocket hashequivalence, corrupted sstate was injected into the
autobuilder extensively. With the new release/LTS, being able to clearly
differentiate between old and new sstate is probably desireable anyway
so bump the appropriate versions.
(From OE-Core rev: 7f107c180f592be29f57f580c60a6adbbebd7714)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For the newer hash equivlance servers we need websockets. Import it
from meta-oe so we can easily include it in buildtools tarball.
(From OE-Core rev: c61ed007b9e06683065aed62af1e1ca4569b8c16)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oldincludedir was removed by 506c91cbc6a604a84e37e53ccff430436369802e
(From OE-Core rev: 0228ab43e9b659771f4f59944897aec6879f8209)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When run-postinsts is installed, a service is added for system which can run
while the package is still being installed. This calls "opkg configure" and if
package management is still running, it can deadlock and error.
To work around this, call fcntl-lock on the opkg lock file and if the lock
was held, it would wait to obtain it. This wait gives the package management
time to finish the install before the configure can then take the lock and run.
Note the dependency in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS otherwise we'd see
sstate selftest failures.
Also ensure that if the configure fails, the scripts returns an error. This
applies to opkg and dpkg.
(From OE-Core rev: 96d37df074dc1fe1578c1406235dff7e328b62b7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The upstream maintainer for Error has deprecated it for quite some time [1].
The only dependency in oe-core was coreutils-ptest.
[YOCTO #15461]
[1] https://metacpan.org/pod/Error#WARNING
Using the "Error" module is no longer recommended due to the black-magical
nature of its syntactic sugar, which often tends to break. Its maintainers
have stopped actively writing code that uses it, and discourage people from
doing so. See the "SEE ALSO" section below for better recommendations [2].
[2] https://metacpan.org/pod/Error#SEE-ALSO
SEE ALSO
--------
See Exception::Class for a different module providing Object-Oriented
exception handling, along with a convenient syntax for declaring hierarchies
for them. It doesn't provide Error's syntactic sugar of try { ... },
catch { ... }, etc. which may be a good thing or a bad thing based on what
you want. (Because Error's syntactic sugar tends to break.)
Error::Exception aims to combine Error and Exception::Class "with correct
stringification".
TryCatch and Try::Tiny are similar in concept to Error.pm only providing a
syntax that hopefully breaks less.
(From OE-Core rev: 7750469e0acfb7f7ef5b3002d1562df5354e6a61)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Any image that inherits qemuboot must also add image dependencies on
qemu-system-native and qemu-helper-native, otherwise the image won't
be able to be booted.
Currently this is done by conf/machine/include/qemu.inc, but not every
machine that uses qemuboot includes that file.
Move the EXTRA_IMAGEDEPENDS from qemu.inc into qemuboot.bbclass, so that
the dependencies don't have to be duplicated.
(From OE-Core rev: dd54cf058f632e985917ff227483995f368e6a7d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As we're close to release, drop compatibility to nanbield, people
have had time to switch now.
(From OE-Core rev: 0e42326dfd6b9042b405329ceb56a93199a89a85)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add vulkan-volk recipe to support building latest vulkan-tools.
(From OE-Core rev: d3d0375fa0b4809d2c69837faf5df297d92de683)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's a hard dependency of recent python3-sphinx-rtd-theme
versions:
4d6de11137
The issue is exposed by latest btrfs-tools update.
(From OE-Core rev: 7a3d074f2d1679b4d4e52c4a023edb46224ca0be)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bmaptool (previously: bmap-tools, bmap-tool, bmaptool) has been moved
to be under the Yocto Project umbrella and is now hosted at:
github.com/yoctoproject/bmaptool
[RP: Added a couple of missing renames]
(From OE-Core rev: 7a036b1a1ec7dcd27dbe18d4c2e703bd2a8af182)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we enable package-management for core-image-full-cmdline we need the workarounds
used for core-image-weston to ensure the oe-selftest license QA tests keep working.
(From OE-Core rev: 29bc855c167ff66aea7ca4681cee85c2557b2308)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Drop backported musl fixes.
* Set `change-id` rather than `changelog-seen`
to fix build warning.
* Add fixes for 4b7e0a0b56aa24 ("Handle vendored sources
when remapping paths") which otherwise cause build failures:
| thread 'main' panicked at src/core/builder.rs:1795:26:
| std::fs::read_dir(registry_src) failed with No such file or directory (os=
error 2)
https://blog.rust-lang.org/2023/12/28/Rust-1.75.0.html
(From OE-Core rev: 9aec2c6c777388bb3129aa4c4f27a40f912522b4)
Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now both gcc and clang all support -march=loongarch64, so we can use it.
(From OE-Core rev: acc08582293709c73011083aa7d5c631a9ae8c8c)
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
split_locales() must only check subdirectories in paths added to
LOCALE_PATHS to avoid creating weird packages based on filenames also
present in paths.
Without such a filter, cups recipe adding ${datadir}/cups/templates to
LOCALE_PATHS creates the following incorrect packages:
- cups-locale-add-class.tmpl
- cups-locale-add-printer.tmpl
- cups-locale-admin.tmpl
(From OE-Core rev: ba3aee0d516bd066829d6edaa8d7bacdd75dd6ef)
Signed-off-by: Jonathan GUILLOT <jonathan@joggee.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to hashserv API changes in siggen, we need bitbake 2.7.3.
(From OE-Core rev: 7172fd527fde440f26dd6cc371cde2720dbaa366)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Existing conf-notes.txt is not adequate in situations where the user
needs to select a config template from several, or get an overview of them and
is interested only in a brief explanation of what the template is for,
but not extended multi-paragraph instructions for how to use it.
Such summaries can be provided via conf-summary.txt and
this patch adds such a summary for the oe-core default template.
Updates to the tools and a tool for selecting templates which
will make specific use of the summary will follow.
(From OE-Core rev: aa96c2064a874714cfe4bac2fa622690e4c27ee4)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some packages may contain localized files not located in default path
${datadir}/locale. Add the new variable LOCALE_PATHS to allow a recipe
to define extra paths or even fully override the scanned directories.
LOCALE_PATHS is set at ${datadir}/locale by default to keep the exact
same behavior for the recipes which did not need modification.
(From OE-Core rev: 0ffc7cf01225743789ac30dd325fca05b9203be1)
Signed-off-by: Jonathan GUILLOT <jonathan@joggee.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a single version of llvm in core these days, furthermore the
version is no longer asked for by recipes such as mesa, which would use
llvm-config tool according to version of llvm found.
(From OE-Core rev: 15d09b02b2632ab1cabc3b1bd9f521e6d3d3b83f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Ross Burton <ross.burton@arm.com>
Acked-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python 3 interprets string literals as Unicode strings, and therefore
\s is treated as an escaped Unicode character which is not correct.
Declaring the RegEx pattern as a raw string instead of unicode is
required for Python 3.
(From OE-Core rev: 662f52f1713c9f070550fc0c874eb62312218ea4)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
feature-microblaze-versions.inc#
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream is in the process of migrating testing to pytest, backport
test_dump_load.py (the legacy_tests were throwing Errors and Failures).
We don't really need to run upstream's test suite, but we do need to verify
that our runtime is functional.
a98fd6088e
(From OE-Core rev: b0fdf0688109ba6b87840a0837bebee3d9a27089)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit dea5e8863792dc7bb3324b543e04da4c94a060aa.
The original commit claims that lzop is unused in OE-core.
That is not correct, the following places still use it and
became unbuildable now:
"
meta/classes-recipe/image_types.bbclass:CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}.${type}"
meta/classes-recipe/image_types.bbclass:CONVERSION_DEPENDS_lzo = "lzop-native"
meta/classes-recipe/kernel-uboot.bbclass: lzop -9 linux.bin
meta/classes-recipe/kernel.bbclass:DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", "lzop-native", "", d)}"
meta/classes-recipe/kernel.bbclass: lzop -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
"
Furthermore, LZO is the best compromise between kernel decompression
time and size on low end ARM systems, that is why it is often used
with e.g.:
FIT_KERNEL_COMP_ALG = "lzo"
FIT_KERNEL_COMP_ALG_EXTENSION = ".lzo"
Reinstate the package to avoid breaking this use case.
[RP: For me, the real reason to justify this is fact that several SoC/BSP
layers do want this as a dependency]
(From OE-Core rev: 6e8a0d66e05387d55c49a275faa7f4aa2bf6f2ac)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Prepare for the scarthgap release.
(From OE-Core rev: b1835e657575c29da43a15a37c673dc37044fd85)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Description: now we can tune our build only for power7 or power9
processor for PowerPC arch, this patch add posibility to choose power8 tune.
(From OE-Core rev: 10f7eeafd16c8b825b3c9b96b8433311f122df1e)
Signed-off-by: Aleksey Smirnov <aleksey.smirnov@yadro.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Most ptests run on on riscv64 but for some reason python3 hangs. Move
it to the problem list until this is resolved so we can establish a
"known to work" baseline.
(was still going after 42000s, long after everything else finished)
(From OE-Core rev: adc448b19e80f6343050f4c527acc63a161c88ca)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed for rpm reproducibility, as otherwise libmagic
will call an external lzip executable, which is both
non-threadsafe, and non-deterministic w.r.t sysroot presence.
(From OE-Core rev: 0e4bde86e1aa499274fc85d01d36a74c3401762e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for SVE2 and add to 8-2a, as it can be used there.
Also, clean up the comments
(From OE-Core rev: 683443d57cb18b3b54245b1a09b6e5d2bae4f5d0)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With changes to gcc-runtime around improving debugging, python modules
are needed but this pulls in bash which breaks the tests.
Add an exclusion to the no-gplv3 include file to handle this.
(From OE-Core rev: 803060fa4e8fe98ac8f987b80162110d06788946)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create a no-gplv3.inc file based upon knowledge currently encoded into one
of the selftests.
There is a risk that people try and take this idea too far, or have unrealistic
expectations. That said, it would be better to collect this knowledge together
in one location rather than handling it piecemeal.
Therefore move the configuration information from the test into a common
incude file.
(From OE-Core rev: fb822fb2029c69934cf43073f95b396c2d60298e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the ability to specify cortexr52hf to get a version that enables the
hard-float calling convention.
(From OE-Core rev: be83bc937a76efaead4690237db25459a57673fc)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the ability to specify cortexr5hf to get a version that enables the
hard-float calling convention.
(From OE-Core rev: 992149023a896ecb38d07c54fa9ae9df82249a07)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently hard-float is dependency upon the special TUNE_CCARGS_MFPU which
contains custom -mfpu= values. However, newer 32-bit architectures like
cortex-r52 use 'simd' instead. There is no 'simd' entry for -mfpu=
according to the GCC manual, it's more or less automatic based on the
cpu settings.
Add this as an exception to the TUNE_CCARGS_FLOAT setting of hard or softfp.
(From OE-Core rev: f122eb8b19528e1192fd0b68b0639d84aa288155)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current include logic goes into generic arm v8/v9 architecture tunes and
adds corresponding -march option after synthesizing it from various tune
fragments, this is fine for a machine which is using armv8/armv9 based
tunes but cortex tunes are intentionally using -mcpu option based on
selected tune value. So when cortex based default tune is selected for a
machine, it will add both -mcpu and -march to the compiler commandline
which can result in invalid combinations for this pair in gcc's own
logic. This can then result in compiler warnings/errors reporting this
e.g.
aarch64-yoe-linux-gcc -mcpu=cortex-a72.cortex-a53 -march=armv8-a+crc+crypto -mbranch-protection=standard
...
cc1: error: switch '-mcpu=cortex-a72.cortex-a53' conflicts with '-march=armv8-a+crc+crypto' switch and resulted in options '+crc+crypto' being added [-Werror]
This is seen in lot of configure test results in glibc 2.39 and the
warning is promoted to errors by gcc in some of these checks especially
with gcc-14, the logs also show it as warning in other places in
configure checks.
mcpu option will compute relevant march implicitly as it specifies a cpu
implementation and this will be the right value to use, therefore do not
specify -march when -mcpu is already describing the cpu.
(From OE-Core rev: e64f0c1b6ac5d598a79a21de5f3060f83cb9523e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Ross Burton <ross.burton@arm.com>
Cc: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
