similar to: Webpage to track implementation status of OpenMP features

Yes, I understand. I just don't understand why there are 15 review links. as to the format of the list, we previously had a list of feature for 4.5 (before it was fully supported), we can reuse this old format. Best regards, Alexey Bataev > 6 июня 2019 г., в 19:12, Narayanaswamy, Ravi <ravi.narayanaswamy at intel.com> написал(а): > > Alexey, > Johannes want to put all

I don't know where it comes from, currently there is just 2 patches with the new functionality : mapper implementation in clang and in the runtime. Plus the patch for unified memory. Best regards, Alexey Bataev > 6 июня 2019 г., в 19:03, Doerfert, Johannes <jdoerfert at anl.gov> написал(а): > >> On 06/06, Alexey Bataev via llvm-dev wrote: >> Hmm, it is interesting.

Long story short: We want to create a webpage under llvm.org that shows the implementation status of OpenMP features, similar to https://clang.llvm.org/cxx_status.html . Please let me know if you have wishes, questions, or concerns. Cheers, Johannes

<font size=2 face="sans-serif">Hi Johannes,</font><br><br><font size=2 face="sans-serif">Thank you for the explanation.</font><br><br><font size=2 face="sans-serif">I think we need to clarify some details about code generation in Clang today:</font><br><br><font size=2

Where we are ------------ Currently, when we generate OpenMP target offloading code for GPUs, we use sufficient syntactic criteria to decide between two execution modes: 1) SPMD -- All target threads (in an OpenMP team) run all the code. 2) "Guarded" -- The master thread (of an OpenMP team) runs the user code. If an OpenMP distribute region is encountered,

Hello! I have samba share on my sshfs-mounted folder. All works just fine except I can't delete files from sshfs unless they are in 0777 chmodded directory. Even if that files were putted trough smbclient. I can read files, write files (regardless their directory permissions) but not delete them. Here is my share config: [myshare] comment = shre over sshfs path = /home/kli/work/remotes/dev

On Mon, Aug 27, 2018 at 10:30 AM, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: > On 2018-08-27 09:44, Sedat Dilek wrote: >> >> Yeah, I see. >> You have an unusual development process seen from my POV. > > > GNOME does the same, to pick one example: > https://wiki.gnome.org/ThreePointTwentynine > Tarballs are due on Monday, official release and announcement

I mean different source password for each mountpoint, no listener password.. chiapas at aktivix.org kirjoitti 20.9.2008 kello 21.36: > 2008/9/18 Timo H?kli <timpuri at kepit.fi>: >> Hi! > > Hi > >> Is it possible to specify different source password for all >> mounpoints? > > A different password for each mountpoint? Sure. > >> I tried to

Hi! Is it possible to specify different source password for all mounpoints? I tried to found it from docs, but.. If there is some other method to increase security when playing with multiple users and mountpoints, please tell me! - Timo H?kli

Yeah, I see. You have an unusual development process seen from my POV. IMHO you can provide the tarballs before the "binaries" are uploaded which means "prebuilt binaries". That could increase the quality of developing when different arch/os maintainers give their OK. But for 7.0.0rc1 I see only prebuilt binaries for... * macOS * FreeBSD10 AMD64 * Windows (32-bit) * Windows

On Thu, Jan 18, 2018 at 7:27 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 18 Jan 2018, at 15:03, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: >> >> Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: >>> On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers >>> <release-testers at lists.llvm.org> wrote: >>>> Start

On 19 Jan 2018, at 17:11, Hans Wennborg <hans at chromium.org> wrote: > > On Thu, Jan 18, 2018 at 7:27 PM, Dimitry Andric <dimitry at andric.com> wrote: >> On 18 Jan 2018, at 15:03, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: >>> >>> Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: >>>> On 17 Jan 2018, at 18:53, Hans Wennborg

On 18 Jan 2018, at 15:03, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: > > Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: >> On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers >> <release-testers at lists.llvm.org> wrote: >>> Start your engines; 6.0.0-rc1 was just tagged. >>> I know there are still open blockers and it's early

Johannes, did you try it on AMD GPUs? If not, I think it might be early to claim it as a general interface for NVidia/AMD GPUs. I'm ok, if you want tointroduce a basic class for the GPU-specific codegen, but it must be done step-by-step and thoroughly tested and reviewed. Theremightbe some parts, common with NVPTX codegen. You can put the commonfunctions into a base class and remove them from

1. You don't need to implement everything in a single patch. The development process is a step-by-step process, when you commit something in small pieces. The code must nit be fully functional, you may start from some basic features. Currently it is very hard to review. 2. I rather doubt that it can be reused without changes for AMD etc., especially without being fully tested. The only tested

libc++.so should be a linker script that automatically pulls in libc++abi (see "Failed to read file header" in your output). And IIRC libc++abi is only one possible implementation that may be used by libc++, but I'm no expert here... Am 2018-03-05 17:33, schrieb Brian Cain: > Isn't libc++.so dependent on libc++abi.so? > > On Mon, Mar 5, 2018 at 10:30 AM, Jonas

Curious. I removed -fno-experimental-isel and all of the tests *except* control_tool.c passed. I would have expected all of them to pass if blockaddress works. I'll try to look at some asm and see what's going on. -David Jonas Hahnfeld <hahnjo at hahnjo.de> writes: > Hi David, > > I was the one who originally added the flag to fix failures

Avoids trying to create and replace version.h more than once which led to file-locking errors with multicore builds. --- Makefile.am | 1 + win32/VS2015/celt.vcxproj | 48 +++++++++++++++++--------- win32/VS2015/generate_version.vcxproj | 65 +++++++++++++++++++++++++++++++++++ win32/VS2015/opus.sln | 32 ++++++++++++++++-

Isn't libc++.so dependent on libc++abi.so? On Mon, Mar 5, 2018 at 10:30 AM, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: > From what I can see all of the libraries without RPATH are runtime > libraries that are used by binaries compiled with Clang. I think they don't > have a dependency on other libraries in that directory, so what would be > the advantage of having

Using -i should prevent failing if the files don't exist. --- appveyor.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appveyor.yml b/appveyor.yml index c85b0b1..ad9c6c0 100644 --- a/appveyor.yml +++ b/appveyor.yml @@ -17,7 +17,7 @@ build: verbosity: minimal after_build: -- cmd: 7z a opus.zip win32\VS2015\%PLATFORM%\%CONFIGURATION%\opus.lib include\*.h +- cmd: 7z