Re: [libcxx] r292013 - Fix last_write_time tests for filesystems that don't support negative and very large times

Hi Hans, can this be merged for 4.0? Eric suggested this in https://reviews.llvm .org/D22452 so I think he should be fine. Thanks, Jonas Am Samstag, den 14.01.2017, 11:35 + schrieb Jonas Hahnfeld via cfe- commits: > Author: hahnfeld > Date: Sat Jan 14 05:35:15 2017 > New Revision: 292013 >

RE: [libcxx] r292013 - Fix last_write_time tests for filesystems that don't support negative and very large times

Thanks for already taking care, less work for me :-) > -Original Message- > From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf > Of Hans Wennborg > Sent: Wednesday, January 18, 2017 6:19 AM > To: Eric Fiselier > Cc: Hahnfeld, Jonas; cfe-commits@lists.llvm.org > Subject: Re:

RE: [libcxx] r294107 - Recommit [libcxx] Never use within libc++

Hi Eric, I'm getting quite a few failures with LIBCXX_ENABLE_ASSERTIONS=On (didn't do a clean build at first): Failing Tests (32): libc++ :: std/experimental/filesystem/class.directory_entry/directory_entry.cons.pass.cpp libc++ :: std/experimental/filesystem/class.directory_entry/direct

RE: D34158: to support gcc 4.8 (and newer) compatibility on Linux, preinclude

Hi, -Original Message- From: Blower, Melanie [mailto:melanie.blo...@intel.com] Sent: Thursday, June 29, 2017 5:35 AM To: reviews+d34158+public+125da21f27579...@reviews.llvm.org; zhangsheng...@huawei.com; olivier...@gmail.com; kalinichev.s...@gmail.com; kf...@kde.org; m...@milianw.de; Kea

Re: r295473 - [OpenMP] Remove barriers at cancel and cancellation point

Hi Hans, Alexey, can we merge this commit and r295474 for the 4.0 release or is it already too late for that? I will totally understand that and can apply these commits locally prior to installing. However, I think that these changes are quite focussed and bear minimal possibility of introducing r

RE: r295473 - [OpenMP] Remove barriers at cancel and cancellation point

Hi Hans, Did r295474 fall off your radar? Sorry that I asked for both commits in one email, should I reply to the other original commit? Thanks, Jonas > -Original Message- > From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf > Of Hans Wennborg > Sent: Thursday, February

RE: r295474 - [OpenMP] Fix cancellation point in task with no cancel

Thanks! Jonas > -Original Message- > From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf > Of Hans Wennborg > Sent: Friday, February 24, 2017 6:39 PM > To: Hahnfeld, Jonas > Cc: cfe-commits > Subject: Re: r295474 - [OpenMP] Fix cancellation point in task with no > cancel >

RE: r285326 - [Driver][OpenMP] Add support to create jobs for unbundling actions.

Hi, I think I have identified what is the problem here: the so-called “name hiding” when overloading virtual functions. (see http://stackoverflow.com/a/1629074) To fix it, I see two possible solutions: Either apply the attached patch or rename one method so that the hiding does not happen.

RE: RE: r285326 - [Driver][OpenMP] Add support to create jobs for unbundling actions.

Hi Samuel, if we trust StackOverflow, the code is wrong because all functions with the same name are hidden, ignoring the rest of the signature. I will try to find the corresponding section in the C++ standard… I think any version of GCC gives the error, I was able to reproduce this with

RE: [libcxx] r250319 - [libcxx] Make it drastically simpler to link libc++.

> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf > Of Eric Fiselier via cfe-commits > Sent: Wednesday, October 14, 2015 9:54 PM > To: cfe-commits@lists.llvm.org > Subject: [libcxx] r250319 - [libcxx] Make it drastically simpler to link > libc++

RE: [libcxx] r251065 - Dont required CMake 3 to install a linker script

Hi, thanks for the attempt to fix this, but this isn't working for in-tree builds of libcxx: CMake Error at projects/libcxx/lib/cmake_install.cmake:56 (FILE): file INSTALL cannot find "<<>>/projects/libcxx/lib/libc++.so" It is located at <<>>/lib/libc++.so. CMake version is 2.8.12.2 which s

RE: [libcxx] r251065 - Dont required CMake 3 to install a linker script

No problem, seems to work now :-) Thanks Jonas From: Eric Fiselier [mailto:e...@efcs.ca] Sent: Friday, October 23, 2015 9:08 AM To: Hahnfeld, Jonas Cc: cfe-commits@lists.llvm.org Subject: Re: [libcxx] r251065 - Dont required CMake 3 to install a linker script Hi Jonas, Thanks for bein

RE: r278140 - [CUDA] Regression test to make sure C++ include path are forwarded to host and device frontends.

Hi, > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf > Of Ismail Donmez via cfe-commits > Sent: Friday, August 12, 2016 11:05 AM > To: Samuel Antao > Cc: cfe-commits > Subject: Re: r278140 - [CUDA] Regression test to make sure C++ include path

AW: r260755 - Darwin: pass -stdlib=libc++ down to cc1 whenever we're targeting libc++

Hi Tim, as I did the change: Sorry that it broke for you on Darwin! I could not test myself and there doesn't seem to be a build-bot... To the change: I think the explicit passing of -stdlib=libc++ will override CLANG_DEFAULT_CXX_STDLIB on Darwin. Instead, Darwin::AddClangCXXStdlibIncludeArgs s

RE: r260755 - Darwin: pass -stdlib=libc++ down to cc1 whenever we're targeting libc++

Hi Tim, > -Original Message- > From: tnortho...@apple.com [mailto:tnortho...@apple.com] > Sent: Monday, February 15, 2016 5:43 PM > To: Hahnfeld, Jonas > Cc: cfe-commits@lists.llvm.org > Subject: Re: r260755 - Darwin: pass -stdlib=libc++ down to cc1 whenever > we're targeting libc++ > > H

RE: r270822 - [OPENMP] Set '_OPENMP' macro to '201511' value to reflect support for

Hi Alexey, I don't really know whether this is correct. IMO this may only be set once OpenMP 4.5 is fully supported. This currently isn't even the case for OpenMP 4.0 as at least support for #pragma omp target update has not yet been committed. In my understanding the macro may be used for feat

RE: r270822 - [OPENMP] Set '_OPENMP' macro to '201511' value to reflect support for

Hi Alexey, If this defaults to the currently completely supported version (I think 4.0 when target update gets committed), that would be great. That way, the user would have to explicitly request the newer (and possibly incomplete) version. Greetings, Jonas > -Original Message- > From:

RE: r270373 - [driver][mips] Support new versions of MIPS CodeScape toolchains

Hi, Have you also set CLANG_DEFAULT_CXX_STDLIB? Then you may need to add an '-stdlib=platform' to the test... (see r260662 and r263434) Cheers, Jonas > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf > Of Ismail Donmez via cfe-commits > Sent:

RE: r270373 - [driver][mips] Support new versions of MIPS CodeScape toolchains

You're welcome. I also had to challenge these issues when I introduced this "feature flag" ;-) > -Original Message- > From: Ismail Donmez [mailto:ism...@i10z.com] > Sent: Thursday, May 26, 2016 5:27 PM > To: Simon Atanasyan > Cc: Hahnfeld, Jonas; cfe-commits@lists.llvm.org > Subject: Re:

RE: 3.8 Merge Request: r259776

Hi, last possible ping as changes are required to be merged by tomorrow... Cheers, Jonas > -Original Message- > From: llvm-commits [mailto:llvm-commits-boun...@lists.llvm.org] On Behalf > Of Hahnfeld, Jonas via llvm-commits > Sent: Monday, May 23, 2016 8:13 AM > To: Tom Stellard > Cc: Ba

RE: 3.8 Merge Request: r259776

Assuming I got it right... > -Original Message- > From: Alexey Bataev [mailto:a.bat...@hotmail.com] > Sent: Monday, May 30, 2016 1:31 PM > To: Hahnfeld, Jonas > Cc: cfe-commits@lists.llvm.org; Tom Stellard > Subject: Re: 3.8 Merge Request: r259776 > > I can try to rebase it to 3.8.1 but T

RE: r259776 - [OPENMP 4.0] Fixed support of array sections/array subscripts.

Hi Alexey, I think this now also affects the released version of Clang 3.8.0. Can this be merged for 3.8.1 if such a version will exist somewhen? Thanks, Jonas > -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf > Of Alexey Bataev via cfe-commit

RE: D16358: [OpenMP] Parsing + Sema for nowait clause on target directive

Hi Alexey, Phabricator doesn't send mails when only the review state changes as mentioned in documentation. This makes following the current status hard when relying on them. Could you therefore please type a "LGTM" which should trigger an email to the mailing list? Thanks, Jonas > -Origi