openembedded-core.git/meta/recipes-devtools/gcc, branch dizzy

gcc-target: Don't install target gcc libdir files

2015-04-17T21:38:35+00:00

Installing /usr/lib/gcc/* means we'd have two copies, one from gcc-cross
and one from here. These can confuse gcc cross where includes use #include_next
and builds track file dependencies (e.g. perl and its makedepends code).
For determinism we don't install this to the sysroot, ever and rely on the
copy from gcc-cross.

[YOCTO #7287]

(From OE-Core rev: 15b3324b769dc92e1b0d4b9da9fbfccbc8dde9dd)

Signed-off-by: Richard Purdie

gcc-runtime: Remove libgfortran data from receipe

2015-04-17T21:38:34+00:00

Remove libgfortran packages from PACKAGES list as long as libgfortran
has separate receipe since commit

5bde5d9b39ea67f19a1a6aedd0c08c6cfedcbe5f
gcc: Allow fortran to build successfully in 4.8

Otherwise, when fortran support will be enabled in the compiler, both
lingfortran and gcc-runtime receipes will create the same files and will
try to install them. This will cause errors:

ERROR: The recipe libgfortran is trying to install files into a shared
area when those files already exist. Those files and their manifest
location are: ...
Please verify which recipe should provide the above files.

(From OE-Core rev: 872342fa3d08edede4a0105ac3ddb0f2ae3224b4)

Signed-off-by: Daniel Dragomir 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc/libgcc-common.inc: Add missing 'fakeroot' to two tasks

2015-02-11T17:39:51+00:00

Without the fakeroot flag the two tasks may create files or
symbolic links that end up being owned by the user and not
root:root as expected.

(From OE-Core rev: 7e9fd9d34a540fdfc1243d059d1f13f1d09864d2)

Signed-off-by: Mark Hatle 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc: ensure target gcc headers can be included

2015-02-11T17:39:50+00:00

There are a few headers installed as part of gcc-runtime (omp.h,
ssp/*.h). Being installed from a recipe built for the target
architecture, these are within the target sysroot and not
cross/nativesdk; thus they weren't able to be found by gcc with the
existing search paths. Add support for picking up these headers
under the sysroot supplied on the gcc command line in order to
resolve this.

Thanks to Richard Purdie for giving me a number of pointers during
fixing this issue.

Fixes [YOCTO #7141].

(From OE-Core rev: 5c87bb9ac2b35b3f8cf2b7d3e4507e7013115162)

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc: stub do_fetch instead of removing it

2015-01-06T14:13:08+00:00

Whilst gcc doesn't have any source to fetch, it still needs a fetch task so that
a world fetch can run without errors.  So instead of deleting the fetch task,
stub it.

(From OE-Core rev: 8e68ebbddc2bc41eb6cb607c51d6a80c54c4199d)

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc: Rework shared work

2015-01-06T14:13:08+00:00

The current implementation of shared work for gcc is at best confusing. It relies
on the fetch/unpack/patch tasks having exactly the same stamps and if this gets
broken for some reason, its hard to figure out what the problem is. It also
leads to complex code in bitbake.

The benefits of shared work for gcc are clear but a better approach is needed. This
patch adjusts things so that a single new recipe (gcc-source) provides the
fetch/unpack/patch/preconfigure tasks, the rest of gcc simply depends on these tasks
and have no fetch/unpack/patch tasks of their own.

This means we should get the significant benefits (disk usage/performance) of the
single source tree but in a way which has less potential for problems and is
easier for people to understand. The cost is an extra recipe/some inc files
which is probably a good tradeoff.

(From OE-Core rev: ceaa0a448dc5ebddb4f7fb94fb8a503a1c0248c3)

Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc-4.9: fix the compile failure of 'defaults.h' not found

2014-12-31T10:17:23+00:00

While compiling gcc-crosssdk-initial-x86_64 on some host, there is
occasionally failure that test the existance of default.h doesn't
work.
...
| tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/gcc/calls.c:1240:
error: 'STACK_CHECK_MAX_VAR_SIZE' was not declared in this scope
...

The reason is tm_include_list='** defaults.h' rather than
tm_include_list='** ./defaults.h'

So we add the test condition for this situation.

(From OE-Core rev: fec684512c6f934d7a847b0c9f5151da81426910)

Signed-off-by: Hongxu Jia 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc: Fix intermittent failures during configure

2014-12-31T10:17:15+00:00

If configure or any of the components it uses from the shared work directory
change, do_configure may fail.

An existing do_preconfigure was created to handle these conditions, but
a 'sed' operation was missed, and a call to gnu-configize was also missed.

(From OE-Core rev: 21c2cfff14442cf224e3568bdbb9bcd4070be247)

Signed-off-by: Mark Hatle 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc: backport two patches to fix ICE in dwarf2out_var_location

2014-12-31T10:17:14+00:00

The first patch fixes the ICE in dwarf2out_var_location, at
dwarf2out.c.

r212171:
    * except.c (emit_note_eh_region_end): New helper function.
    (convert_to_eh_region_ranges): Use emit_note_eh_region_end to
    emit EH_REGION_END note.
    * jump.c (cleanup_barriers): Do not split a call and its
    corresponding CALL_ARG_LOCATION note.

But it introduced a regression issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348

so backport the fix for the regression as well:

r215613:
    PR rtl-optimization/63348
    * emit-rtl.c (try_split): Do not emit extra barrier.

(From OE-Core rev: de52db1b1b0dbc9060dddceb42b7dd4f66a7e0f3)

Signed-off-by: Jackie Huang 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

gcc: backport patch for gcc bug 61144

2014-10-11T07:06:52+00:00

This fixes gcc bug 6144, which in my case exhibited itself as a kernel
module that failed to load. This was because static platform_data
structures were being corrupted with the optimiser being set to any
value other than -O0.

Originally-submitted-by: Peter Urbanec 

Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie