fortran-lang
fix: windows compilation of hash maps tests and increase stack size avoiding segfaults
This PR addresses #979 and #971 partially.
For intel compiler some dependencies with mvsc need to be managed.
Another problem is the stack memory size limit that needs to be increased for Windows.
cc @R-Goc @zoziha @jvdp1 @perazz
Ideally there would be a way to avoid the issues with the libs, instead of fixing them this way, but it seems to work.
Also this may warrant adding the intel oneapi llvm compiler on windows to the compilers which work, but aren't tested in the readme.
Yes, I agree that ideally this should be managed differently but I'm not aware of a better solution compared to what we found here. It is good that indeed, it enables full compliance on Windows for the tests.
Stack space is supposed to be faster, but is the differrnce in performance really measurable? An alternative might be to combine them: use small wrappers that pass either automatic or explicitly allocated arrays to the actual routines that do the work. But a test to see the performance might be useful.
Op za 3 mei 2025 06:41 schreef jalvesz @.***>:
@.**** commented on this pull request.
In test/CMakeLists.txt https://github.com/fortran-lang/stdlib/pull/988#discussion_r2072325566:
@@ -2,6 +2,14 @@ if (NOT TARGET "test-drive::test-drive") find_package("test-drive" REQUIRED) endif()
+if(WIN32)
- if(CMAKE_Fortran_COMPILER_ID MATCHES "^Intel")
- add_link_options(/Qoption,link,/STACK:8388608)
That's on my personal laptop, it has a smaller memory compared to a proper workstation.
— Reply to this email directly, view it on GitHub https://github.com/fortran-lang/stdlib/pull/988#discussion_r2072325566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN6YR46IQDLFV3NWLNI2AT24RJIHAVCNFSM6AAAAAB34BLDLSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDQMJTGE3DCNJVHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Just making it an allocatable should be fine. Even just holding a smaller array and refilling it should work. Holding a big array of random values is a rather weird thing to do.
Tried with the open maps test to make it allocatable but it's still overflowing the stack.
I believe that this could be merged first with the increased stack size, and then the tests could be investigated more deeply. Increasing stack size is not really bad practice. It being so tiny on windows is for legacy reasons. I don't really see a reason why it needs to be so small on 64bit architectures. This also isn't actually committed memory but reserved memory.
Also: it would be worthwhile to check whether the test programs are run with OpenMP turned on, as it it known that stdlib is still not 100% thread-safe
The following 5 tests fail with ifx25+/Qopenmp (Windows), without it all tests pass.
Failing tests with OpenMP
The following tests FAILED:
12 - chaining_maps (Failed)
13 - open_maps (Failed)
14 - maps (SEGFAULT)
22 - open (Failed)
43 - sorting (SEGFAULT)
ctest --test-dir build/test --rerun-failed --output-on-failure
Internal ctest changing into directory: D:/github/fortran-lang/stdlib/build/test
Test project D:/github/fortran-lang/stdlib/build/test
Start 12: chaining_maps
1/5 Test #12: chaining_maps ....................***Failed 0.10 sec
KEY not found in map KEY_TEST.
Start 13: open_maps
2/5 Test #13: open_maps ........................***Failed 0.09 sec
KEY not found in map KEY_TEST.
Start 14: maps
3/5 Test #14: maps .............................***Exception: SegFault 0.05 sec
# Testing: stdlib-open-maps
Starting open-maps-seeded_nmhash32x_hasher-256-byte-words ... (9/12)
Starting open-maps-seeded_water_hasher-256-byte-words ... (11/12)
Starting open-maps-fnv_1a_hasher-256-byte-words ... (5/12)
Starting open-maps-seeded_nmhash32_hasher-16-byte-words ... (6/12)
Starting open-maps-fnv_1a_hasher-16-byte-words ... (4/12)
Starting open-maps-seeded_nmhash32_hasher-256-byte-words ... (7/12)
Starting open-maps-fnv_1_hasher-16-byte-words ... (1/12)
Starting open-maps-seeded_water_hasher-16-byte-words ... (10/12)
Starting open-maps-fnv_1_hasher-16-byte-words ... (2/12)
Starting open-maps-fnv_1_hasher-256-byte-words ... (3/12)
Starting open-maps-seeded_nmhash32x_hasher-16-byte-words ... (8/12)
Starting open-maps-removal-spec ... (12/12)
... open-maps-removal-spec [PASSED]
Start 22: open
4/5 Test #22: open .............................***Failed 0.07 sec
# Testing: open
Starting io_read_write_text ... (1/3)
Starting io_open_error_flag ... (3/3)
Starting io_read_write_stream ... (2/3)
forrtl: Le processus ne peut pas acc der au fichier car ce fichier est utilis par un autre processus.
... io_read_write_text [PASSED]
... io_read_write_stream [PASSED]
forrtl: severe (30): open failure, unit -131, file D:\github\fortran-lang\stdlib\build\test\io\io_open.stream
Image PC Routine Line Source
test_open.exe 00007FF679EC8591 Unknown Unknown Unknown
test_open.exe 00007FF679E8E2FF Unknown Unknown Unknown
test_open.exe 00007FF679E728BF Unknown Unknown Unknown
test_open.exe 00007FF679E9FD71 Unknown Unknown Unknown
test_open.exe 00007FF679EA82F3 Unknown Unknown Unknown
libiomp5md.dll 00007FFBCFD149B3 Unknown Unknown Unknown
libiomp5md.dll 00007FFBCFC5C384 Unknown Unknown Unknown
libiomp5md.dll 00007FFBCFC5B7D5 Unknown Unknown Unknown
libiomp5md.dll 00007FFBCFCBAC51 Unknown Unknown Unknown
KERNEL32.DLL 00007FFC503E259D Unknown Unknown Unknown
ntdll.dll 00007FFC5150AF38 Unknown Unknown Unknown
Start 43: sorting
5/5 Test #43: sorting ..........................***Exception: SegFault 0.05 sec
# Testing: sorting
Starting bitset_large_sorts ... (10/22)
Starting char_ord_sorts ... (1/22)
Starting int_sorts ... (7/22)
Starting bitset_large_ord_sorts ... (3/22)
Starting bitset_64_sorts ... (11/22)
Starting int_sort_indexes_default ... (12/22)
Starting int_radix_sorts ... (5/22)
Starting string_sorts ... (9/22)
Starting bitset_large_sort_indexes_default ... (15/22)
Starting char_sort_indexes_default ... (13/22)
Starting string_ord_sorts ... (2/22)
Starting real_radix_sorts ... (6/22)
Starting char_sorts ... (8/22)
Starting string_sort_indexes_default ... (14/22)
Starting bitset_64_ord_sorts ... (4/22)
Starting bitset_64_sort_indexes_default ... (16/22)
reverse + work ORD_SORT did not sort Bitset Decrease.
SORT did not sort Bitset Decrease.
i = 512
i = 1
bitset64_dummy(i-1:i) = 0000000000000000000000000000000000000000000000000000111000000000 0000000000000000000000000000000000000000000000000000110111111111
bitset64_dummy(i-1:i) = 0000000000000000000000000000000000000000000000000000111111111111 0000000000000000000000000000000000000000000000000000111111111110
Starting int_sort_indexes_low ... (17/22)
Starting string_sort_indexes_low ... (19/22)
Starting bitset_large_sort_indexes_low ... (20/22)
Starting bitset_64_sort_indexes_low ... (21/22)
Starting char_sort_indexes_low ... (18/22)
Starting int_ord_sorts ... (22/22)
reverse ORD_SORT did not sort Bitset Decrease.
i = 1280
bitset64_dummy(i-1:i) = 0000000000000000000000000000000000000000000000000000000100000000 0000000000000000000000000000000000000000000000000000000011111111
reverse SORT did not sort Bitset Decrease.
... bitset_64_ord_sorts [FAILED]
Message: Condition not fullfilled
SORT_INDEX did not sort Bitset Decrease.
i = 1276
i = 1277
bitsetl_dummy(i-1:i) = 0000000000000000000000000000000000000000000000000000101100000011
I think this PR can (should) be merged soon. It does not try to fix problems with thread safety but simply enabling running the test suit with ifx under Windows, which otherwise can't be even compiled. Also, the stack issue affects both intel and gnu compilers.
I'll merge this one to fix the issues with the tests on windows. If we find a better way to resolve stack problems we can remove the stack flags latter on.