RFR: 7904115: Fix for AIX test case failures due to incorrect alignment for double and pointer [v2]

[Maurizio Cimadamore]

On Fri, 21 Nov 2025 12:57:39 GMT, Varada M <varadam at openjdk.org> wrote:

>> Total of 10 test failures observed on AIX:
>> jtreg/generator/nestedTypes/TestNestedTypesUnsupported.java 
>> jtreg/generator/test8246400/LibTest8246400Test.java 
>> jtreg/generator/test8258605/LibTest8258605Test.java 
>> jtreg/generator/test8261511/Test8261511.java 
>> jtreg/generator/testStruct/LibStructTest.java 
>> testng/org/openjdk/jextract/test/toolprovider/ConstantsTest.java 
>> testng/org/openjdk/jextract/test/toolprovider/IncompleteArrayTest.java 
>> testng/org/openjdk/jextract/test/toolprovider/Test8240811.java 
>> testng/org/openjdk/jextract/test/toolprovider/TestClassGeneration.java 
>> testng/org/openjdk/jextract/test/toolprovider/nestedAnonOffset/TestNestedAnonOffset.java
>> 
>> This PR fixes AIX specific layout generation issues related to incorrect alignment double and pointer types.
>> 1. Structs containing double fields fail with:
>>     i. Unsupported layout: 4%D8
>>     ii. Invalid alignment constraint for member layout
>>     double in AIX structs has size 8 but alignment 4 (except as first field). AIX specific handling for C_DOUBLE computes the     correct alignment.
>> 
>> 2. Clang was detected as 32-bit due to missing -m64 during macro extraction, causing inconsistent macros. This caused jextract to interpret pointer constants incorrectly, leading to failures like:
>> expected [-1] but found [4294967295]
>> 
>> 3. TestNestedAnonOffset.java test failed on AIX because it also expects more padding similar to platforms like windows and linux
>> 
>> 
>> After the patch jtreg tests passes successfully.
>> 
>> JBS: [CODETOOLS-7904115](https://bugs.openjdk.org/browse/CODETOOLS-7904115)
>
> Varada M has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addition of  -m64 at right place
>  - addition of  -m64 at right place

My 0.02$ on this issue.

Jextract code (perhaps incorrectly) hardwrires the expected alignment for common C types. Let's ignore the fact that it's hardwired...

The main reason we do this is to avoid redundant call to `align`. Not because it would be inefficient, but simply because it will make layouts unreadable.

So, we do:


case Double -> alignIfNeeded(runtimeHelperName() + ".C_DOUBLE", 8, align);


And then:


   private String alignIfNeeded(String layoutPrefix, long align, long expectedAlign) {
        return align > expectedAlign ?
                String.format("%1$s.align(%2$s, %3$d)", runtimeHelperName(), layoutPrefix, expectedAlign) :
                layoutPrefix;
    }
```    

What this means is: if the _expected_ alignment requirement is _bigger_ than the alignment of the primitive type, we can safely skip the call to `align` (most of the times). Which means we only need to call `align` when we're trying to, say, put an `int` field in a 2-byte aligned offset -- this will lead to an exception when building the layout, so we need to properly align the layout (to 2 bytes).

Now, given the fuzzy nature of double alignment on AIX, perhaps it would be best to skip this "optimization" at least for doubles. That is, we could simply do:


case Double -> alignIfNeeded(runtimeHelperName() + ".C_DOUBLE", IS_AIX ? Long.MAX_VALUE : 8, align);


What this will do is it will pass a very big intrinsic layout alignment for `double`. This alignment will always be bigger than whatever jextract wants, which means a call to `align` will always be emitted. This seems the path of least resistance?

-------------

PR Comment: https://git.openjdk.org/jextract/pull/296#issuecomment-3563909130