ppc64le compilation failure in Alpine for swi-prolog 8.5.0

[brebs-gh]

Hi, the compilation log for ppc64le (aka ppc64el in Debian) shows failure:

/builds/ktprograms/aports/testing/swi-prolog/src/swipl-8.5.0/src/os/../pl-inline.h: In function 'valBignum___LD':
/builds/ktprograms/aports/testing/swi-prolog/src/swipl-8.5.0/src/os/../pl-inline.h:448:2: error: #error "Unsupported int64_t alignment conversion"
  448 | #error "Unsupported int64_t alignment conversion"

[JanWielemaker]

Thanks. A search through the compilation log shows this CMake output

-- Check alignment of INT64_T: 
-- Check alignment of DOUBLE: 8
-- Check alignment of VOIDP: 8

There should be a number (most probably 8) behind the INT64_T :cry: So, the real problem is probably in cmake/AlignOf.cmake. By far the simplest to figure this out would be interactive access to this platform. Is there a simple way?

[ktprograms]

@JanWielemaker This patch seems to fix it. For some reason gcc on ppc64le has a N (literal ascii N) right before the INT64_ALIGNMENT=8 so the regex of ^INT64_ALIGNMENT=(1|4|8|16|32|64) doesn't match.

Patch:

--- a/cmake/AlignOf.cmake
+++ b/cmake/AlignOf.cmake
@@ -16,13 +16,13 @@ function(alignof VAR_ALIGNOF_INT64_T VAR

          # Read patterns from compiled executable
          FILE(STRINGS ${alignof_checker_target} alignof_int64_pat
-            REGEX "^INT64_ALIGNMENT=${alignof_pat_regex}" LIMIT_COUNT 1)
+            REGEX "INT64_ALIGNMENT=${alignof_pat_regex}" LIMIT_COUNT 1)

          FILE(STRINGS ${alignof_checker_target} alignof_voidp_pat
-            REGEX "^VOIDP_ALIGNMENT=${alignof_pat_regex}" LIMIT_COUNT 1)
+            REGEX "VOIDP_ALIGNMENT=${alignof_pat_regex}" LIMIT_COUNT 1)

          FILE(STRINGS ${alignof_checker_target} alignof_double_pat
-            REGEX "^DOUBLE_ALIGNMENT=${alignof_pat_regex}" LIMIT_COUNT 1)
+            REGEX "DOUBLE_ALIGNMENT=${alignof_pat_regex}" LIMIT_COUNT 1)

          # Extract alignments from patterns and assign them to the variables
          string(REGEX MATCH "${alignof_pat_regex}$" int64_alignment "${alignof_int64_pat}")

[ktprograms]

By far the simplest to figure this out would be interactive access to this platform. Is there a simple way?

In this case I was able to reproduce it with QEMU user mode emulation in a chroot

[JanWielemaker]

Thanks. Wondering whether that is not dangerously ambiguous? Would ^N? also work? Just tested on amd64, where it works fine. Pushed SWI-Prolog/swipl-devel@df1f0bf795a16edd313a2a25f0678ce044a4a71d. Could you test this?

[ktprograms]

@JanWielemaker I think the problem isn't the N? but that the regex is matching ^. I don't think it's ambiguous since that's the only place with INT64_ALIGNMENT in the entire binary.

[JanWielemaker]

Thanks. You are right. I'll simply drop the ^.

[ktprograms]

... @JanWielemaker wasn't that exactly my patch? 😂

So when will it be in a SWI-Prolog release? Or should I apply the patch in the alpine build process for now?

[JanWielemaker]

Indeed :smile:

So when will it be in a SWI-Prolog release?

I'm planning to release 8.5.1 today. Hope not too much gets in between ...

[JanWielemaker]

I think that only leaves the crash on s390x open on Debian. See my comment at https://github.com/SWI-Prolog/issues/issues/103#issuecomment-950939508. Do you happen to have the setup ready to look at that? I'm asking too much ...

Qemu is slow. You only have to build the core to re-run this failing test though. Probably even without GMP (though I'm not sure about that).

[ktprograms]

I think that only leaves the crash on s390x open on Debian.

Don't you mean Alpine?

And yes, I'll try and reproduce the test later today.

[JanWielemaker]

Don't you mean Alpine?

Yes. So it could be a C library difference. I still suspect a C stack overflow though. A few tests use a lot of C-stack (eventually that should be fixed :cry:). If this runs out, the question is whether the C stack is lower than usual, the S390x somehow uses more stack that other platforms or there is a real bug with infinite recursion. The last would need a fix (but is IMHO least likely). The other two either require reducing the test or increasing the stack limit for running the tests.

And yes, I'll try and reproduce the test later today.

Thanks!

[JanWielemaker]

This issue has been mentioned on SWI-Prolog. There might be relevant details there:

https://swi-prolog.discourse.group/t/ann-swi-prolog-8-5-1/4595/1

[JanWielemaker]

This issue has been mentioned on SWI-Prolog. There might be relevant details there:

https://swi-prolog.discourse.group/t/ann-swi-prolog-8-4-1-stable/4661/1

[brebs-gh]

All done, closing issue.

[JanWielemaker]

This issue has been mentioned on SWI-Prolog. There might be relevant details there:

https://swi-prolog.discourse.group/t/ann-swi-prolog-9-0-0/5963/1