Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

0.5.0 broken on AArch64 with GFortran #44

Open
sheepforce opened this issue Sep 9, 2024 · 4 comments
Open

0.5.0 broken on AArch64 with GFortran #44

sheepforce opened this issue Sep 9, 2024 · 4 comments

Comments

@sheepforce
Copy link

The latest 0.5.0 release broke the builds on AArch64 machines with GFortran, I assume somehow by the changes from #21 . Here is an attached build log with compiler and library versions as well as the error itself:
testdrive.txt

The important part:

test-drive-aarch64-unknown-linux-gnu> FAILED: libtest-drive.so.0.5.0.p/src_testdrive.F90.o libtest-drive.so.0.5.0.p/testdrive.mod
test-drive-aarch64-unknown-linux-gnu> aarch64-unknown-linux-gnu-gfortran -Ilibtest-drive.so.0.5.0.p -I. -I.. -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -ffree-line-length-none -fbacktrace -DWITH_QP=1 -DWITH_XDP=1 -fPIC -Jlibtest-drive.so.0.5.0.p -o libtest-drive.so.0.5.0.p/src_testdrive.F90.o -c ../src/testdrive.F90
test-drive-aarch64-unknown-linux-gnu> ../src/testdrive.F90:1257:42:
test-drive-aarch64-unknown-linux-gnu>  1257 |   subroutine check_complex_exceptional_xdp(error, actual, message, more)
test-drive-aarch64-unknown-linux-gnu>       |                                          1
test-drive-aarch64-unknown-linux-gnu> ......
test-drive-aarch64-unknown-linux-gnu>  1354 |   subroutine check_complex_exceptional_qp(error, actual, message, more)
test-drive-aarch64-unknown-linux-gnu>       |                                         2
test-drive-aarch64-unknown-linux-gnu> Error: Ambiguous interfaces in generic interface 'check' for 'check_complex_exceptional_xdp' at (1) and 'check_complex_exceptional_qp' at (2)
test-drive-aarch64-unknown-linux-gnu> ../src/testdrive.F90:1965:2:
test-drive-aarch64-unknown-linux-gnu>  1965 |   elemental function is_nan_xdp(val) result(is_nan)
test-drive-aarch64-unknown-linux-gnu>       |  1
test-drive-aarch64-unknown-linux-gnu> ......
test-drive-aarch64-unknown-linux-gnu>  1977 |   elemental function is_nan_qp(val) result(is_nan)
test-drive-aarch64-unknown-linux-gnu>       |  2
test-drive-aarch64-unknown-linux-gnu> Error: Ambiguous interfaces in generic interface 'is_nan' for 'is_nan_xdp' at (1) and 'is_nan_qp' at (2)
test-drive-aarch64-unknown-linux-gnu> ../src/testdrive.F90:1886:2:
test-drive-aarch64-unknown-linux-gnu>  1886 |   pure function complex_xdp_to_string(val) result(string)
test-drive-aarch64-unknown-linux-gnu>       |  1
test-drive-aarch64-unknown-linux-gnu> ......
test-drive-aarch64-unknown-linux-gnu>  1897 |   pure function complex_qp_to_string(val) result(string)
test-drive-aarch64-unknown-linux-gnu>       |  2
test-drive-aarch64-unknown-linux-gnu> Error: Ambiguous interfaces in generic interface 'to_string' for 'complex_xdp_to_string' at (1) and 'complex_qp_to_string' at (2)
test-drive-aarch64-unknown-linux-gnu> ninja: build stopped: subcommand failed.
@awvwgk
Copy link
Member

awvwgk commented Sep 9, 2024

This seems to be an issue with using extended double and quadruple precision detection on aarch64. Can you check whether building with -Dxdp=disabled in meson or -DWITH_XDP=off in CMake the build is passing?

@sheepforce
Copy link
Author

Yes, -Dxdp=disabled indeed fixes the problem on AArch64 and cross compilation! 👍

@awvwgk
Copy link
Member

awvwgk commented Sep 9, 2024

I believe the issue is due to cross compilation, in this case we cannot easily check whether support is available by compiling and running a test program, instead those options should be defined with the cross compilation environment.

One solution from the test-drive side could be to disable the features in case of cross compilation.

@sheepforce
Copy link
Author

No its not an issue of cross compilation, also does not work on our native AArch64 CI builders. I was just able to reproduce the issue with cross compilation and tested with it initially :)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants