Yes it is exactly that one because of Bar::Bar takes a std::pair<float, float> type and that bug is about std::pair causing an ABI mismatch for -std=c++17 and -std=c++14 on aarch64.
Thanks, Andrew Pinski ________________________________________ From: Andrew Pinski <apin...@marvell.com> Sent: Monday, March 30, 2020 9:39 AM To: Jussi Lind; Maxim Kuvyrkov Cc: linaro-toolchain@lists.linaro.org Subject: Re: [EXT] Re: TX2 + C++17 problems I am thinking this is the same issue as referecned at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 . Thanks, Andrew ________________________________________ From: linaro-toolchain <linaro-toolchain-boun...@lists.linaro.org> on behalf of Jussi Lind <jussi.l...@unikie.com> Sent: Friday, March 27, 2020 5:47 AM To: Maxim Kuvyrkov Cc: linaro-toolchain@lists.linaro.org Subject: [EXT] Re: TX2 + C++17 problems External Email ---------------------------------------------------------------------- Hi, I now have a working test case and instructions here (also attached): https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-3Fid-3D1B5SceFB1mKkCnE8iE59Mq0lScK2F0iOl&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=L_uAQMgirzaBwiEk05NHY-AMcNfJzugOS_xTjrtS94k&m=iDyyHRMZMk8s9uRRA_86ocKSPqTC9IZyT9TcLX1cRj0&s=i69mfJ635bPGytve6Gd5ZCV7eZ4MJ-s9Vo-vvEzn5rI&e= I haven't changed my compiler version. Only the C++ standard from C++14 to C++17 so that my app and lib use different standards. That should not break anything, right? If both are on C++14 or both are on C++17 things are ok. I'm running this on Jetson TX2 (Ubuntu 18.04, GCC 7.5.0). Details here: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/7/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu Thread model: posix gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) On Fri, Mar 27, 2020 at 1:38 PM Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> wrote: > > On Mar 26, 2020, at 3:13 PM, Jussi Lind <jussi.l...@unikie.com> wrote: > > > > Hi, > > > > We are having some serious problems after we upgraded from C++14 to C++17 > > on an Jetson TX2 ARM device. Our system tests started to behave > differently > > and fail. > > > > It seems that when our application uses a library (also developed by us) > > some data gets corrupted when delivered to a class constructor. For > > example, the .second of and std::pair<float> appears to be the .first and > > the .second is garbage. This is deterministic, but different tests are > > failing depending on the combination: library C++17/C++14 <-> application > > C++14/C++17. > > > > This is on Ubuntu 18.04 and gcc version 7.5.0 (Ubuntu > 7.5.0-3ubuntu1~18.04). > > > > Nothing like this happens on Intel. > > > > So: > > ARM, C++14: OK > > Intel, C++14: OK > > ARM, C++17: FAIL > > Intel, C++17: OK > > > > Any ideas what could cause this? I know this is a bit vague, but this a > > commercial, closed-source application so I cannot yet give any other > > information. > > > > Hi Jussi, > > What target are you using? Is it 32-bit armhf (arm-linux-gnueabihf) or > 64-bit AArch64 (aarch64-linux-gnu)? > > If it is armhf, then take a look at notice at > https://urldefense.proofpoint.com/v2/url?u=http-3A__releases.linaro.org_components_toolchain_binaries_latest-2D7_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=L_uAQMgirzaBwiEk05NHY-AMcNfJzugOS_xTjrtS94k&m=iDyyHRMZMk8s9uRRA_86ocKSPqTC9IZyT9TcLX1cRj0&s=ovYGQUHaSXGbXe1YqXW6PP3W92o84iTOwVYdtWozrC4&e= > . > There has been an ABI bug in GCC 5.x and GCC 6.x, which has been fixed in > GCC 7.x. If you didn't fully recompile all you libraries with GCC 7.x, > then you could be hitting that bug. > > Another thing to try is to upgrade to latest GCC 9.x. GCC 7.x was EOL'ed > for some time, and GCC 8.x will go EOL later this year. If your problem > reproduces with GCC 9.x or GCC's master branch, then we'll do our best to > investigate it (provided a reproducible testcase, of course). > > Regards, > > -- > Maxim Kuvyrkov > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linaro.org&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=L_uAQMgirzaBwiEk05NHY-AMcNfJzugOS_xTjrtS94k&m=iDyyHRMZMk8s9uRRA_86ocKSPqTC9IZyT9TcLX1cRj0&s=7AbrZRzG_ZNbFrEiDIVLGw8MEDVwrdOSF9FbbvDD9EU&e= > > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.linaro.org_mailman_listinfo_linaro-2Dtoolchain&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=L_uAQMgirzaBwiEk05NHY-AMcNfJzugOS_xTjrtS94k&m=iDyyHRMZMk8s9uRRA_86ocKSPqTC9IZyT9TcLX1cRj0&s=a9bjnUNlFYWBrOWG0ZAQJZmZ0TdEWuo39vnw48pB8WY&e= _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
