[ORC] Preserve order of constructors with same priority #95532
Conversation
Constructors with the same priority should keep their relative order that was specified. This is important for clang-repl with many const variables after commit 05137ec ("[clang-repl] Emit const variables only once").
…)" The test fails on 32-bit ARMv8: https://lab.llvm.org/buildbot/#/builders/154/builds/170 This reverts commit e5d0627.
|
Reverted in edd6f0c because the test fails on 32-bit ARMv8: https://lab.llvm.org/buildbot/#/builders/154/builds/170 It works on 64-bit, I'll need time to investigate... |
|
I'm having some difficulties debugging this issue since I can only get access to AArch64 machines that are either not properly configured to run 32-bit ARM executables or have too old software (CMake, Python, GCC) to even build the latest LLVM. @DavidSpickett any chance you could help here? For a start, it would be really interesting to know what the actual output is, ie if all constructors were run and in which order... |
|
Sure, I'll reproduce it locally. |
|
Some of them are missing but they have empty lines where they should be: |
|
If I revert the change to |
Okay, that was my reading of the buildbot failure, but I couldn't think of a good reason why it should be this way...
Right, and the order matches what I remember seeing on x86, which should mean it's something else. Could you maybe try adding |
|
Same result with that: We do suspect relocations in another recent issue #94994, so it could be that. In that issue the initial value of a variable wasn't being loaded at all. We're not sure of the cause at the moment. |
Thanks for the pointer, this indeed sounds related. What does this mean for this fix? Do you think it's acceptable to open a new issue and mark the test as |
|
Yes, I've opened #95911 and relanded the change with the test marked unsupported. |
|
Thanks! Now I won't get emails though because I'm not anymore the commit author... I'll try to keep an eye on the buildbots manually. |
|
Hey, interesting bug on arm32. I will look into it next week! |
LLVM had a bug where constructors with the same priority would not be stably sorted. This has been fixed upstream by llvm/llvm-project#95532, but to avoid relying on a backport this pass works around the issue: The idea is that we lower the default priority of concerned constructors to make them sort correctly.
LLVM had a bug where constructors with the same priority would not be stably sorted. This has been fixed upstream by llvm/llvm-project#95532, but to avoid relying on a backport this commit works around the issue: The idea is that we lower the default priority of concerned constructors to make them sort correctly.
LLVM had a bug where constructors with the same priority would not be stably sorted. This has been fixed upstream by llvm/llvm-project#95532, but to avoid relying on a backport this commit works around the issue: The idea is that we lower the default priority of concerned constructors to make them sort correctly.
LLVM had a bug where constructors with the same priority would not be stably sorted. This has been fixed upstream by llvm/llvm-project#95532, but to avoid relying on a backport this commit works around the issue: The idea is that we lower the default priority of concerned constructors to make them sort correctly.
LLVM had a bug where constructors with the same priority would not be stably sorted. This has been fixed upstream by llvm/llvm-project#95532, but to avoid relying on a backport this commit works around the issue: The idea is that we lower the default priority of concerned constructors to make them sort correctly.
LLVM had a bug where constructors with the same priority would not be stably sorted. This has been fixed upstream by llvm/llvm-project#95532, but to avoid relying on a backport this commit works around the issue: The idea is that we lower the default priority of concerned constructors to make them sort correctly. (cherry picked from commit 7db43f7)
LLVM had a bug where constructors with the same priority would not be stably sorted. This has been fixed upstream by llvm/llvm-project#95532, but to avoid relying on a backport this commit works around the issue: The idea is that we lower the default priority of concerned constructors to make them sort correctly. (cherry picked from commit 7db43f7)
Constructors with the same priority should keep their relative order that was specified. This is important for
clang-replwith manyconstvariables after commit 05137ec ("[clang-repl] Emit const variables only once").