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.
BR, Jussi Lind
On Mar 26, 2020, at 3:13 PM, Jussi Lind jussi.lind@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 http://releases.linaro.org/components/toolchain/binaries/latest-7/ . 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://www.linaro.org
Hi,
I now have a working test case and instructions here (also attached): https://drive.google.com/open?id=1B5SceFB1mKkCnE8iE59Mq0lScK2F0iOl
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.kuvyrkov@linaro.org wrote:
On Mar 26, 2020, at 3:13 PM, Jussi Lind jussi.lind@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 http://releases.linaro.org/components/toolchain/binaries/latest-7/ . 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://www.linaro.org
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-bounces@lists.linaro.org on behalf of Jussi Lind jussi.lind@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-3...
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.kuvyrkov@linaro.org wrote:
On Mar 26, 2020, at 3:13 PM, Jussi Lind jussi.lind@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_comp... . 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=Dw...
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.linaro.org_mailma...
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 apinski@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-bounces@lists.linaro.org on behalf of Jussi Lind jussi.lind@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-3...
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.kuvyrkov@linaro.org wrote:
On Mar 26, 2020, at 3:13 PM, Jussi Lind jussi.lind@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_comp... . 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=Dw...
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.linaro.org_mailma...
Yes, that's the same problem :)
BR, Jussi
On Mon, Mar 30, 2020, 19:39 Andrew Pinski apinski@marvell.com wrote:
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-bounces@lists.linaro.org on behalf of Jussi Lind jussi.lind@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-3...
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.kuvyrkov@linaro.org wrote:
On Mar 26, 2020, at 3:13 PM, Jussi Lind jussi.lind@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_comp... .
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=Dw...
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.linaro.org_mailma...
linaro-toolchain@lists.linaro.org
-
Andrew Pinski -
Jussi Lind -
Maxim Kuvyrkov