Vale
Vale copied to clipboard
ValeLang
Switch to LLVM 14 and add --pic by default
Clang 14 seems to have a problem with the code generated by the backend if --pic is not specified, so this PR adds it to the default build options and switches to Clang 14 in the Ubuntu installer script. Not sure if it causes problems with older Clang versions, so may need some testing on other OSes (and those installer scripts need updating too).
Fixes issue #521 (although it seems I'm the only one affected by that so far).
Oh, I see from CI that there's more significant changes needed... not sure why it worked locally for me; maybe having Clang 14 in Ubuntu 22.04's apt repo changes things. Guess I'll come back to this on the weekend.
Sounds good, thanks for the work you've been putting into this! I really appreciate it, it's good to have a comrade in this endeavor. If you end up stuck, let me know and I can give it a swing too.
(Also, if you ever swing by the discord server let me know so I can give you the Contributor role!)
Hmm, I think it worked locally for me because I had some combination of LLVM 13 and 14 on my system. Changing to LLVM 14 in CMakeLists.txt now causes test failures to do with type coersions in bitwise and (I guess??):
Printing file /home/omf/code/vale/Vale/Tester/build/testbuild/interfacemutreturnexport_resilient-v3/build.ll
Module verification failed:
Both operands to a binary operator are not of the same type!
%2 = and i256 %1, i32 -1
Both operands to a binary operator are not of the same type!
%6 = and i256 %5, i32 -1
Both operands to a binary operator are not of the same type!
%10 = and i256 %9, i56 -1
Both operands to a binary operator are not of the same type!
%14 = and i256 %13, i52 -1
Both operands to a binary operator are not of the same type!
%18 = and i256 %17, i52 -1
Both operands to a binary operator are not of the same type!
%22 = and i256 %21, i16 -1
Both operands to a binary operator are not of the same type!
%26 = and i256 %25, i16 -1
@Verdagon can you make any sense of it? :sweat_smile:
I also switched the Mac build script to use LLVM 14, but the Windows install script depends on a custom LLVM archive so I'm not sure what to do about that.
Very odd! If we're lucky, it's just clang 14 being more strict than clang 13, and these are legitimate problems in the Vale compiler. I'll clone this PR tomorrow in my Ubuntu VM and take a look. Will keep you posted!
Gave it a shot on a clean Ubuntu VM, and had some very odd experiences.
First, I took out the sudo apt-get install clang from install-compiler-prereqs.sh, to be sure I wasn't mixing and matching any clangs.
Then I tried to instruct CMake to use the clang-14 and clang++ that came with the LLVM 14 download, by changing the line in build-compiler.sh to
cmake -B build -D CMAKE_C_COMPILER="clang-14" -D CMAKE_CXX_COMPILER="clang++" -D LLVM_DIR="$LLVM_CMAKE_DIR"
and prefixing the build-compiler.sh like
PATH=$PATH:/home/valerian/LLVMForVale/clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04/bin ./scripts/ubuntu/build-compiler.sh ~/LLVMForVale/clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04 ~/BootstrappingValeCompiler --test=all ./scripts/VERSION
but then there was an error about how /usr/bin/ld couldn't find libstd++... the clang 14 that comes with LLVM 14 doesn't seem to have one. Pretty shocking actually!
I gave up on that and did sudo apt-get install clang which installed clang version 10 (can't find 14) and got the same outcome you did. Somehow, having both 10 and 14 tricked it into getting further. I suspect the same oddity exists in today's valec, which is slightly worrying.
That's all my time today, but at least I've successfully repro'd the problem, and can look into fixing those weird binary ands on Thursday or Friday.
(BTW, what do you mean "having Clang 14 in Ubuntu 22.04's apt repo"? It looked to me like apt clang doesn't go that high.)
Gave it a shot on a clean Ubuntu VM, and had some very odd experiences.
First, I took out the sudo apt-get install clang from install-compiler-prereqs.sh, to be sure I wasn't mixing and matching any clangs.
Yeah, I should have checked that -- mixing Clangs probably allowed it to work for me locally by chance.
I gave up on that and did
sudo apt-get install clangwhich installed clang version 10 (can't find 14) and got the same outcome you did. Somehow, having both 10 and 14 tricked it into getting further. I suspect the same oddity exists in today's valec, which is slightly worrying.That's all my time today, but at least I've successfully repro'd the problem, and can look into fixing those weird binary ands on Thursday or Friday.
Thanks for looking at it! I'll poke around more on the weekend too.
(BTW, what do you mean "having Clang 14 in Ubuntu 22.04's apt repo"? It looked to me like apt clang doesn't go that high.)
I'm on Pop_OS but it seems to be Clang 14 in the Ubuntu 22.04 repo now.
As Verdagon mentioned on Discord, llvm ships with clang by default, so maybe clang doesn't need to be installed explicitly, but we can instead use the clang that is shipped with the downloaded llvm.
Also, maybe we should avoid downloading llvm manually in the future when Ubuntu (and by extension, Pop_OS!) ships an llvm package already.
But this should be fine for now and is asking for a new PR.
As I mentioned in Discord, given some time on my end, I might start working on a .deb for installing Vale on Ubuntu so that all of this can be automated further by using the package manager and isn't as tedious as using a manual installation script!
This can of course be extended for other platforms, like a PKGBUILD for Arch and maybe even an APKBUILD for Alpine, when we start supporting these.
@Verdagon let me know if I should open an issue for this.
Installing LLVM via apt-get is preferable to the curl command we're doing today. IIRC, we use curl today because clang-13 and llvm-13 weren't available on apt at the time for 20.04.
Github actions just added a 22.04 environment, and it looks like 22.04's apt has clang-14 so perhaps we can finally remove the script's manual installation of LLVM and clang, for linux at least.
might start working on a .deb for installing Vale on Ubuntu
That would be great! A new issue would be best.
As discussed on discord, we probably shouldn't rely on apt to get clang-14, as we want to keep supporting old versions of linux and not require them to upgrade to 22.04. We'll stick with curling for now.
It seems like this requires the bootstrapping valec to already support --pic which it doesn't, so I'm splitting that out into a separate PR https://github.com/ValeLang/Vale/pull/544 and will make a new minor release with just that. That should unblock the rest of this PR which upgrades us to LLVM 14.
@Witcher01 figured out how to install LLVM 14 without curling, so I modified this PR in https://github.com/ValeLang/Vale/pull/543, want to merge those changes into your PR? (Not sure how to contribute to your current in-flight PR directly)
It seems like this requires the bootstrapping valec to already support --pic which it doesn't, so I'm splitting that out into a separate PR #544 and will make a new minor release with just that. That should unblock the rest of this PR which upgrades us to LLVM 14.
@Witcher01 figured out how to install LLVM 14 without
curling, so I modified this PR in #543, want to merge those changes into your PR? (Not sure how to contribute to your current in-flight PR directly)
Good stuff. I haven't updated my branch so happy to pull one PR into d'other. Although it seems that one is based on some of these commits already? Maybe better to close this one and get #543 sorted?
Turns out, we didn't completely add the --pic flag in this PR! But I just fixed that and merged it in in a separate PR (#545). However, it's defaulted to off. I made a new release with it (0.2.0.15)
So, this PR is no longer about adding the --pic flag, it's now about:
- Upgrading to LLVM 14.
- Defaulting --pic to true, and seeing how the CI reacts. It didn't seem to work when I quickly tried it, but I also suspect my cat may have done something to my experimenting when it walked on my keyboard.
I'd prefer if we kept working on your PR, for history reasons. Is there a way you can merge my changes into yours, if they look good to you?
(I'm out of time for today, but I can dive back into this on Tuesday)
Okay, I've pulled the changes from master and fixed one or two small things, but still haven't the faintest clue what to do about the main errors:
Printing file /home/runner/work/Vale/Vale/Tester/build/testbuild/interfacemutreturnexport_resilient-v3/build.ll
Module verification failed:
Both operands to a binary operator are not of the same type!
%2 = and i256 %1, i32 -1
[...]
I'm looking at that build.ll generated code and can see those instructions, but... no idea how it was generated or how the types were selected / derived. Got any tips for where to start?
Exciting times... looks like the last outstanding item is that the Windows build needs a new LLVM build, which I think Verdagon is doing manually ATM. @Verdagon do you think we might be able to use GH actions to sneakily build and publish that LLVM archive as a manually triggered occasional action?
I'm hoping long-term we can just rely on the pre-built ones Zig provides: https://github.com/ziglang/zig/wiki/Building-Zig-on-Windows and they should have LLVM 14 (or 15) within a month or so: https://github.com/ziglang/zig/issues/12534. If we wait a bit, we don't have to go through the process of building (and stripping/minimizing) or automatic an LLVM 14 build 😄
I'm hoping long-term we can just rely on the pre-built ones Zig provides: https://github.com/ziglang/zig/wiki/Building-Zig-on-Windows and they should have LLVM 14 (or 15) within a month or so: ziglang/zig#12534. If we wait a bit, we don't have to go through the process of building (and stripping/minimizing) or automatic an LLVM 14 build :smile:
Sounds like a plan!
Looks like zig bumped their release date to November. I might finish my current focus (generics+regions) by then though, so I might get to this first.
I think I've gotten Windows LLVM 14 to work! I merged this PR into a branch (https://github.com/ValeLang/Vale/tree/LLVM14.0.6) so I could edit it, and then merged some windows fixes into it. New PR (#568) will merge the branch into master.