Re: [Mingw-w64-public] [PATCH 3/3] crt: testcases: Waive issues with t_aligned_alloc on aarch64

[Martin Storsjö]

On Wed, 25 Jun 2025, Pali Rohár wrote:

On Wednesday 25 June 2025 11:08:57 Martin Storsjö wrote:
Both for UCRT and for msvcrt.dll, we end up calling the CRT DLL
provided functions directly, so these issues are outside of our
own emulation wrappers.
Just waive the test for these configurations.

Signed-off-by: Martin Storsjö <mar...@martin.st>
---
 mingw-w64-crt/testcases/t_aligned_alloc.c | 30 ++++++++++++++++++-----
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/mingw-w64-crt/testcases/t_aligned_alloc.c 
b/mingw-w64-crt/testcases/t_aligned_alloc.c
index 1e4cbdea2..d80a3d318 100644
--- a/mingw-w64-crt/testcases/t_aligned_alloc.c
+++ b/mingw-w64-crt/testcases/t_aligned_alloc.c
@@ -25,6 +25,18 @@
   } \
 } while (0)

+#ifndef BROKEN_REALLOC_SHRINK
+#if defined(__aarch64__)
+/* On aarch64, both UCRT and msvcrt.dll, a _aligned_realloc that attempts to
+ * shrink the allocation, ends up not shrinking it in practice, leading to
+ * failures in some of these tests. Ignore those test failures. This is
+ * observed on both Windows 10 rev 19041 and Windows 11 rev 22000 and 22631. */
+#define BROKEN_REALLOC_SHRINK 1
+#else
+#define BROKEN_REALLOC_SHRINK 0
+#endif
+#endif
+
 int main() {
   void *ptr;
   size_t size;
@@ -94,17 +106,20 @@ int main() {
   TEST((uintptr_t)ptr % 128, 0, "_aligned_realloc: ptr 0x%p is not aligned", 
ptr);

   size = _aligned_msize(ptr, 128, 0);
-  TEST(size, 10, "_aligned_msize: ptr 0x%p has incorrect size %lu", ptr, 
(unsigned long)size);
+  if (!BROKEN_REALLOC_SHRINK)
+    TEST(size, 10, "_aligned_msize: ptr 0x%p has incorrect size %lu", ptr, 
(unsigned long)size);

   ptr = _aligned_recalloc(ptr, 20, 1, 128);
   assert(ptr != NULL);
   TEST((uintptr_t)ptr % 128, 0, "_aligned_recalloc: ptr 0x%p is not aligned", 
ptr);

   size = _aligned_msize(ptr, 128, 0);
-  TEST(size, 20, "_aligned_msize: ptr 0x%p has incorrect size %lu", ptr, 
(unsigned long)size);
+  if (!BROKEN_REALLOC_SHRINK)
+    TEST(size, 20, "_aligned_msize: ptr 0x%p has incorrect size %lu", ptr, 
(unsigned long)size);

   TEST_MEM(ptr, 0x02, 10, "_aligned_realloc: 0x%p has incorrect byte 0x%02x at 
%lu", ptr, ((unsigned char *)ptr)[i], (unsigned long)i);

Not related to your change. But now I spotted typo in the above TEST_MEM
message. There is "_aligned_realloc", but it should be "_aligned_recalloc"
(missing "c").

Ok, I can make a commit to fix that and push along with other changes.

-  TEST_MEM(ptr+10, 0x00, 10, "_aligned_recalloc: 0x%p has incorrect byte 0x%02x at 
%lu", ptr, ((unsigned char *)ptr)[i+10], (unsigned long)i+10);
+  if (!BROKEN_REALLOC_SHRINK)
+    TEST_MEM(ptr+10, 0x00, 10, "_aligned_recalloc: 0x%p has incorrect byte 0x%02x 
at %lu", ptr, ((unsigned char *)ptr)[i+10], (unsigned long)i+10);

Why is this test also skipped? Does it mean that _aligned_recalloc does
not fill zero bytes as "c"alloc is suppose to do?

I think it does fill with zeros, when it actually ends up expanding for 
real.

But first we allocate 128, then we shrink it to 10, then we expand to 20. 
As the realloc/recalloc to shrink it to 10 actually doesn't seem to shrink 
it (but keeps the size as 128) due to this issue, it means that the 
recalloc to expand from 10 to 20 doesn't zero the range [10,20] either, 
since the allocation at this time is 128, not 10.

So with _aligned_recalloc, it seems like this issue really could cause 
trouble for potential users. Not to the point that I think we should try 
to work around it in mingw-w64-crt, but perhaps we should file it as a bug 
to MS.

// Martin

_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public