- User Since
- Jun 10 2015, 8:17 AM (240 w, 5 d)
Fri, Jan 17
Tue, Jan 14
Is there anything else to do? We (Julia) have been carrying this patch for a while.
move test and rebase
- rebase D50010
Sun, Jan 12
Sun, Dec 22
Dec 21 2019
Dec 18 2019
- reduce test
- update test
Dec 16 2019
Dec 14 2019
Sorry that it took so long for me to finish this.
- update aaccording to comments
Dec 13 2019
Nov 30 2019
- fix AS in anyref testfile
Nov 28 2019
restore previous changes
support old DL modules
Nov 27 2019
Rebased onto current master and added an initial test. (I will start adding more as I start integrating this with the rest of the toolchain)
- add test for passing anyref through a function
- fix wrong name for funcref
- fixes and formatting
- fix error message
Oct 2 2019
- change anyref AS to 256
- fix some comments and address nit
Keno has asked me to take this over for him and I will work on getting this into shape so that it can get landed.
Sep 27 2019
Aug 23 2019
Aug 20 2019
Thanks Martin for the quick response and fix. My minimal test-case works and I am in the progress of testing our full build.
Aug 18 2019
This broke Julia downstream (https://github.com/JuliaLang/julia/pull/32712#issuecomment-521206577). In Julia we emit JIT'ed code on MINGW as ELF+Static relocation model (https://github.com/JuliaLang/julia/blob/be3b04b29654a463b4dc899a228b5f53e862cdde/src/codegen.cpp#L7653-L7669), due us having issues with COFF support in RuntimeDyld.
May 5 2019
Jul 23 2018
It indeed does! Thanks!
Jul 10 2018
Jul 5 2018
Update to current master and consolidate tests
Apr 19 2018
From my side this looks good and it fixes my more complicated test-case in Julia as well.
Superseded by https://reviews.llvm.org/D45819
Apr 4 2018
Apr 3 2018
@nemanjai correctly noted that the both branches are equal and we can simplify this,
by making sure that we don't fall over the iterator and then removing both BB.
Mar 25 2018
Mar 20 2018
Is the x86_64-pc-windows-itanium the right platform triple?
- update for windows-itanium and add tests
Mar 19 2018
Hm I can't reproduce the failure you are seeing. I added your example as a test case and started extending the tests in Codegen/X86/stack-protector.ll to also cover mingw (there still lots of cases to go there).
Start adding test for ssp and sspstrong for mingw32
Thanks! Can you land this for me I don't have the commit bit.
update tests to use FileCheck
@nemanjai I added two test cases the first taken from ARM.addrspacecast.ll and the second from a bug that the Julia frontend hit.
add tests for addrspaces noops on PPC
Mar 17 2018
@mstorsjo Thanks for your feedback. Might I ask how you tested this? Did you simply compiled clang as well and run the testsuite?
Rebase onto master
In the progress of updating the Julia frontend to LLVM 6.0.0 I encountered this issue again.
Julia is using mingw for our windows support and as far as I understand mingw doesn't provide __security_cookie and __security_check_cookie
as part of the runtime (https://sourceforge.net/p/mingw-w64/mailman/message/27235169/). I suspect partly due to the fact that the version of
msvcrt.dll that mingw only has the symbols in an external static library (bufferoverflowU.lib). On the other hand mingw does provide libssp.
Feb 26 2018
Jul 6 2017
@echristo I noticed that you reverted r294702 shortly after it landed. What needs to be done to get it working?
Feb 13 2017
Jan 4 2017
address review comments
SKX: Defensively check for AVX512
@craig.topper should we still have a feature gate for 0x55? SKX is not on the market yet so we can't verify this yet.
Add model id 0x55 as SKX and consolidate 0x4e & 0x5e into SKL
Jan 3 2017
Related issue for clang https://llvm.org/bugs/show_bug.cgi?id=27003 shows that the model id for i5-6200U is also 4e. I also grouped the two Skylake ids together.
groups the model id for skylake and checks for AVX512 to differentiate between SKL and SKX
Jan 2 2017
Dec 11 2016
Dec 9 2016
As far as I know Intel on Windows is capable off handling gnu-style options, but I don't have a test system.
Dec 1 2016
I should also note the mingw64 provides "libssp" so the MSVCRT functions are not needed on this target.
The Julia project is currently evaluating updating LLVM from 3.7 to 3.9 and we are working on making sure that it will continue to work on all supported platforms.
We currently support Windows through Mingw and encountered LLVM ERROR: Program used external function '__atomic_store' which could not be resolved! in JIT'ed code.
So far we did not need MSVCRT as a runtime library with Mingw, greatly simplifying deployment.
Oct 31 2016
Since I am new to LLVM I was wondering what the process of landing this is?
Oct 23 2016
Address review comments