-
-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Power] 1.1.0b5: Large quantities of failing unit tests #1909
Comments
|
My bad, did not see #1905. |
|
Actually the issue in the original report is fixed. But there is now a new issue: |
|
LDC was able to compile itself for the OP of #1904 with #1905 (ppc64 and ppc64le). The signature of |
|
Sorry but could you clarify on what I am supposed to do? |
|
Never mind, I'll try it myself at home using your target triple. |
|
So I did a ; [#uses = 0] [display name = core.math.cos]
define double @_D4core4math3cosFNaNbNiNfeZe(double %x_arg) #0 comdat !dbg !6 {
%x = alloca double, align 8 ; [#uses = 2, size/byte = 8]
store double %x_arg, double* %x, !dbg !12 ; [debug line = 50:10]
call void @llvm.dbg.declare(metadata double* %x, metadata !11, metadata !13), !dbg !12 ; [debug line = 50:10] [debug variable = x]
%1 = load double, double* %x, !dbg !14 ; [#uses = 1] [debug line = 50:43]
%2 = call double @llvm.cos.f64(double %1) #2, !dbg !14 ; [#uses = 1] [debug line = 50:43]
ret double %2, !dbg !14 ; [debug line = 50:43]
}
...
attributes #0 = { "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "target-cpu" "target-features"="+64bit" "unsafe-fp-math"="false" }So no LLVM attributes in the signature itself, and accordingly no error. Can you try to do the same (maybe add |
; [#uses = 0] [display name = core.math.cos]
define double @_D4core4math3cosFNaNbNiNfeZe(double %x_arg) #0 comdat !dbg !6 {
%x = alloca double, align 8 ; [#uses = 2, size/byte = 8]
store double %x_arg, double* %x, !dbg !12 ; [debug line = 50:10]
call void @llvm.dbg.declare(metadata double* %x, metadata !11, metadata !13), !dbg !12 ; [debug line = 50:10] [debug variable = x]
%1 = load double, double* %x, !dbg !14 ; [#uses = 1] [debug line = 50:43]
%2 = call double @llvm.cos.f64(double %1) #2, !dbg !14 ; [#uses = 1] [debug line = 50:43]
ret double %2, !dbg !14 ; [debug line = 50:43]
}
...
attributes #0 = { "unsafe-fp-math"="false" }
attributes #1 = { nounwind readnone }
attributes #2 = { nounwind readnone "unsafe-fp-math"="false" }
attributes #3 = { noinline }And no error was reported. So how exactly did it fail during the build... |
|
And using |
Yes the build does pass, generating an object file in correct format. And if I am not mistaken, this is where the flags to compile |
|
Those aren't the final ones, so checking the Makefile makes sense. You should also omit the |
|
This definitely seems to be an ABI issue, so are you sure the LDC used to compile the runtime is the fixed final one? How did you bootstrap it, i.e., which D host compiler did you use? |
Ah ha, now that I would suspect that I should re-bootstrap then. I am currently using version 1.1.0b3. Do you think I should drop back down to 0.17 and restart again? |
|
Oh yes. :) |
|
Well then, I will be back in about half an hour. |
|
Latest 0.17 has most ABI fixes, but not all, I just cherry-picked some fixes of #1905 into the |
|
Got it. |
|
Wasn't able to install with |
|
Did you do a |
|
I am currently building with 0.17.1, and no error so far - 39%. |
|
Let me close this issue then, it's probably due to the fact that I am bootstrapping using a faulty compiler... Sorry for the trouble. |
|
It would be awesome if you could run the library unittests for us, as we're currently completely in the dark wrt. PPC(64). It doesn't take that long if you have a few CPU cores; the debug ones only take an estimated 5 mins on my quadcore. You'd do that by invoking |
|
Sure thing, I will post the test log once I am done. Also you are welcome to pop me an email so I can provide you with SSH access if need be. |
|
Thank you very much already. The tests in release mode would be |
|
I am currently stuck on |
|
Also |
|
Hmm okay, not looking too good then. Just kill the hanging process ( |
|
Okay, and it goes on, hang on... |
|
Here you are.
|
|
Renamed issue and re-opened. |
|
Very nice, thanks. Unfortunately, it looks as if there's a multitude of issues in Phobos (although |
|
Yes, a Power Mac G5 with POWER4 (I think) derived PowerPC 970FX. |
|
The |
|
Right, give me a minute. |
|
Here you go, https://pastebin.aosc.io/view/efb009ad. |
|
And Phobos isn't big-endian aware (at least not everywhere), e.g., there's this test in OutBuffer buf = new OutBuffer();
"hello"w.copy(buf);
assert(buf.toBytes() == "h\x00e\x00l\x00l\x00o\x00");
|
|
Thanks, but |
|
You are very welcome sir. |
|
Multi-byte Unicode encoding also appears to be wrong (UTF-8 at least), this fails (from assert(lastIndexOfAny(to!string("ÖABCDEFCDEF"), to!string("ö"), 2, CaseSensitive.no) == 0);Edit: Nope, the case-sensitive check works, so it must be the case-insensitiveness (toLower/Upper() failing for big-endian?). |
|
I must admit I was largely ignorant to the state PPC64 altogether – did 1.0 work better (i.e. are these regressions)? In any case, it seems unlikely that we can get much further for this release. @redstar? |
|
The ABI issues were there in 1.0 at least, that's for sure, making the more recent LDC 0.17 versions the only halfway-working ones for Power targets. It's quite astonishing that LDC can build itself, the runtimes and their unittests successfully, but that a lot of tests fails for a seemingly pretty small number of rudimentary issues. Stuff like this certainly doesn't help, and that's in there since forever. |
1.1.0b5 could not be built on PPC64 (PowerMac G5) an "Invalid operand types for ICmp instruction" error.
CFLAGS as follows:
LLVM/Clang info:
Build error:
The text was updated successfully, but these errors were encountered: