[jdk8u-dev] RFR: 8342822: jdk8u432-b06 does not compile on AIX [v2]
Francisco Ferrari Bihurriet
fferrari at openjdk.org
Tue Dec 10 00:43:45 UTC 2024
On Thu, 7 Nov 2024 11:40:27 GMT, Varada M <varadam at openjdk.org> wrote:
>> Use of llabs() for jlong resolves the build error on AIX.
>> Performed jtreg testing for hotspot/test on both aix-ppc64 and linux-ppc64le and no related failures observed
>>
>> JBS : [JDK-8342822](https://bugs.openjdk.org/browse/JDK-8342822)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>
> 8342822: jdk8u432-b06 does not compile on AIX
Hi, sorry for my delayed reply, I'm resuming work on this issue.
Here is [the relevant part of the failure log](https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-aix-ppc64-temurin/484/consoleText#:~:text=machnode.cpp-,%5B2024%2D11%2D14T21%3A10%3A24.721Z%5D,Error%201) (from [`jdk8u-aix-ppc64-temurin` Build #484](https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-aix-ppc64-temurin/484/) thanks @jerboaa for pointing me to that Jenkins instance):
[2024-11-14T21:10:24.721Z] "/home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-aix-ppc64-temurin/workspace/build/src/hotspot/src/share/vm/opto/superword.hpp", line 591.26: 1540-0219 (S) The call to "abs" has no best match.
[2024-11-14T21:10:24.721Z] "/home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-aix-ppc64-temurin/workspace/build/src/hotspot/src/share/vm/opto/superword.hpp", line 591.43: 1540-1229 (I) Argument number 1 is an rvalue of type "long".
[2024-11-14T21:10:24.721Z] "/usr/include/math.h", line 1033.20: 1540-1202 (I) No candidate is better than "abs(long double)".
[2024-11-14T21:10:24.721Z] "/home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-aix-ppc64-temurin/workspace/build/src/hotspot/src/share/vm/opto/superword.hpp", line 591.43: 1540-1231 (I) The conversion from argument number 1 to "long double" uses "a floating point-integral conversion".
[2024-11-14T21:10:24.721Z] "/usr/include/math.h", line 1003.14: 1540-1202 (I) No candidate is better than "abs(float)".
[2024-11-14T21:10:24.721Z] "/home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-aix-ppc64-temurin/workspace/build/src/hotspot/src/share/vm/opto/superword.hpp", line 591.43: 1540-1231 (I) The conversion from argument number 1 to "float" uses "a floating point-integral conversion".
[2024-11-14T21:10:24.721Z] "/usr/include/math.h", line 1001.15: 1540-1202 (I) No candidate is better than "abs(double)".
[2024-11-14T21:10:24.721Z] "/home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-aix-ppc64-temurin/workspace/build/src/hotspot/src/share/vm/opto/superword.hpp", line 591.43: 1540-1231 (I) The conversion from argument number 1 to "double" uses "a floating point-integral conversion".
[2024-11-14T21:10:24.721Z] "/usr/include/stdlib.h", line 803.18: 1540-1202 (I) No candidate is better than "abs(int)".
[2024-11-14T21:10:24.721Z] "/home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-aix-ppc64-temurin/workspace/build/src/hotspot/src/share/vm/opto/superword.hpp", line 591.43: 1540-1231 (I) The conversion from argument number 1 to "int" uses "an integral conversion".
[2024-11-14T21:10:24.721Z] gmake[6]: *** [/home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-aix-ppc64-temurin/workspace/build/src/hotspot/make/aix/makefiles/rules.make:151: loopnode.o] Error 1
We are building for _ppc64_, and searching the best candidate for `abs(long)`. The following candidates are considered at an equal-level (so none of them is the "best match"):
* `abs(long double)` from `/usr/include/math.h`, using "a floating point-integral conversion"
* `abs(float)` from `/usr/include/math.h`, using "a floating point-integral conversion"
* `abs(double)` from `/usr/include/math.h`, using "a floating point-integral conversion"
* `abs(int)` from `/usr/include/stdlib.h`, using "an integral conversion"
`xlC` is unable to find the `abs(long)` candidate, which should qualify at the highest level (no argument conversion, so the "best match").
>From @varada1110 [tests](#issuecomment-2487668534), this candidate is available in `cstdlib` (although in that particular case, isn't a "best match" for `unsigned long`):
"/opt/IBM/xlC/13.1.3/include/cstdlib", line 74.15: 1540-1202 (I) No candidate is better than "abs(long)".
Trying to get some external clues, I did a simple _Fedora Linux x86-64_ test with GCC. I found that `std::abs` is used even if we include `stdlib.h` and don't qualify `abs` with the `std::` namespace:
```c++
g++ -pedantic -Wall -xc++ -std=c++11 -op -<<'EOF'
//////////////////////////////////////////////////
#include <iostream>
#include <stdlib.h>
int main() {
long var = -1234567890; // 0xffffffffb669fd2e
std::cout << abs(var) << std::endl;
}
//////////////////////////////////////////////////
EOF
./p
sha256sum p
objdump --insn-width=8 -dC p | grep -A10 'abs|<main>'
rm -f p
Output:
1234567890
3657bd6d3bb686f0dc8e058cce73199bb38b7c20113f3c599a11629577dbb12b p
0000000000401146 <main>:
401146: 55 push %rbp
401147: 48 89 e5 mov %rsp,%rbp
40114a: 48 83 ec 10 sub $0x10,%rsp
40114e: 48 c7 45 f8 2e fd 69 b6 movq $0xffffffffb669fd2e,-0x8(%rbp)
401156: 48 8b 45 f8 mov -0x8(%rbp),%rax
40115a: 48 89 c7 mov %rax,%rdi
40115d: e8 21 00 00 00 call 401183 <std::abs(long)>
401162: 48 89 c6 mov %rax,%rsi
401165: bf 40 40 40 00 mov $0x404040,%edi
40116a: e8 e1 fe ff ff call 401050 <std::ostream::operator<<(long)@plt>
40116f: be 30 10 40 00 mov $0x401030,%esi
401174: 48 89 c7 mov %rax,%rdi
401177: e8 c4 fe ff ff call 401040 <std::ostream::operator<<(std::ostream& (*)(std::ostream&))@plt>
40117c: b8 00 00 00 00 mov $0x0,%eax
401181: c9 leave
401182: c3 ret
0000000000401183 <std::abs(long)>:
401183: 55 push %rbp
401184: 48 89 e5 mov %rsp,%rbp
401187: 48 89 7d f8 mov %rdi,-0x8(%rbp)
40118b: 48 8b 45 f8 mov -0x8(%rbp),%rax
40118f: 48 89 c2 mov %rax,%rdx
401192: 48 f7 da neg %rdx
401195: 48 0f 49 c2 cmovns %rdx,%rax
401199: 5d pop %rbp
40119a: c3 ret
In fact, the following three combinations produce an identical binary:
* `#include <stdlib.h>` / `std::abs(var)`
* `#include <stdlib.h>` / `abs(var)` (the combination in the previous snippet)
* `#include <cstdlib>` / `std::abs(var)`
Apparently, the `#include <cstdlib>` / `abs(var)` combination yields some sort of inlined `abs` (I don't know where it's coming from):
0000000000401146 <main>:
[...]
40114e: 48 c7 45 f8 2e fd 69 b6 movq $0xffffffffb669fd2e,-0x8(%rbp)
401156: 48 8b 45 f8 mov -0x8(%rbp),%rax
40115a: 89 c2 mov %eax,%edx
40115c: f7 da neg %edx
40115e: 0f 49 c2 cmovns %edx,%eax
[...]
I will proceed to get [Temporary test system access](https://github.com/adoptium/infrastructure/blob/master/docs/AccessControl.md#temporary-test-system-access) and continue experimentation in _AIX ppc64_.
Some doubts I plan to clarify are:
1. What are the _AIX ppc64_ results of the equivalent tests I did for _Fedora Linux x86-64_?
2. Assuming I get access to both compiler versions, are there any differences between `xlC` 13.1.3 and `xlC` 16.1.0?
3. Is there a `/opt/IBM/xlC/13.1.3/include/stdlib.h` file?
* What happens if we include that one instead of `/usr/include/stdlib.h`?
* Assuming I get access to both compiler versions, repeat for `/opt/IBM/xlC/16.1.0/include/stdlib.h`
Any other research suggestions or advices are welcome.
-------------
PR Comment: https://git.openjdk.org/jdk8u-dev/pull/600#issuecomment-2529925265
More information about the jdk8u-dev
mailing list