Re: [OE-core] [RFT] GCC 8.1

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 11927 bytes --]

On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> Hi Martin
> 
> Thanks for testing and reporting back
> 
> On 5/9/18 2:38 AM, Martin Jansa wrote:
> > My initial tests show couple issues, but usually caused by other changes 
> > in that branch, not the gcc-8 itself.
> > 
> > 1) strace-4.22 from 
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654
> > fails to build with ptest enabled (it builds with 4.20 version if I 
> > revert this change)
> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in 
> > asm here
> >   }
> >   ^
> 
> are you targeting thumb1 ? how can I reproduce it ?

I'm trying to find out what's different in the builds where it was
failing, will provide more info later.

> > Makefile:6313: recipe for target 'inject-nf.o' failed
> > make: *** [inject-nf.o] Error 1
> > make: Leaving directory 'strace/4.22-r0/build/tests'
> > 
> > 2) glibc with obsolete rpc disabled from: 
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a
> > causes busybox's mount applet to fail building:
> > util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
> >   # include <rpc/rpc.h>
> >             ^~~~~~~~~~~
> > compilation terminated.
> > make[1]: *** [util-linux/mount.o] Error 1
> > make: *** [util-linux] Error 2
> 
> I think you sent a patch already for this so discussion for fix are on 
> going.
> 
> > 
> > 3) grub and grub-efi fails to build with gcc8:
> > In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
> > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
> > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > ..
> > ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct 
> > grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > 
> 
> I think we need to align end of these structs here, can you try
> https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch

I've sent fix as well:
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150587.html
it's in master-next already.

> > 4) iotivity fails to build with gcc8:
> > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: 
> > In lambda function:
> > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: 
> > error: 'value' is not captured
> >                   ocRep[KEY] = value;
> >                                ^~~~~
> > 
> 
> this needs more investigation. May be move
> https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160
> 
> just above
> https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165

There are more issues in iotivity:
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+
+service/resource-encapsulation/unittests/ResourceClientTest.cpp:243:67: error: 'VALUE' is not captured
+extlibs/hippomocks/hippomocks/HippoMocks/hippomocks.h:1609:15: error: void value not ignored as it ought to be

e.g. rapidjson one is tracked upstream:
https://github.com/Tencent/rapidjson/issues/1205

for other issues I have a work around, but not good enough to submit for meta-oic.

> 
> > 5) nativesdk-libxcrypt fails to build (not sure which change caused 
> > this, it build OK with sumo since the -std=gnu99 addition.
> > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated 
> > before the last format character [-Werror=format-truncation=]
> >               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
> >               ^~~
> > 
> 
> something new, I will look into reproducing this.
> 
> > 6) couple internal components which usually fail to build with gcc8, 
> > because of more strict warnings + Werror.
> 
> OK, feel free to send out question if you get stuck
> 
> > 
> > I didn't get very far in testing, because our old kernel fails to build 
> > with gcc8 and there are some other issues caused by other master 
> > changes. But it doesn't look too bad (in my small test, lets see what 
> > bitbake world will show), thanks a lot for new gcc.
> > 
> 
> yes, older kernel needs fixes, especially to disable new warnings.
> the mips/ppc fixes that I put out there might be helpful to cook up 
> fixes for older kernels if running into same issues.

In this case it fails with Error: .err encountered for many drivers. It's not the same case as in:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html
nor arm version of this change, both are already applied in our
4.4.3 based kernel.

I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't
fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more.

> > Cheers,
> > 
> > 
> > 
> > 
> > 
> > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com 
> > <mailto:raj.khem@gmail.com>> wrote:
> > 
> >     Hi All
> > 
> >     As you might have noticed that gcc 8.1 was released this week, I am
> >     calling out for some testing help on testing branch so we can weed out
> >     issues you might see in your setups. so if you have your
> >     builders idling over weekend, then you know what they can do this
> >     weekend :)
> > 
> >     Highlighted changes are
> > 
> >     https://gcc.gnu.org/gcc-8/changes.html
> >     <https://gcc.gnu.org/gcc-8/changes.html>
> > 
> >     and porting doc is
> > 
> >     https://gcc.gnu.org/gcc-8/porting_to.html
> >     <https://gcc.gnu.org/gcc-8/porting_to.html>
> > 
> >     The branch is here
> > 
> >     http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
> >     <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8>
> > 
> >     Its uptodate on top of current master oe-core
> > 
> >     May fourth be with you !!
> > 
> >     Cheers!
> > 
> >     -Khem
> >     -- 
> >     _______________________________________________
> >     Openembedded-core mailing list
> >     Openembedded-core@lists.openembedded.org
> >     <mailto:Openembedded-core@lists.openembedded.org>
> >     http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
> > 
> > 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]