[OE-core] [PATCH][morty] gcc6: Upgrade to 6.4.0 (latest stable series release)

[Martin Jansa]

Thanks Andre!

I've seen another failure probably caused by this gcc upgrade in morty-next:

python-matplotlib triggers ICE:

src/_png.cpp: In function 'void init_png()':
src/_png.cpp:497:25: warning: variable '_png' set but not used
[-Wunused-but-set-variable]
     static _png_module* _png = NULL;
                         ^~~~
src/_png.cpp: In member function 'Py::Object _png_module::read_png(const
Py::Tuple&)':
src/_png.cpp:272:1: internal compiler error: Segmentation fault
 _png_module::read_png(const Py::Tuple& args)
 ^~~~~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
error: command 'i586-oe-linux-gcc' failed with exit status 1
ERROR: Function failed: do_compile (log file is located at
python-matplotlib/1.1.0-r1/temp/log.do_compile.15213)

I'll try to build it with Khem's and Andre's patches only to eliminate
hjl/indirect/gcc-6-branch/master changes.

On Mon, Mar 5, 2018 at 7:37 AM, Andre McCurdy <armccurdy at gmail.com> wrote:

> On Sun, Mar 4, 2018 at 8:22 AM, Martin Jansa <martin.jansa at gmail.com>
> wrote:
> > On Sun, Mar 04, 2018 at 03:15:38PM +0100, Martin Jansa wrote:
> >> On Sun, Mar 04, 2018 at 11:21:32AM +0000, Richard Purdie wrote:
> >> > From: Juro Bystricky <juro.bystricky at intel.com>
> >> >
> >> > Changed BINV and PV from 6.2.0 to 6.4.0
> >> > Modified BASEURI to load xz tarball instead of bz2
> >> >
> >> > Backported series of patches from https://github.com/hjl-tools/
> gcc.git
> >> > branch /hjl/indirect/gcc-6-branch/master which contains
> >> > an IA patch series for security related issues
> >> >
> >> > ubsan-fix-check-empty-string.patch : removed, already applied
> >>
> >> Very limited testing with this change in morty shows that raspberrypi3
> >> (cortexa7hf-neon-vfpv4) build of glibc-initial fails with:
> >>
> >> configure:5344: checking for broken __attribute__((alias()))
> >> configure:5359: arm-oe-linux-gnueabi-gcc  -march=armv7ve -marm
> >> -mfpu=neon-vfpv4  -mfloat-abi=hard -mcpu=cortex-a7
> >> --sysroot=sysroots/raspberrypi3-tcbootstrap
> >> -Werror -S conftest.c -o conftest.s 1>&5
> >> conftest.c:1:0: error: switch -mcpu=cortex-a7 conflicts with
> >> -march=armv7ve switch [-Werror]
> >>          extern int foo (int x) __asm ("xyzzy");
> >>
> >> cc1: all warnings being treated as errors
> >> configure:5362: $? = 1
> >> configure:5372: result: yes
> >> configure:5375: error: working alias attribute support required
> >>
> >> Which is a bit strange as armv7ve was added to resolve this error with
> >> -mcpu=cortexa7 and -march=armv7a in:
> >>
> >> commit 35392025f3236f5e5393f9cf0857732da9a2e503
> >> Author: Martin Jansa <Martin.Jansa at gmail.com>
> >> Date:   Tue Oct 6 17:08:59 2015 +0200
> >>
> >>     arch-armv7ve: add tune include for armv7ve and use it from cortexa7
> >> and cortexa15
> >>
> >>     * be aware that this -march value is available only in gcc-4.9 and
> >>       newer:
> >>       https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907
> >>     * -mcpu=cortex15 and -mcpu=cortexa7 conflict with -march=armv7a
> >>       We either have to stop putting -march in default CCARGS or at
> >>       least set it compatible one like this patch does.
> >>
> >> Regards,
> >
> > It seems to be known regression in 6.4, with fix available here:
> > https://patchwork.ozlabs.org/patch/835592/
>
> Yes. Not only was the patch submitted upstream to gcc, it was even
> submitted to oe-core:
>
>   http://lists.openembedded.org/pipermail/openembedded-core/
> 2017-November/144159.html
>
> Unfortunately gcc 6.4.0 was dropped from oe-core master before the fix
> was merged...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180305/a46fcb61/attachment-0002.html>