Please test 1.0.0-beta1

[elliottslaughter]

CCing people who have been active recently or who have contributed to the recent release: @viluon @bananu7 @OvermindDL1 @Mx7f @ProfFan @Clyybber

I've put together a beta for the upcoming 1.0 release. If you have the time, please download it and make sure it is working. I'm particularly looking for someone to test the Windows build.

• Binaries: https://github.com/zdevito/terra/releases/tag/release-1.0.0-beta1
• Release notes: https://github.com/zdevito/terra/blob/master/CHANGES.md

If no major issues are found I'll release this as 1.0.

Test matrix for release:

Test/OS	Linux	OSX	Windows
Test Suite w/o CUDA	✅ (Travis)	✅ (Travis)	✅ (AppVeyor)
Test Suite with CUDA	✅ (@elliottslaughter)	✅ (@ProfFan)
Rigel	✅ (@elliottslaughter)
Opt		✅ (@ProfFan)
Regent	✅ (@elliottslaughter)	✅ (@elliottslaughter)	N/A

Other todo items:

• Update documentation to include labels (was: New Terra release) #173 (document label([name]) and and for multiple functions)
• defer is not documented #154 (document defer)
• Please test 1.0.0-beta1 #323 (comment) (CUDA slowdown)
• Please document __for (and question about iterators) #333 (document __for)
• Expose checkreturns() from terralib #339 (document lex:terraexpr() and lex:terrastats())
• RFC: Deprecate Makefile build #383 (deprecate Make)
• RFC: Deprecate NMake build on Windows #403 (deprecate NMake)
• Problems testing terra[ Release 1.0.0-beta1 ] #366 (portability of Linux binaries)

Optional:

• Support Holy Build Box #388 (holy build box)

[elliottslaughter]

Note: Linux/Mac binaries are still coming, so check back in a bit if you don't see them yet.

[OvermindDL1]

523 tests passed. 0 tests failed.

Test run on linux.

My simple sandbox code seems to work fine too but it doesn't really stress much. :-)

[OvermindDL1]

Was looking through the docs to see if I could test something that might break and found a doc bug. On http://terralang.org/api.html#function the func:printpretty([quote_per_line=true]) example, I think it should be func:printpretty({quote_per_line=true}) instead since a quote is not valid at the top level there (or with that internal syntax I think). Do you want a new issue for this?

[elliottslaughter]

I think that's just saying that the argument is optional, and has a default value of true? (See e.g. http://terralang.org/api.html#symbol) I agree that it's confusing though, since both [] and {} are valid syntax in the language!

If you have ideas for how to make it more clear, please create a new issue---I think this will be pretty pervasive in the docs so it won't be a quick and simple change.

[ProfFan]

We could probably have a matrix of test conditions here and check them all. Also, I think it is nice to have dependent projects like Darkroom and Opt added to the test matrix.
Probably like

Test/OS	Linux	OSX	Windows
Test Suite w/o CUDA
Test Suite with CUDA
Darkroom
Opt
etc.

[elliottslaughter]

@ProfFan Ok, I copied your test matrix into the issue description up top.

Would you be willing to test Opt?

Also, do you know any contacts for Darkroom? I'm all in favor of having everyone test this, but I'm not going to know how to run their tests myself.

[elliottslaughter]

FYI, I noticed an issue where the macOS binary that got uploaded did not have CUDA enabled (due to a bug in a condition on Travis). I've renamed that binary, and re-run the correct Travis job, so the new binary should have CUDA enabled.

[bananu7]

I'm particularly looking for someone to test the Windows build.

Well, I tried. Namely:

terra-Windows-x86_64-2e2032e\share\terra\tests $ ..\..\..\bin\terra run
terra-Windows-x86_64-2e2032e\bin $ terra ..\share\terra\tests\run

And copying the terra binary to the tests folder and running from there (neither method is in the README, which I think doesn't correspond to the zip folder structure). Only the first one sort of went through, producing a lot of:

ERROR: The system was unable to find the specified registry or key value.

In the end:

 453 tests passed. 70 tests failed.

But quickly looking at the log, a good chunk of the fails was due to the fact that stdio.h wasn't found; not all of them, though, e.g. defergoto.t didn't typecheck.

I've tried numerous standard library headers, including GCC (doesn't compile), MSVS (LLVM says that code isn't executable), and libcxx (fails to find stdio.h again at #include_next).

Here's the full test log.

[bananu7]

And oh, Darkroom tests seem to be failing because of the same issue.

[ProfFan]

@elliottslaughter I will test Opt on macOS and Linux in a few days.

[Clyybber]

@bananu7 I think darkroom relies on platform specific things, such as pthreads:
cpthread = terralib.includec("pthread.h")
https://github.com/jameshegarty/darkroom/blob/master/src/backend_terra.t

Darkroom and Terra are tested to work on Linux and Mac OS X. Other platforms are unlikely to work.

[bananu7]

@Clyybber Would be worth a try to test it with MinGW pthread, but I didn't even get to that point anyway.

[OvermindDL1]

I grabbed a Windows 10 machine at work that has cygwin and the visual studio tools and a lot of other dev stuff that no one uses here anymore and the best I was able to get the tests to do was 453 tests passed. 70 tests failed, though it won't really affect me as I don't use Windows. None of my tests include cuda either as I use OpenCL and Vulkan rather than Cuda (yay standards).

Full failing list:

=================
= FAILING tests
=================
ainline.t
arrayt.t
atoi.t
avxhadd.t
benchmark_fannkuchredux.t
benchmark_nbody.t
bf.t
blocking.t
blocking2-fixed.t
blocking2.t
blocking3.t
bounce.t
breaktest.t
bug2.t
bug4.t
cconv.t
clanginfo.t
class.t
class2.t
class3.t
class5.t
class6.t
clean.t
defer.t
deferbreak.t
defergoto.t
dgemm.t
dgemm2.t
dgemm3.t
diffuse.t
dynlib.t
exportdynamic.t
fakeasm.t
gemm.t
hello.t
hello2.t
includec.t
luaapi.t
malloc.t
mathlib.t
multiterra.t
new.t
objtest.t
option_e.t
output.t
printfarray.t
printfloat.t
proxystruct.t
quote7.t
quote8.t
quote9.t
quoteselect.t
recstruct.t
renaming.t
scc.t
sgemm-old.t
sgemm.t
sgemm3.t
sgemmkernel.t
sharedlib.t
speed.t
ssimple.t
stencil.t
strerror.t
string.t
symbolmangling.t
testminmax.t
teststd.t
testvector.t
varargcstring.t
=================

453 tests passed. 70 tests failed.

I tested gcc and linking with some simple C/C++ programs that used some standard headers with no issue, and likewise with the VC tools and nmake'ing a simple project. Note that it is the Visual Studio compiler that is installed, not the full IDE, but the entire compiler pipeline and VS headers and all are installed.

[OvermindDL1]

I can test something else out if needed as well. If needing of anything 'too' windows specific I may need help with as I'm a linux user, not a Windows user, and thus I don't know Windows quite perfectly, but I do have a bash shell and all the VS and cygwin tools available.

For note, the failing tests had a LOT of ERROR: The system was unable to find the specified registry key or value when they were running, which seems questionable... (why is the registry being accessed?)

[elliottslaughter]

@bananu7 @OvermindDL1 For your Windows tests, what Windows and Visual Studio versions do you have installed?

Probably what's happening is we're hitting these lines:

https://github.com/zdevito/terra/blob/master/src/terralib.lua#L4068-L4069

The binaries are built with Visual 2015, but those values are hard-coded to expect 2013. However, when I tried to remove those and/or reorder them with respect to the Clang paths, I started to get some failing tests on AppVeyor. But it may still be possible to make this work better than it currently is.

[bananu7]

-- this is the reason we can't have nice things

Oh wow. This is seriously sketchy. Should be definitely taken from an environment variable or similar. I'm at home now with pretty much all VS versions installed, so giving it a try again.

On second thoughts, why can't those headers be bundled together with Terra? Is there some licensing issue there?

[bananu7]

OK, so the results from my machine are in:

455 tests passed. 68 tests failed.

Seems that the include situation isn't really much better:

In file included from <buffer>:1:
In file included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC/INCLUDE\stdio.h:20:
C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/INCLUDE\crtdefs.h:10:10: fatal error: 'corecrt.h' file not found
#include <corecrt.h>
         ^~~~~~~~~~~

I have no idea why it's using the 12.0 stdio.h and then trying to include 14.0 corecrt.h. I suppose it might have something to do with the fact I have both installed...

[bananu7]

I'm pretty sure that this is the problematic part.

The fact that it, sort of maliciously, inserts the 14.0 path can be observed by running clanginfo.t test.

And indeed, disabling (temporarily changing the name of the folder) the 14.0 includes makes it work - all tests pass. 😄

[Mx7f]

This was the relevant pull request: #315, you can see why that part was added (or rather, rearranged) in there. I hadn't gotten the bandwidth to figure out how fix it properly.

[elliottslaughter]

@bananu7 I'd love to accept a pull request for this. As you can see in the discussion of #315, I spent some time trying to figure out how to fix it, but debugging via AppVeyor builds is about the slowest debugging cycle you can possibly imagine, and I eventually gave up on it. Someone with a working Visual Studio install could probably iterate a lot faster.

I see two possible options:

1. Rely entirely on Clang, since we've got a lot of duplication of the paths we can probably just remove our versions of them. Presumably if we're not setting up bad paths in the code I linked above, then the Clang paths will just be used if we put the code back where it was originally. (I.e. Clang paths no longer need to be forced to come first.)
2. Fix the auto-detection of the registry keys so that we can find the correct paths ourselves, and then we can put the Clang paths back into their normal place.

[OvermindDL1]

@OvermindDL1 For your Windows tests, what Windows and Visual Studio versions do you have installed?

2017 I think I remembered seeing? Whatever was the latest available toolset earlier this year most likely.

On second thoughts, why can't those headers be bundled together with Terra? Is there some licensing issue there?

Not if you use clang's headers. :-)
There is with gcc's and VS's.

Rely entirely on Clang, since we've got a lot of duplication of the paths we can probably just remove our versions of them. Presumably if we're not setting up bad paths in the code I linked above, then the Clang paths will just be used if we put the code back where it was originally. (I.e. Clang paths no longer need to be forced to come first.)

Honestly I'd say just do this, even Visual Studio 2017+ itself supports clang now. You'd have to use a very recent clang version though.

Fix the auto-detection of the registry keys so that we can find the correct paths ourselves, and then we can put the Clang paths back into their normal place.

For note, I'm not entirely sure that the Visual Studio Tools installs registry keys, I think it just updates the PATH and maybe some other envvars? It's basically the pure-cli version of Visual Studio designed for CI builds and so forth.

[ProfFan]

This version is not building for me on macOS High Sierra. The error is:

ld: warning: ignoring file libluajit.a, file was built for archive which is not the architecture being linked (x86_64): libluajit.a
Undefined symbols for architecture x86_64:
  "_luaJIT_version_2_0_5", referenced from:
      _pmain in luajit.o
  "_luaL_callmeta", referenced from:
      _traceback in luajit.o
...

[elliottslaughter]

@ProfFan Where did you get your LLVM? I'm also on 10.13.6, and I've had trouble building with certain binaries (though I can't remember ever seeing that exact message), but so far no trouble whenever I build LLVM from source.

[ProfFan]

@elliottslaughter I think it is not a problem with LLVM, as the failure is at the LuaJIT building.

[elliottslaughter]

@ProfFan Could you upload the full log somewhere? Might also be good to start from a fresh clone in case there is any residue left over.

[aiverson]

I tested the binary release build on Windows 10, Arch Linux, and Ubuntu

Under windows 10 with Visual Studio Community Edition 2017, I see the same symptom as mentioned previously with the failure to find the specified registry entry. I see the same set of failing tests with the addition of rd.t. However, all the cuda tests passed.

Under Arch Linux, I initially see a failure due to being unable to load libtinfo.so.5 because Arch Linux provides libtinfo.so.6. After putting a symlink to libtinfo.so.6 on the LD_PATH for Terra, Terra runs but writes to the terminal an error message stating libtinfo.so.5: no version information available (required by /.../terra-Linux-x86_64-2e2032e/bin/terra). The test report indicates that only dylib.t failed, with 522 tests passing and one failed. Cuda was enabled.

Testing darkroom from latest version on github produces the following error message

src/terralib.lua:774: bad argument #6 to 'addvalue' (string expected, got nil)
stack traceback:
        [C]: in function 'addvalue'
        src/terralib.lua:774: in function 'jitvalue'
        src/terralib.lua:526: in function 'compile'
        src/terralib.lua:532: in function 'getpointer'
        src/terralib.lua:540: in function 'makeIm'
        /home/aiverson/utils/darkroom/extras/darkroomSimple.t:75: in function 'load'
        test.t:57: in main chunk
        switch.lua:1: in main chunk
make: *** [makefile:15: out/switch.lua.bmp] Error 1

On Ubuntu 16.04, 523 tests pass, 0 failures.

Darkroom produces the same error under Ubuntu as under ArchLinux

[ProfFan]

@elliottslaughter Finally found the problem. I accidentally linked binutils which gives me a rogue ar utility. Now it compiles flawlessly.

[ProfFan]

@elliottslaughter Tested the test suite & Opt with CUDA on macOS, so far no problem :)

Darkroom produces the same error as @aiverson 's, probably we can ignore Darkroom for now?

Also, are there any other important downstream projects?

[elliottslaughter]

@jameshegarty Would you be interested in helping to test Darkroom against the new beta release of Terra? See above for errors we're seeing. ^^

[jameshegarty]

I dno if it makes sense to test Darkroom, since I'm not really maintaining that code (I'm not even sure if it works with the last public release of terra from a few years ago). But we should try it with Rigel (https://github.com/jameshegarty/rigel).

you can just do:
cd rigel/examples
make terra

I will try running this myself ASAP

[capr]

@memophen look at https://github.com/luapower/terra/blob/master/terralib_luapower.lua for how to set systemincludes

disas() doesn't give assembler code on Windows only LLVM IR (works on Linux though)

saveobj() detects binary type based on file extension IIRC so try it with 'helloterra.exe'

do you have stdio.h on your hard drive? find it manually then modify terralib.lua to point to it, it doesn't have to be VS 12

[memophen]

@capr (1) The CUDA_PATH method did the trick, no complaints about stdio.h anymore. Setting terra.systemincludes the way you indicate does not work for me. Reducing it to its preliminary essentials:

local ffi  = require 'ffi'
local List = require 'asdl'.List

print('ffi.os', ffi.os)
terra.systemincludes = List()
print 'So far'

The script stops before executing:

ERROR: The system was unable to find the specified registry key or value.
ERROR: The system was unable to find the specified registry key or value.
terralib_luapower--MINIMALIZED.t:5: '<name>' expected near '.'

ffi.os is 'Windows' indeed, by the way.

(2) I can accept disas() as is.

(3) Adding the .exe extension doesn't make any difference.

(4) There is no terralib.lua in the build (terra-Windows-x86_64-2e2032e.zip). My assumption of a reference to v12.0 was based on the source I downloaded separately (terra-release-1.0.0-beta1.zip).

[PyryM]

llvm: program not executable

This very helpful error message is caused when llvm can't find the linker (link.exe on Windows); a recent pull (#400) partially fixed this, as long as you run terra from the 'Developer Command Prompt' or 'x64 Native Tools Command Prompt' which set the right environment variables.

[elliottslaughter]

@PyryM can you try again on the latest master? We just merged #411 which should make this a lot better.

[ErikMcClure]

After going through this thread, I am alarmed at the amount of development being done by developers who simply do not use Windows, don't know how it works, and in some cases seem to aggressively not care, so I want to make a few things clear:

1. You absolutely must use the Windows SDK to build anything on Windows. Even clang finds the windows SDK and builds against it when building things for windows. The Windows SDK contains kernel32.lib which is what all executable binaries on the entire operating system must link to.

   Now, this doesn't always require that the Windows SDK is actually present on your machine. Every compiler for any language in existence that builds things on windows actually includes a part of the Windows SDK inside of itself. What happens is that languages like Rust and Go and Lua all have their own runtimes. These runtimes are always built against the Windows SDK using Visual Studio. This is exactly what LuaJIT does, and it's why you can drag it around to other machines that don't have Windows SDK installed and it will still work - the internal runtime was already linked against the Windows SDK and all the relevant parts of the SDK now exist inside the LuaJIT runtime itself.

   This is where we run into trouble. "All relevant parts" of the Windows SDK makes sense for a language like Lua, or Go, or Rust, who all have their own standard libraries that languages use. These languages do not, under normal circumstances, link directly to C headers, which means everything they need inside the Windows SDK is contained inside their own runtimes. If you do link directly against C headers, suddenly there is no "relevant part" of the Windows SDK anymore. You need all of it. The whole thing. Because Terra supports compiling arbitrary C code, it requires the entire Windows SDK, and by extension, the Visual Studio C runtime.

2. While it may be possible to find a substitute C runtime to avoid requiring Visual Studio, this would require compiling both LLVM and LuaJIT against this same substitute C runtime. It is possible to statically compile the Visual Studio C Runtime, which will help make terra.exe itself portable without the hack of copying msvcp140.dll (which you are definitely not supposed to be doing). This same technique can be used to make executables Terra compiles portable, by statically linking the C runtime.

   However, the runtime must still be present, and once again, we can't compile our own runtime that wraps around it, because Terra supports compiling arbitrary C code, which implies requiring the entire visual studio runtime. I have done some investigation and it may actually be possible to drop the vcruntime requirement under certain conditions, but this only works on Windows 10, which separated the C runtime into a windows component. Earlier versions do not. Unfortunately, the Windows SDK C runtime itself depends on visual studio being present, which makes it impossible to escape having Visual Studio installed if you want to compile arbitrary C code. This, of course, is ignoring the fact that we still rely on link.exe, which would have to be substituted with LLD.

3. Because of all this, not only do you have to query the registry to find the Windows SDK and Visual Studio on the host computer, you have to invoke a bunch of insane COM calls, all of which is officially documented by Microsoft as being The Correct Way of doing things.

4. Using cygwin or mingw are poor solutions that often don't work correctly, because they attempt to patch the actual C runtime with their own so they can try to pretend Windows is Linux. Windows is not Linux and this is almost never a reliable way of building anything. The Windows SDK being installed is non-negotiable. This is always going to be required, and the Windows SDK UCRT requires the Visual Studio runtime, which requires you install Visual Studio. If you want to compile C code on windows, you must install Visual Studio.

As a side-note, Terra executables are not portable. They dynamically link to the Visual Studio runtime, which requires the user install the corresponding Visual Studio Redistributable. This can be fixed if the entire LLVM + LuaJIT + Terra toolchain is changed to statically compile the runtime instead. Terra executables dynamically link to the C runtime, which is present everywhere, it is only Terra itself that is not portable. If people are interesting in attempting to fix any of these situations under windows, we should file issues to track each one.

[capr]

Just a couple of notes:

What you refer to as the C runtime is actually the C++ runtime (msvcp*.dll). The C runtime is msvcrt.dll and it's a Windows built-in since forever. You can safely link against that without redistribution issues but that's only for C programs. C++ programs must link msvcp statically or tell the user to download it from ms website since you're not licensed to include it yourself.

About mingw not working correctly, the entire luapower collection (including luajit, terra, llvm and binaries built with terra) is built on mingw64 since the beginning and I never had a bug from that. Luapower's terra.dll btw is portable, you can check it out here: https://github.com/luapower/terra/tree/master/bin

About the whole compiler detection thing, I personally wouldn't have done any of that, just add mention in the docs that you need to set the include paths of your CRT (be that VC or mingw depending on how you've built terra) if you want to use C headers from Terra. Every programmer would understand.

[ErikMcClure]

There are legends about mingw being poorly behaved in other projects. If it happened to work for you, congratulations, but I will never recommend it to anyone doing windows development.

I double checked and it looks like terra is linking against the C library, not the C++ one, so the executables being produced are actually portable, it is only terra itself that needs to be statically linked so we stop copying msvcp140.dll around. However, clang prefers to link against libcmt instead of msvcrt, so I think terra should prefer that as well. Unfortunately, I'm not willing to make this change until we can figure out why we can't compile stdio.h correctly.

[elliottslaughter]

I'd be fine with statically linking libcmt on Windows, and at least for certain LLVM versions we've already got builds that do that (see e.g. here). Right now the main limiting factor to getting more is that the builds time out on AppVeyor.

On Linux I think the holy build box approach probably makes more sense (i.e. dynamically link an old glibc for maximum compatibility, and statically link everything else), but if people want to convince me otherwise, by all mean do so.

I think we're not going to be able to get away without needing a full C compiler infrastructure at least at the point where Terra is being used to compile something. Since as @blackhole12 noted, we can compile arbitrary C code, and I consider this a feature not a bug (for exactly the reason why Dragon FFI exists when CFFI was already a thing). But if there are things we can do to improve the portability of Terra (so you don't need the same compiler/distro when using Terra to compile something as when you built it) then I'm all ears.

[ErikMcClure]

If Terra ever actually gets a standard library, it would be possible to build a "Terra runtime" which then contains whatever parts of the C standard library that the Terra standard library wraps around. This would allow you to compile terra code that only depends on the Terra standard library with no external C code without needing the Windows SDK or Visual Studio. This would still require switching to the LLD linker, because link.exe is only shipped with Visual Studio.

[elliottslaughter]

I forgot to add to my last comment: I'd be happy to have better MinGW support in Terra, and I think it could live alongside the existing MSVC support. But (as with all things in the project) it will have to come from someone who uses that platform on a regular basis and is willing to put in the time to make the improvements. There's a reason why the MSVC support has been advancing so rapidly recently....

[elliottslaughter]

Enough has changed recently that I'm planning to cut another beta release. Please let me know if there are any issues that should block that. (I consider documentation issues blockers for 1.0 but not for the next beta.)

[ErikMcClure]

I was originally going to suggest making another release once switch statements were added, but that has apparently devolved into a debate about whether it should even exist, so that's not going to happen.

I would consider trying to rebuild LLVM by statically linking the C++ runtime instead of shipping the dynamic library, but I haven't made any progress with that.

[elliottslaughter]

I do want to get switch or jump tables into a release, but I think it's worth taking the time to do them right.

I'm happy to do releases more frequently, assuming there is something worth releasing. So if we get switches shortly after this beta we can just do another one.

[ErikMcClure]

I don't think there are any really serious blocking issues at the moment, but nobody's actually gone back to check if we've been able to improve the situation in #366, which I believe was partially caused by the include header problem that I fixed. I'm hoping that my fix makes the result more portable, but we'd have to find the people who were having trouble installing terra and ask them to try again.

Of course, on the other hand, it'd be a lot easier to test if we have a beta build for them to test installation with, so maybe the best course of action is to simply make a second beta release and then use that to run more tests.

[PyryM]

I'm happy to test things on Windows if there are binaries available (so more frequent releases are better for me). And I believe the newly-introduced "github actions" (github's own CI/CD) does support Windows hosts, and claims to be free for public repos.

[elliottslaughter]

I think you can always get the most recent build off of AppVeyor, e.g. here's yesterday's build: https://ci.appveyor.com/api/buildjobs/3q0q8a9nccb0onxv/artifacts/terra-Windows-x86_64-8c6ccd0.zip

I wouldn't mind considering a more unified CI platform; we've got an issue about it at #355. The main limiter (as always) is someone's time to play around with the options and find something that works better than our current solution.

[aiverson]

I'd like to have improved RAII/memory management stuff in for the initial release of 1.0, but I don't think it should block making another beta release.

I think that there should be syntax support for some other things, but they don't need to all get implemented at once.

• let expressions, including using them inside constants when the only statements are variables being declared and initialized to constants
• Some form of switch statement/expression, C-style ints only at minimum, but an ADT Match operation would be great.

[Mx7f]

Testing on a Google Compute Engine; clean Ubuntu 18.04 installation. Installed Cuda 10.2; the GPU is a Tesla T4 (which is compute architecture 7.5, which is the latest). The cuda tests all fail with:

'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
'sm_75' is not a recognized processor for this target (ignoring processor)
cudahello.t:25: cuModuleLoadData: cuda reported error 218: a PTX JIT compilation failed

=================
= FAILING tests
=================
cudaagg.t
cudaoffline.t
cudaaggregate.t
cudatex.t
cudaglobal.t
cudashared.t
cudaconst2.t
cudaoo.t
cudatest.t
cudahello.t
cudaprintf.t
cudaatomic.t
=================

511 tests passed. 12 tests failed.

I'm guessing the problem is that this GPU's compute capability is higher than the highest supported by whichever version of LLVM produced the binaries, and the proper fix is to query LLVM for the highest supported and clamp the version to that. I'll give it a shot building from source in the coming days.

[ProfFan]

Just a side note: I recently upgraded my Mac to macOS Catalina, so I will not be able to test macOS + CUDA anymore as NV does not provide drivers for 10.14+... But anyway the user base is small so I assume that will not hurt too much...

[elliottslaughter]

If you have time it would be good to check there are no new issues on Catalina (i.e. relative to #365, which is still outstanding).

[ErikMcClure]

Since we have a beta2 now, maybe this should be updated?

[elliottslaughter]

Yeah, this issue has become large enough to be unmanageable, I'll regenerate the issue and copy the remaining todos.

[elliottslaughter]

New issue is at #439. Please move all new discussion there.

[elliottslaughter]

@Mx7f wrote:

Still digging into this, but as a heads up, I'm getting ~12x slowdown for cuda kernels using this release (and cuda 9.2) for Opt. Trying to figure out why...

Just wanted to follow up on this. Since the changes in #471 (comment) I'm getting equivalent performance with LLVM 13. It may be worth trying this out on Opt, if this is still something you care about.