from:"Hahnfeld, Jonas via cfe\-commits"

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

2017-01-14 Thread Hahnfeld, Jonas via cfe-commits

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
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=292013&view=rev
> Log:
> Fix last_write_time tests for filesystems that don't support negative and 
> very large times
> 
> Seems to be the case for NFS.
> 
> Original patch by Eric Fiselier!
> Differential Revision: https://reviews.llvm.org/D22452
> 
> Modified:
> 
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
> 
> Modified: 
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp?rev=292013&r1=292012&r2=292013&view=diff
> ==
> --- 
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
>  (original)
> +++ 
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
>  Sat Jan 14 05:35:15 2017
> @@ -72,13 +72,60 @@ std::pair GetS
>  return {st.st_atime, st.st_mtime};
>  }
>  
> -inline bool TimeIsRepresentableAsTimeT(file_time_type tp) {
> +namespace {
> +bool TestSupportsNegativeTimes() {
> +using namespace std::chrono;
> +std::error_code ec;
> +std::time_t old_write_time, new_write_time;
> +{ // WARNING: Do not assert in this scope.
> +scoped_test_env env;
> +const path file = env.create_file("file", 42);
> +old_write_time = LastWriteTime(file);
> +file_time_type tp(seconds(-5));
> +fs::last_write_time(file, tp, ec);
> +new_write_time = LastWriteTime(file);
> +}
> +return !ec && new_write_time <= -5;
> +}
> +
> +bool TestSupportsMaxTime() {
>  using namespace std::chrono;
>  using Lim = std::numeric_limits;
> -auto sec = duration_cast(tp.time_since_epoch()).count();
> -return (sec >= Lim::min() && sec <= Lim::max());
> +auto max_sec = 
> duration_cast(file_time_type::max().time_since_epoch()).count();
> +if (max_sec > Lim::max()) return false;
> +std::error_code ec;
> +std::time_t old_write_time, new_write_time;
> +{ // WARNING: Do not assert in this scope.
> +scoped_test_env env;
> +const path file = env.create_file("file", 42);
> +old_write_time = LastWriteTime(file);
> +file_time_type tp = file_time_type::max();
> +fs::last_write_time(file, tp, ec);
> +new_write_time = LastWriteTime(file);
> +}
> +return !ec && new_write_time > max_sec - 1;
>  }
>  
> +static const bool SupportsNegativeTimes = TestSupportsNegativeTimes();
> +static const bool SupportsMaxTime = TestSupportsMaxTime();
> +
> +} // end namespace
> +
> +// Check if a time point is representable on a given filesystem. Check that:
> +// (A) 'tp' is representable as a time_t
> +// (B) 'tp' is non-negative or the filesystem supports negative times.
> +// (C) 'tp' is not 'file_time_type::max()' or the filesystem supports the max
> +// value.
> +inline bool TimeIsRepresentableByFilesystem(file_time_type tp) {
> +using namespace std::chrono;
> +using Lim = std::numeric_limits;
> +auto sec = duration_cast(tp.time_since_epoch()).count();
> +auto microsec = 
> duration_cast(tp.time_since_epoch()).count();
> +if (sec < Lim::min() || sec > Lim::max())   return false;
> +else if (microsec < 0 && !SupportsNegativeTimes) return false;
> +else if (tp == file_time_type::max() && !SupportsMaxTime) return false;
> +return true;
> +}
>  
>  TEST_SUITE(exists_test_suite)
>  
> @@ -214,15 +261,17 @@ TEST_CASE(set_last_write_time_dynamic_en
>  
>  file_time_type  got_time = last_write_time(TC.p);
>  
> -TEST_CHECK(got_time != old_time);
> -if (TC.new_time < epoch_time) {
> -TEST_CHECK(got_time <= TC.new_time);
> -TEST_CHECK(got_time > TC.new_time - Sec(1));
> -} else {
> -TEST_CHECK(got_time <= TC.new_time + Sec(1));
> -TEST_CHECK(got_time >= TC.new_time - Sec(1));
> +if (TimeIsRepresentableByFilesystem(TC.new_time)) {
> +TEST_CHECK(got_time != old_time);
> +if (TC.new_time < epoch_time) {
> +TEST_CHECK(got_time <= TC.new_time);
> +TEST_CHECK(got_time > TC.new_time - Sec(1));
> +} else {
> +TEST_CHECK(got_time <= TC.new_time + Sec(1));
> +TEST_CHECK(got_time >= TC.new_time - Sec(1));
> +}
> +TEST_CHECK(LastAccessTime(TC.p) == old_times.first);
>  }
> -TEST_CHECK(La

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

2017-01-17 Thread Hahnfeld, Jonas via cfe-commits

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: [libcxx] r292013 - Fix last_write_time tests for filesystems 
> that
> don't support negative and very large times
>
> I went ahead and merged it in r292341.
>
> On Tue, Jan 17, 2017 at 4:26 PM, Eric Fiselier  wrote:
> > @Jonas please go ahead and merge this patch.
> >
> > On Tue, Jan 17, 2017 at 5:24 PM, Hans Wennborg 
> wrote:
> >>
> >> Yes, go ahead.
> >>
> >> Apologies for the delay.
> >>
> >>  - Hans
> >>
> >> On Sat, Jan 14, 2017 at 5:54 AM, Eric Fiselier  wrote:
> >> > +1 from me. @Hans am I OK to merge this?
> >> >
> >> > On Sat, Jan 14, 2017 at 4:53 AM, Hahnfeld, Jonas
> >> >  wrote:
> >> >>
> >> >> 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
> >> >>
> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=292013&view=rev
> >> >> Log:
> >> >> Fix last_write_time tests for filesystems that don't support
> >> >> negative and very large times
> >> >>
> >> >> Seems to be the case for NFS.
> >> >>
> >> >> Original patch by Eric Fiselier!
> >> >> Differential Revision: https://reviews.llvm.org/D22452
> >> >>
> >> >> Modified:
> >> >>
> >> >>
> >> >> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.la
> >> >> st_write_time/last_write_time.pass.cpp
> >> >>
> >> >> Modified:
> >> >>
> >> >> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.la
> >> >> st_write_time/last_write_time.pass.cpp
> >> >> URL:
> >> >>
> >> >> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experime
> >> >> ntal/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.
> >> >> pass.cpp?rev=292013&r1=292012&r2=292013&view=diff
> >> >>
> >> >>
> >> >>
> ==
> 
> >> >> 
> >> >> ---
> >> >>
> >> >> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.la
> >> >> st_write_time/last_write_time.pass.cpp
> >> >> (original)
> >> >> +++
> >> >>
> >> >> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.la
> >> >> st_write_time/last_write_time.pass.cpp
> >> >> Sat Jan 14 05:35:15 2017
> >> >> @@ -72,13 +72,60 @@ std::pair GetS
> >> >>  return {st.st_atime, st.st_mtime};  }
> >> >>
> >> >> -inline bool TimeIsRepresentableAsTimeT(file_time_type tp) {
> >> >> +namespace {
> >> >> +bool TestSupportsNegativeTimes() {
> >> >> +using namespace std::chrono;
> >> >> +std::error_code ec;
> >> >> +std::time_t old_write_time, new_write_time;
> >> >> +{ // WARNING: Do not assert in this scope.
> >> >> +scoped_test_env env;
> >> >> +const path file = env.create_file("file", 42);
> >> >> +old_write_time = LastWriteTime(file);
> >> >> +file_time_type tp(seconds(-5));
> >> >> +fs::last_write_time(file, tp, ec);
> >> >> +new_write_time = LastWriteTime(file);
> >> >> +}
> >> >> +return !ec && new_write_time <= -5; }
> >> >> +
> >> >> +bool TestSupportsMaxTime() {
> >> >>  using namespace std::chrono;
> >> >>  using Lim = std::numeric_limits;
> >> >> -auto sec =
> duration_cast(tp.time_since_epoch()).count();
> >> >> -return (sec >= Lim::min() && sec <= Lim::max());
> >> >> +auto max_sec =
> >> >>
> >> >> duration_cast(file_time_type::max().time_since_epoch()).c
> >> >> ount();
> >> >> +if (max_sec > Lim::max()) return false;
> >> >> +std::error_code ec;
> >> >> +std::time_t old_write_time, new_write_time;
> >> >> +{ // WARNING: Do not assert in this scope.
> >> >> +scoped_test_env env;
> >> >> +const path file = env.create_file("file", 42);
> >> >> +old_write_time = LastWriteTime(file);
> >> >> +file_time_type tp = file_time_type::max();
> >> >> +fs::last_write_time(file, tp, ec);
> >> >> +new_write_time = LastWriteTime(file);
> >> >> +}
> >> >> +return !ec && new_write_time > max_sec - 1;
> >> >>  }
> >> >>
> >> >> +static const bool SupportsNegativeTimes =
> >> >> +TestSupportsNegativeTimes(); static const bool SupportsMaxTime =
> >> >> +TestSupportsMaxTime();
> >> >> +
> >> >> +} // end namespace
> >> >> +
> >> >> +// Check if a time point is representable on a given filesystem.
> >> >> +Check
> >> >> that:
> >> >> +// (A) 'tp' is representable as a time_t // (B) 'tp' is
> >> >> +non-negative or the filesystem supports negative times.
> >> >> +// (C) 'tp' is not 'file_time_type::max()' or the filesystem
> >> >> +supports
> >> >

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

2017-02-06 Thread Hahnfeld, Jonas via cfe-commits

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/directory_entry.mods.pass.cpp
libc++ :: 
std/experimental/filesystem/class.directory_entry/directory_entry.obs/comparisons.pass.cpp
libc++ :: 
std/experimental/filesystem/class.directory_iterator/directory_iterator.members/ctor.pass.cpp
libc++ :: 
std/experimental/filesystem/class.directory_iterator/directory_iterator.members/increment.pass.cpp
libc++ :: 
std/experimental/filesystem/class.directory_iterator/directory_iterator.nonmembers/begin_end.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.itr/iterator.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.append.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.assign/source.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.compare.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.concat.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.decompose/path.decompose.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.modifiers/make_preferred.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.modifiers/remove_filename.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.modifiers/replace_extension.pass.cpp
libc++ :: 
std/experimental/filesystem/class.path/path.member/path.modifiers/swap.pass.cpp
libc++ :: 
std/experimental/filesystem/class.rec.dir.itr/rec.dir.itr.members/ctor.pass.cpp
libc++ :: 
std/experimental/filesystem/class.rec.dir.itr/rec.dir.itr.members/depth.pass.cpp
libc++ :: 
std/experimental/filesystem/class.rec.dir.itr/rec.dir.itr.members/increment.pass.cpp
libc++ :: 
std/experimental/filesystem/class.rec.dir.itr/rec.dir.itr.nonmembers/begin_end.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.canonical/canonical.pass.cpp
libc++ :: std/experimental/filesystem/fs.op.funcs/fs.op.copy/copy.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.is_empty/is_empty.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.permissions/permissions.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.read_symlink/read_symlink.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.remove/remove.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.remove_all/remove_all.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.resize_file/resize_file.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.space/space.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.status/status.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.symlink_status/symlink_status.pass.cpp
libc++ :: 
std/experimental/filesystem/fs.op.funcs/fs.op.temp_dir_path/temp_directory_path.pass.cpp

They go away with LIBCXX_ENABLE_ASSERTIONS=Off which is the new default. Is 
this expected to happen?

Thanks,
Jonas

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Eric Fiselier via cfe-commits
> Sent: Sunday, February 05, 2017 12:22 AM
> To: cfe-commits@lists.llvm.org
> Subject: [libcxx] r294107 - Recommit [libcxx] Never use  within
> libc++
>
> Author: ericwf
> Date: Sat Feb  4 17:22:28 2017
> New Revision: 294107
>
> URL: http://llvm.org/viewvc/llvm-project?rev=294107&view=rev
> Log:
> Recommit [libcxx] Never use  within libc++
>
> It is my opinion that libc++ should never use ``, including in the
> `dylib`.
> This patch remove all uses of `assert` from within libc++ and replaces most 
> of
> them with `_LIBCPP_ASSERT` instead.
>
> Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS`  off by default,
> because the standard library should not be aborting user programs unless
> explicitly asked to.
>
> Modified:
> libcxx/trunk/CMakeLists.txt
> libcxx/trunk/include/__config
> libcxx/trunk/include/__threading_support
> libcxx/trunk/src/condition_variable.cpp
> libcxx/trunk/src/experimental/filesystem/path.cpp
> libcxx/trunk/src/mutex.cpp
> libcxx/trunk/src/system_error.cpp
>
> Modified: libcxx/trunk/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-
> project/libcxx/trunk/CMakeLists.txt?rev=294107&r1=294106&r2=294107&vie
> w=diff
> ==
> 
> --- libcxx/trunk/CMakeLists.txt (original)
> +++ libcxx/trunk/CMakeLists.txt Sat Feb  4 17:22:28 2017
> @@ -60,7 +60,7 @@ endif()
>  include(CMakeDependentOption)
>
>  # Basic 
> options ---
> -option(L

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

2017-06-29 Thread Hahnfeld, Jonas via cfe-commits

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; Keane, Erich ; 
Hahnfeld, Jonas ; mgo...@gentoo.org; 
fedor.serg...@oracle.com; rich...@metafoo.co.uk; renato.go...@linaro.org
Cc: cfe-commits@lists.llvm.org; kli...@google.com; simon.dar...@imgtec.com; 
anastasia.stul...@arm.com; arichardson@gmail.com
Subject: RE: D34158: to support gcc 4.8 (and newer) compatibility on Linux, 
preinclude 

[...]


Comment at: test/Driver/gcc-predef.c:9
+  #else
+#if !defined(  _STDC_PREDEF_H )
+  #error "stdc-predef.h should be preincluded for GNU/Linux 4.8 and 
higher"

The driver will only include `stdc-predef.h` if it can be found in the system. 
With that, the current version of this test will only run on such Linux 
system. Maybe add a basic tree in `test/Driver/Inputs` and test that the 
corresponding header is included?
>>>OK I understand what you mean now.

To be clear here: I was thinking about running this test case on let's say 
Darwin/Mac OS X != GNU/Linux. But you probably figured that out of my 
imprecise comment already. Sorry about that.

Regards,
Jonas


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2017-02-17 Thread Hahnfeld, Jonas via cfe-commits

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 regressions.

Thanks,
Jonas

Am Freitag, den 17.02.2017, 18:32 + schrieb Jonas Hahnfeld via cfe-
commits:
> Author: hahnfeld
> Date: Fri Feb 17 12:32:51 2017
> New Revision: 295473
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=295473&view=rev
> Log:
> [OpenMP] Remove barriers at cancel and cancellation point
> 
> This resolves a deadlock with the cancel directive when there is no explicit
> cancellation point. In that case, the implicit barrier acts as cancellation
> point. After removing the barrier after cancel, the now unmatched barrier for
> the explicit cancellation point has to go as well.
> 
> This has probably worked before rL255992: With the calls for the explicit
> barrier, it was sure that all threads passed a barrier before exiting.
> 
> Reported by Simon Convent and Joachim Protze!
> 
> Differential Revision: https://reviews.llvm.org/D30088
> 
> Modified:
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/test/OpenMP/cancel_codegen.cpp
> cfe/trunk/test/OpenMP/cancellation_point_codegen.cpp
> 
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=295473&r1=295472&r2=295473&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri Feb 17 12:32:51 2017
> @@ -4724,7 +4724,6 @@ void CGOpenMPRuntime::emitCancellationPo
>auto *Result = CGF.EmitRuntimeCall(
>createRuntimeFunction(OMPRTL__kmpc_cancellationpoint), Args);
>// if (__kmpc_cancellationpoint()) {
> -  //  __kmpc_cancel_barrier();
>//   exit from construct;
>// }
>auto *ExitBB = CGF.createBasicBlock(".cancel.exit");
> @@ -4732,8 +4731,6 @@ void CGOpenMPRuntime::emitCancellationPo
>auto *Cmp = CGF.Builder.CreateIsNotNull(Result);
>CGF.Builder.CreateCondBr(Cmp, ExitBB, ContBB);
>CGF.EmitBlock(ExitBB);
> -  // __kmpc_cancel_barrier();
> -  emitBarrierCall(CGF, Loc, OMPD_unknown, /*EmitChecks=*/false);
>// exit from construct;
>auto CancelDest =
>CGF.getOMPCancelDestination(OMPRegionInfo->getDirectiveKind());
> @@ -4762,7 +4759,6 @@ void CGOpenMPRuntime::emitCancelCall(Cod
>auto *Result = CGF.EmitRuntimeCall(
>RT.createRuntimeFunction(OMPRTL__kmpc_cancel), Args);
>// if (__kmpc_cancel()) {
> -  //  __kmpc_cancel_barrier();
>//   exit from construct;
>// }
>auto *ExitBB = CGF.createBasicBlock(".cancel.exit");
> @@ -4770,8 +4766,6 @@ void CGOpenMPRuntime::emitCancelCall(Cod
>auto *Cmp = CGF.Builder.CreateIsNotNull(Result);
>CGF.Builder.CreateCondBr(Cmp, ExitBB, ContBB);
>CGF.EmitBlock(ExitBB);
> -  // __kmpc_cancel_barrier();
> -  RT.emitBarrierCall(CGF, Loc, OMPD_unknown, /*EmitChecks=*/false);
>// exit from construct;
>auto CancelDest =
>CGF.getOMPCancelDestination(OMPRegionInfo->getDirectiveKind());
> 
> Modified: cfe/trunk/test/OpenMP/cancel_codegen.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/cancel_codegen.cpp?rev=295473&r1=295472&r2=295473&view=diff
> ==
> --- cfe/trunk/test/OpenMP/cancel_codegen.cpp (original)
> +++ cfe/trunk/test/OpenMP/cancel_codegen.cpp Fri Feb 17 12:32:51 2017
> @@ -12,6 +12,8 @@ int main (int argc, char **argv) {
>  {
>  #pragma omp cancel parallel if(flag)
>argv[0][0] = argc;
> +#pragma omp barrier
> +  argv[0][0] += argc;
>  }
>  // CHECK: call void (%ident_t*, i32, void (i32*, i32*, ...)*, ...) 
> @__kmpc_fork_call(
>  #pragma omp sections
> @@ -20,7 +22,6 @@ int main (int argc, char **argv) {
>  }
>  // CHECK: call void @__kmpc_for_static_init_4(
>  // CHECK: call i32 @__kmpc_cancel(
> -// CHECK: call i32 @__kmpc_cancel_barrier(%ident_t*
>  // CHECK: call void @__kmpc_for_static_fini(
>  // CHECK: call void @__kmpc_barrier(%ident_t*
>  #pragma omp sections
> @@ -36,7 +37,6 @@ int main (int argc, char **argv) {
>  // CHECK: [[CMP:%.+]] = icmp ne i32 [[RES]], 0
>  // CHECK: br i1 [[CMP]], label %[[EXIT:[^,].+]], label %[[CONTINUE:.+]]
>  // CHECK: [[EXIT]]
> -// CHECK: call i32 @__kmpc_cancel_barrier(%ident_t*
>  // CHECK: br label
>  // CHECK: [[CONTINUE]]
>  // CHECK: br label
> @@ -44,7 +44,6 @@ int main (int argc, char **argv) {
>  // CHECK: [[CMP:%.+]] = icmp ne i32 [[RES]], 0
>  // CHECK: br i1 [[CMP]], label %[[EXIT:[^,].+]], label %[[CONTINUE:.+]]
>  // CHECK: [[EXIT]]
> -// CHECK: call i32 @__kmpc_cancel_barrier(%ident_t*
>  //

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

2017-02-23 Thread Hahnfeld, Jonas via cfe-commits

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 23, 2017 7:46 PM
> To: Alexey Bataev
> Cc: Hahnfeld, Jonas; cfe-commits@lists.llvm.org
> Subject: Re: r295473 - [OpenMP] Remove barriers at cancel and cancellation
> point
> 
> Thanks! r296000.
> 
> On Wed, Feb 22, 2017 at 8:15 PM, Alexey Bataev 
> wrote:
> > Yes, approved
> >
> > Best regards,
> > Alexey Bataev
> >
> >> 23 февр. 2017 г., в 1:00, Hans Wennborg 
> написал(а):
> >>
> >> Alexey: ping?
> >>
> >>> On Tue, Feb 21, 2017 at 11:07 AM, Hans Wennborg
>  wrote:
> >>> I'm Ok with it if Alexey approves.
> >>>
> >>> On Fri, Feb 17, 2017 at 10:52 AM, Hahnfeld, Jonas
> >>>  wrote:
>  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 regressions.
> 
>  Thanks,
>  Jonas
> 
>  Am Freitag, den 17.02.2017, 18:32 + schrieb Jonas Hahnfeld via
>  cfe-commits:
> 
>  Author: hahnfeld
>  Date: Fri Feb 17 12:32:51 2017
>  New Revision: 295473
> 
>  URL: http://llvm.org/viewvc/llvm-project?rev=295473&view=rev
>  Log:
>  [OpenMP] Remove barriers at cancel and cancellation point
> 
>  This resolves a deadlock with the cancel directive when there is no
>  explicit cancellation point. In that case, the implicit barrier
>  acts as cancellation point. After removing the barrier after
>  cancel, the now unmatched barrier for the explicit cancellation
>  point has to go as well.
> 
>  This has probably worked before rL255992: With the calls for the
>  explicit barrier, it was sure that all threads passed a barrier before
> exiting.
> 
>  Reported by Simon Convent and Joachim Protze!
> 
>  Differential Revision: https://reviews.llvm.org/D30088
> 
>  Modified:
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/test/OpenMP/cancel_codegen.cpp
> cfe/trunk/test/OpenMP/cancellation_point_codegen.cpp


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2017-02-27 Thread Hahnfeld, Jonas via cfe-commits

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
>
> Merged to 4.0 in r296139 as requested on the r295473 commit thread.
>
> On Fri, Feb 17, 2017 at 10:32 AM, Jonas Hahnfeld via cfe-commits  comm...@lists.llvm.org> wrote:
> > Author: hahnfeld
> > Date: Fri Feb 17 12:32:58 2017
> > New Revision: 295474
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=295474&view=rev
> > Log:
> > [OpenMP] Fix cancellation point in task with no cancel
> >
> > With tasks, the cancel may happen in another task. This has a
> > different region info which means that we can't find it here.
> >
> > Differential Revision: https://reviews.llvm.org/D30091
> >
> > Modified:
> > cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> > cfe/trunk/test/OpenMP/cancellation_point_codegen.cpp
> >
> > Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> > URL:
> > http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CGOpenMPRunt
> > ime.cpp?rev=295474&r1=295473&r2=295474&view=diff
> >
> ==
> 
> > 
> > --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Fri Feb 17 12:32:58
> 2017
> > @@ -4716,7 +4716,9 @@ void CGOpenMPRuntime::emitCancellationPo
> >// global_tid, kmp_int32 cncl_kind);
> >if (auto *OMPRegionInfo =
> >dyn_cast_or_null(CGF.CapturedStmtInfo)) {
> > -if (OMPRegionInfo->hasCancel()) {
> > +// For 'cancellation point taskgroup', the task region info may not 
> > have a
> > +// cancel. This may instead happen in another adjacent task.
> > +if (CancelRegion == OMPD_taskgroup || OMPRegionInfo->hasCancel())
> > + {
> >llvm::Value *Args[] = {
> >emitUpdateLocation(CGF, Loc), getThreadID(CGF, Loc),
> >CGF.Builder.getInt32(getCancellationKind(CancelRegion))};
> >
> > Modified: cfe/trunk/test/OpenMP/cancellation_point_codegen.cpp
> > URL:
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/cancellation
> > _point_codegen.cpp?rev=295474&r1=295473&r2=295474&view=diff
> >
> ==
> 
> > 
> > --- cfe/trunk/test/OpenMP/cancellation_point_codegen.cpp (original)
> > +++ cfe/trunk/test/OpenMP/cancellation_point_codegen.cpp Fri Feb 17
> > +++ 12:32:58 2017
> > @@ -78,6 +78,12 @@ for (int i = 0; i < argc; ++i) {  }  // CHECK: call
> > i8* @__kmpc_omp_task_alloc(  // CHECK: call i32 @__kmpc_omp_task(
> > +#pragma omp task
> > +{
> > +#pragma omp cancellation point taskgroup } // CHECK: call i8*
> > +@__kmpc_omp_task_alloc( // CHECK: call i32 @__kmpc_omp_task(
> >  #pragma omp parallel sections
> >  {
> >{
> > @@ -118,6 +124,15 @@ for (int i = 0; i < argc; ++i) {
> >
> >  // CHECK: define internal i32 @{{[^(]+}}(i32
> >  // CHECK: [[RES:%.+]] = call i32 @__kmpc_cancellationpoint(%ident_t*
> {{[^,]+}}, i32 {{[^,]+}}, i32 4)
> > +// CHECK: [[CMP:%.+]] = icmp ne i32 [[RES]], 0
> > +// CHECK: br i1 [[CMP]], label %[[EXIT:[^,]+]],
> > +// CHECK: [[EXIT]]
> > +// CHECK: br label %[[RETURN:.+]]
> > +// CHECK: [[RETURN]]
> > +// CHECK: ret i32 0
> > +
> > +// CHECK: define internal i32 @{{[^(]+}}(i32
> > +// CHECK: [[RES:%.+]] = call i32 @__kmpc_cancellationpoint(%ident_t*
> {{[^,]+}}, i32 {{[^,]+}}, i32 4)
> >  // CHECK: [[CMP:%.+]] = icmp ne i32 [[RES]], 0
> >  // CHECK: br i1 [[CMP]], label %[[EXIT:[^,]+]],
> >  // CHECK: [[EXIT]]
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-11-03 Thread Hahnfeld, Jonas via cfe-commits

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.

 

Finally: Why didn’t the other bots point to this problem?!?

 

Cheers,

Jonas

 

From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Galina Kistanova via cfe-commits
Sent: Tuesday, November 01, 2016 7:29 PM
To: Samuel F Antao
Cc: cfe-commits
Subject: Re: r285326 - [Driver][OpenMP] Add support to create jobs for 
unbundling actions.

 

http://lab.llvm.org:8011/builders/clang-3stage-ubuntu/builds/128/steps/cmake-configure/logs/stdio

-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4

The code itself seems fine. The similar builder that uses the ToT Clang does 
not generate any warnings.
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/107

Thanks

Galina

 

On Mon, Oct 31, 2016 at 6:26 PM, Samuel F Antao  wrote:

Hi Galina,

 

Thanks for letting me know. Can you tell me which compiler (kind and version) 
is used in the buildbot slave? Looks like that compiler is not doing what it 
should, so I need to be able to test a workaround.

 

We have  

 

virtual void ConstructJob(Compilation &C, const JobAction &JA,
const InputInfo &Output,
const InputInfoList &Inputs,
const llvm::opt::ArgList &TCArgs,
const char *LinkingOutput) const = 0;

 

which is the signature of ConstructJob that should be overwritten, so we are 
not hiding anything. And in Action.cpp we have an unreachable statement, so no 
need for return. So, the code seems to be okay, but we can probably massage the 
code a little to silence the compiler you are using.

 

Thanks!

Samuel

 

- Original message -
From: Galina Kistanova 
To: Samuel F Antao/Watson/IBM@IBMUS
Cc: cfe-commits 
Subject: Re: r285326 - [Driver][OpenMP] Add support to create jobs for 
unbundling actions.
Date: Tue, Nov 1, 2016 12:59 AM
  

Hi Samuel,

Looks like this revision introduced warning to one of our builders:
http://lab.llvm.org:8011/builders/clang-3stage-ubuntu/builds/67/steps/build-stage3-clang/logs/warnings%20%28830%29

Please have a look at this?

Thanks

Galina

  

On Thu, Oct 27, 2016 at 11:14 AM, Samuel Antao via cfe-commits 
 wrote: 

Author: sfantao
Date: Thu Oct 27 13:14:55 2016
New Revision: 285326

URL: http://llvm.org/viewvc/llvm-project?rev=285326&view=rev
Log:
[Driver][OpenMP] Add support to create jobs for unbundling actions.

Summary:
This patch adds the support to create jobs for the `OffloadBundlingAction` 
which will invoke the `clang-offload-bundler` tool to unbundle input files.

Unlike other actions, unbundling actions have multiple outputs. Therefore, this 
patch adds the required changes to have a variant of `Tool::ConstructJob` with 
multiple outputs.

The way the naming of the results is implemented is also slightly modified so 
that the same action can use a different offloading prefix for each use by the 
different offloading actions.

With this patch, it is possible to compile a functional OpenMP binary with 
offloading support, even with separate compilation.

Reviewers: echristo, tra, jlebar, ABataev, hfinkel

Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, 
andreybokhanko, arpith-jacob, carlo.bertolli, caomhin

Differential Revision: https://reviews.llvm.org/D21857

Modified:
cfe/trunk/include/clang/Driver/Action.h
cfe/trunk/include/clang/Driver/Driver.h
cfe/trunk/include/clang/Driver/Tool.h
cfe/trunk/lib/Driver/Action.cpp
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/Tool.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Driver/Tools.h
cfe/trunk/test/Driver/cuda-bindings.cu
cfe/trunk/test/Driver/openmp-offload.c
cfe/trunk/test/Driver/opt-record.c

Modified: cfe/trunk/include/clang/Driver/Action.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Action.h?rev=285326&r1=285325&r2=285326&view=diff
==
--- cfe/trunk/include/clang/Driver/Action.h (original)
+++ cfe/trunk/include/clang/Driver/Action.h Thu Oct 27 13:14:55 2016
@@ -157,9 +157,12 @@ public:
   /// Return a string containing the offload kind of the action.
   std::string getOffloadingKindPrefix() const;
   /// Return a string that can be used as prefix in order to generate unique
-  /// files for each offloading kind.
-  std::string
-  getOffloadingFileNamePrefix(llvm::StringRef NormalizedTriple) const;
+  /// files for each offloading kind. By default, no prefix is used for
+  /// non-device kinds, except if \a CreatePrefixForHost is set.
+  static std::string
+  GetOffloadingFileNamePrefix(OffloadKind Kind,
+

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

2016-11-03 Thread Hahnfeld, Jonas via cfe-commits

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 
the attached small code:
$ g++ --version

g++ (GCC) 6.2.0

[…]

$ g++ -Woverloaded-virtual virtual-name-hiding.cpp -o virtual-name-hiding.exe

virtual-name-hiding.cpp:2:16: warning: ‘virtual void Base::test(const long 
int&)’ was hidden [-Woverloaded-virtual]

   virtual void test(const long &l);

^~~~

virtual-name-hiding.cpp:7:16: warning:   by ‘virtual void Child::test(const 
int&)’ [-Woverloaded-virtual]

   virtual void test(const int &a) override { };

^~~~

 

Regards,

Jonas

 

From: Samuel F Antao [mailto:sfan...@us.ibm.com] 
Sent: Thursday, November 03, 2016 1:04 PM
To: Hahnfeld, Jonas
Cc: cfe-commits@lists.llvm.org; gkistan...@gmail.com
Subject: Re: RE: r285326 - [Driver][OpenMP] Add support to create jobs for 
unbundling actions.

 

Hi Jonas,

 

I think that the code is correct. Is probably some bug in the compiler. We are 
not hiding anything - the compiler is checking against the wrong virtual 
function (using the wrong signature).

 

I am in process to compile the same version of gcc the bot is using to see if 
there is any massagin in the code that can be done to silence that.

 

Thanks!

Samuel

 

- Original message -
From: "Hahnfeld, Jonas" 
To: Galina Kistanova , Samuel F Antao/Watson/IBM@IBMUS
Cc: "cfe-commits@lists.llvm.org" 
Subject: RE: r285326 - [Driver][OpenMP] Add support to create jobs for 
unbundling actions.
Date: Thu, Nov 3, 2016 11:53 AM
 

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.

 

Finally: Why didn’t the other bots point to this problem?!?

 

Cheers,

Jonas

 

From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Galina Kistanova via cfe-commits
Sent: Tuesday, November 01, 2016 7:29 PM
To: Samuel F Antao
Cc: cfe-commits
Subject: Re: r285326 - [Driver][OpenMP] Add support to create jobs for 
unbundling actions.

 

http://lab.llvm.org:8011/builders/clang-3stage-ubuntu/builds/128/steps/cmake-configure/logs/stdio

-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4

The code itself seems fine. The similar builder that uses the ToT Clang does 
not generate any warnings.
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/107

Thanks

Galina

 

On Mon, Oct 31, 2016 at 6:26 PM, Samuel F Antao  wrote:

Hi Galina,

 

Thanks for letting me know. Can you tell me which compiler (kind and version) 
is used in the buildbot slave? Looks like that compiler is not doing what it 
should, so I need to be able to test a workaround.

 

We have  

 

virtual void ConstructJob(Compilation &C, const JobAction &JA,
const InputInfo &Output,
const InputInfoList &Inputs,
const llvm::opt::ArgList &TCArgs,
const char *LinkingOutput) const = 0;

 

which is the signature of ConstructJob that should be overwritten, so we are 
not hiding anything. And in Action.cpp we have an unreachable statement, so no 
need for return. So, the code seems to be okay, but we can probably massage the 
code a little to silence the compiler you are using.

 

Thanks!

Samuel

 

- Original message -
From: Galina Kistanova 
To: Samuel F Antao/Watson/IBM@IBMUS
Cc: cfe-commits 
Subject: Re: r285326 - [Driver][OpenMP] Add support to create jobs for 
unbundling actions.
Date: Tue, Nov 1, 2016 12:59 AM
  

Hi Samuel,

Looks like this revision introduced warning to one of our builders:
http://lab.llvm.org:8011/builders/clang-3stage-ubuntu/builds/67/steps/build-stage3-clang/logs/warnings%20%28830%29

Please have a look at this?

Thanks

Galina

  

On Thu, Oct 27, 2016 at 11:14 AM, Samuel Antao via cfe-commits 
 wrote: 

Author: sfantao
Date: Thu Oct 27 13:14:55 2016
New Revision: 285326

URL: http://llvm.org/viewvc/llvm-project?rev=285326&view=rev
Log:
[Driver][OpenMP] Add support to create jobs for unbundling actions.

Summary:
This patch adds the support to create jobs for the `OffloadBundlingAction` 
which will invoke the `clang-offload-bundler` tool to unbundle input files.

Unlike other actions, unbundling actions have multiple outputs. Therefore, this 
patch adds the required changes to have a variant of `Tool::ConstructJob` with 
multiple outputs.

The way the naming of the results is implemented is also slightly modified so 
that the same action can use a different offloading prefix for each use by the 
different offloading actions.

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

2015-10-21 Thread Hahnfeld, Jonas via cfe-commits

> -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++.
>
> Author: ericwf
> Date: Wed Oct 14 14:54:03 2015
> New Revision: 250319
>
> URL: http://llvm.org/viewvc/llvm-project?rev=250319&view=rev
> Log:
> [libcxx] Make it drastically simpler to link libc++.
[...]
>  if (LIBCXX_INSTALL_LIBRARY)
>install(TARGETS cxx
>  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
>  ARCHIVE DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
>  )
> +  # NOTE: This install command must go after the cxx install command
> + otherwise  # it will not be executed after the library symlinks are 
> installed.
> +  if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
> +install(FILES "$"
> +  DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
> +  COMPONENT libcxx)
> +  endif()
>  endif()

Generator expressions in install(FILES) are only allowed since CMake 3.0 
(https://cmake.org/cmake/help/v3.0/release/3.0.0.html#commands).
The current minimum for libcxx is 2.8, so this should either be raised or we 
have to find another possibility of writing this install command...

Greetings
Jonas


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-10-22 Thread Hahnfeld, Jonas via cfe-commits

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 
should be the minimum required version when building all LLVM projects.

Cheers,
Jonas

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Eric Fiselier via cfe-commits
> Sent: Thursday, October 22, 2015 11:24 PM
> To: cfe-commits@lists.llvm.org
> Subject: [libcxx] r251065 - Dont required CMake 3 to install a linker script
>
> Author: ericwf
> Date: Thu Oct 22 16:24:01 2015
> New Revision: 251065
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251065&view=rev
> Log:
> Dont required CMake 3 to install a linker script
>
> Modified:
> libcxx/trunk/lib/CMakeLists.txt
>
> Modified: libcxx/trunk/lib/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-
> project/libcxx/trunk/lib/CMakeLists.txt?rev=251065&r1=251064&r2=251065&
> view=diff
> ==
> 
> --- libcxx/trunk/lib/CMakeLists.txt (original)
> +++ libcxx/trunk/lib/CMakeLists.txt Thu Oct 22 16:24:01 2015
> @@ -154,7 +154,6 @@ if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
>)
>  endif()
>
> -
>  if (LIBCXX_INSTALL_LIBRARY)
>install(TARGETS cxx
>  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
> @@ -163,7 +162,9 @@ if (LIBCXX_INSTALL_LIBRARY)
># NOTE: This install command must go after the cxx install command
> otherwise
># it will not be executed after the library symlinks are installed.
>if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
> -install(FILES "$"
> +# Replace the libc++ filename with $
> +# after we required CMake 3.0.
> +install(FILES
> "${CMAKE_CURRENT_BINARY_DIR}/libc++${CMAKE_SHARED_LIBRARY_SUFF
> IX}"
>DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
>COMPONENT libcxx)
>endif()
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-10-23 Thread Hahnfeld, Jonas via cfe-commits

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 being patient and sorry for the failed first attempt. I think I 
fixed it in r251100.



I swear I'm normally more careful.



/Eric



On Thu, Oct 22, 2015 at 8:34 PM, Hahnfeld, Jonas  
wrote:

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
should be the minimum required version when building all LLVM projects.

Cheers,
Jonas


> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Eric Fiselier via cfe-commits
> Sent: Thursday, October 22, 2015 11:24 PM
> To: cfe-commits@lists.llvm.org
> Subject: [libcxx] r251065 - Dont required CMake 3 to install a linker script
>
> Author: ericwf
> Date: Thu Oct 22 16:24:01 2015
> New Revision: 251065
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251065 
>  &view=rev
> Log:
> Dont required CMake 3 to install a linker script
>
> Modified:
> libcxx/trunk/lib/CMakeLists.txt
>
> Modified: libcxx/trunk/lib/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-
> project/libcxx/trunk/lib/CMakeLists.txt?rev=251065&r1=251064&r2=251065&
> view=diff
> ==
> 
> --- libcxx/trunk/lib/CMakeLists.txt (original)
> +++ libcxx/trunk/lib/CMakeLists.txt Thu Oct 22 16:24:01 2015
> @@ -154,7 +154,6 @@ if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
>)
>  endif()
>
> -
>  if (LIBCXX_INSTALL_LIBRARY)
>install(TARGETS cxx
>  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
> @@ -163,7 +162,9 @@ if (LIBCXX_INSTALL_LIBRARY)
># NOTE: This install command must go after the cxx install command
> otherwise
># it will not be executed after the library symlinks are installed.
>if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
> -install(FILES "$"
> +# Replace the libc++ filename with $
> +# after we required CMake 3.0.
> +install(FILES
> "${CMAKE_CURRENT_BINARY_DIR}/libc++${CMAKE_SHARED_LIBRARY_SUFF
> IX}"
>DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
>COMPONENT libcxx)
>endif()
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits





smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-08-12 Thread Hahnfeld, Jonas via cfe-commits

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
> are forwarded to host and device frontends.
>
> Hi,
>
> On Tue, Aug 9, 2016 at 8:27 PM, Samuel Antao via cfe-commits  comm...@lists.llvm.org> wrote:
> > Author: sfantao
> > Date: Tue Aug  9 12:27:24 2016
> > New Revision: 278140
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=278140&view=rev
> > Log:
> > [CUDA] Regression test to make sure C++ include path are forwarded to
> host and device frontends.
> >
> > Summary: Add test to detect the C++ include paths are passed to both
> CUDA host and device frontends.
> >
> > Reviewers: tra
> >
> > Subscribers: cfe-commits
> >
> > Differential Revision: https://reviews.llvm.org/D22946
> >
> > Modified:
> > cfe/trunk/test/Driver/cuda-detect.cu
> >
> > Modified: cfe/trunk/test/Driver/cuda-detect.cu
> > URL:
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cuda-detect.
> > cu?rev=278140&r1=278139&r2=278140&view=diff
> >
> ==
> 
> > 
> > --- cfe/trunk/test/Driver/cuda-detect.cu (original)
> > +++ cfe/trunk/test/Driver/cuda-detect.cu Tue Aug  9 12:27:24 2016
> > @@ -72,6 +72,11 @@
> >  // RUN:   | FileCheck %s -check-prefix COMMON \
> >  // RUN: -check-prefix NOCUDAINC -check-prefix NOLIBDEVICE
> >
> > +// Verify that C++ include paths are passed for both host and device
> frontends.
> > +// RUN: %clang -### -target x86_64-linux-gnu %s \ // RUN:
> > +--sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree2 2>&1 \ // RUN: |
> > +FileCheck %s --check-prefix CHECK-CXXINCLUDE
> > +
> >  // CHECK: Found CUDA installation: {{.*}}/Inputs/CUDA/usr/local/cuda
> > // NOCUDA-NOT: Found CUDA installation:
> >
> > @@ -92,3 +97,8 @@
> >  // CUDAINC-SAME: "-include" "__clang_cuda_runtime_wrapper.h"
> >  // NOCUDAINC-NOT: "-include" "__clang_cuda_runtime_wrapper.h"
> >  // COMMON-SAME: "-x" "cuda"
> > +// CHECK-CXXINCLUDE: clang{{.*}} "-cc1" "-triple" "nvptx64-nvidia-cuda"
> > +// CHECK-CXXINCLUDE-SAME: {{.*}}"-internal-isystem"
> "{{.+}}/include/c++/4.8"
> > +// CHECK-CXXINCLUDE: clang{{.*}} "-cc1" "-triple" "x86_64--linux-gnu"
> > +// CHECK-CXXINCLUDE-SAME: {{.*}}"-internal-isystem"
> "{{.+}}/include/c++/4.8"
> > +// CHECK-CXXINCLUDE: ld{{.*}}"
>
> This needs -stdlib=libstdc++ otherwise it fails on hosts defaulting to 
> libc++.
>
> ismail
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Right, I also noticed that but forgot to commit the fix.
Should work with r278497.

Thanks,
Jonas


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-02-13 Thread Hahnfeld, Jonas via cfe-commits

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 should be implemented, maybe 
similar to Linux::AddClangCXXStdlibIncludeArgs.
(ToolChain::AddClangCXXStdlibIncludeArgs states that the implementation of 
passing down -stdlib is legacy anyway)

With regard to the test case: First I think this currently won't ever be 
executed because it resists in the root directory.
And second: Testing the default stdlib chosen by clang is fragile now because 
it can be changed by CLANG_DEFAULT_CXX_STDLIB which would fail all the tests!
I already had this problem with FreeBSD and NetBSD. As a solution we could 
think about implementing -stdlib=default which would take the architecture 
default instead...

Greetings,
Jonas

Von: cfe-commits  im Auftrag von Tim 
Northover via cfe-commits 
Gesendet: Freitag, 12. Februar 2016 23:30
An: cfe-commits@lists.llvm.org
Betreff: r260755 - Darwin: pass -stdlib=libc++ down to cc1 whenever we're 
targeting libc++

Author: tnorthover
Date: Fri Feb 12 16:30:42 2016
New Revision: 260755

URL: http://llvm.org/viewvc/llvm-project?rev=260755&view=rev
Log:
Darwin: pass -stdlib=libc++ down to cc1 whenever we're targeting libc++

Recent refactoring meant it only got passed down when explicitly specified,
which breaks header search on Darwin.

Added:
cfe/trunk/darwin-stdlib.cpp
Modified:
cfe/trunk/lib/Driver/ToolChains.cpp

Added: cfe/trunk/darwin-stdlib.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/darwin-stdlib.cpp?rev=260755&view=auto
==
--- cfe/trunk/darwin-stdlib.cpp (added)
+++ cfe/trunk/darwin-stdlib.cpp Fri Feb 12 16:30:42 2016
@@ -0,0 +1,16 @@
+// RUN: %clang -target x86_64-apple-darwin -arch arm64 
-miphoneos-version-min=7.0 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-LIBCXX
+// RUN: %clang -target x86_64-apple-darwin -mmacosx-version-min=10.8 %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-LIBSTDCXX
+// RUN: %clang -target x86_64-apple-darwin -mmacosx-version-min=10.9 %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-LIBCXX
+// RUN: %clang -target x86_64-apple-darwin -arch armv7s 
-miphoneos-version-min=6.1 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-LIBSTDCXX
+// RUN: %clang -target x86_64-apple-darwin -arch armv7s 
-miphoneos-version-min=7.0 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-LIBCXX
+// RUN: %clang -target x86_64-apple-darwin -arch armv7k %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-LIBCXX
+
+// The purpose of this test is that the libc++ headers should be found
+// properly. At the moment this is done by passing -stdlib=libc++ down to the
+// cc1 invocation. If and when we change to finding them in the driver this 
test
+// should reflect that.
+
+// CHECK-LIBCXX: -stdlib=libc++
+
+// CHECK-LIBSTDCXX-NOT: -stdlib=libc++
+// CHECK-LIBSTDCXX-NOT: -stdlib=libstdc++

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=260755&r1=260754&r2=260755&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Fri Feb 12 16:30:42 2016
@@ -1030,6 +1030,7 @@ DerivedArgList *Darwin::TranslateArgs(co
   const char *BoundArch) const {
   // First get the generic Apple args, before moving onto Darwin-specific ones.
   DerivedArgList *DAL = MachO::TranslateArgs(Args, BoundArch);
+  const OptTable &Opts = getDriver().getOpts();

   // If no architecture is bound, none of the translations here are relevant.
   if (!BoundArch)
@@ -1060,6 +1061,11 @@ DerivedArgList *Darwin::TranslateArgs(co
 }
   }

+  if (!Args.getLastArg(options::OPT_stdlib_EQ) &&
+  GetDefaultCXXStdlibType() == ToolChain::CST_Libcxx)
+DAL->AddJoinedArg(nullptr, Opts.getOption(options::OPT_stdlib_EQ),
+  "libc++");
+
   // Validate the C++ standard library choice.
   CXXStdlibType Type = GetCXXStdlibType(*DAL);
   if (Type == ToolChain::CST_Libcxx) {


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-02-15 Thread Hahnfeld, Jonas via cfe-commits

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++
> 
> Hi Jonas,
> 
> Thanks for looking at the patch!
> 
> > On 13 Feb 2016, at 01:26, Hahnfeld, Jonas 
> wrote:
> > 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…
> 
> No worries. I think it only triggered in the stage 2 Green Dragon bots (when
> the compiler was actually used to try and build some ASAN test bits).
> 
> > To the change: I think the explicit passing of -stdlib=libc++ will override
> CLANG_DEFAULT_CXX_STDLIB on Darwin.
> 
> Good point, sorry about that. I thought I was being cunning by skipping the
> extra bits of GetCXXStdlibType.
> 
> > Instead, Darwin::AddClangCXXStdlibIncludeArgs should be implemented,
> maybe similar to Linux::AddClangCXXStdlibIncludeArgs.
> 
> I did look into that, but there was quite a bit of logic to be refactored and 
> I
> was very much in fire-fighting mode at the time (everything was falling down
> around me on Friday). I’ll see what I can do if things quiet down.
> 
> > With regard to the test case: First I think this currently won't ever be
> executed because it resists in the root directory.
> 
> Good point. Don’t know how I managed to do that.
> 
> > And second: Testing the default stdlib chosen by clang is fragile now
> because it can be changed by CLANG_DEFAULT_CXX_STDLIB which would fail
> all the tests!
> 
> > I already had this problem with FreeBSD and NetBSD. As a solution we
> could think about implementing -stdlib=default which would take the
> architecture default instead…
> 
> So what have you done in the meantime? I think I’d prefer a test that’s noisy
> in less common configurations over no test at all.

Not much on this idea - but I do still like it after thinking a bit about some 
-stdlib=default for the tests. Let me see if I can implement this ;-)
Yep, tests are great, especially if they can catch problems for other platforms.

> 
> Anyway, I think I’ve fixed the big mistakes in r260898. I’ll see what I can do
> about the refactoring this week.

Looks good. Thanks,
Jonas

> 
> Cheers.
> 
> Tim.


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-05-26 Thread Hahnfeld, Jonas via cfe-commits

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 feature tests. That's what we 
tried to do within the ompt.h header and we had to add an exception because 
Clang 3.8 reported 201307 but didn't support #pragma omp declare target (which 
it only recently gained).
Would you be ok reverting this commit?

Cheers,
Jonas

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Alexey Bataev via cfe-commits
> Sent: Thursday, May 26, 2016 6:56 AM
> To: cfe-commits@lists.llvm.org
> Subject: r270822 - [OPENMP] Set '_OPENMP' macro to '201511' value to
> reflect support for
>
> Author: abataev
> Date: Wed May 25 23:56:05 2016
> New Revision: 270822
>
> URL: http://llvm.org/viewvc/llvm-project?rev=270822&view=rev
> Log:
> [OPENMP] Set '_OPENMP' macro to '201511' value to reflect support for
> OpenMP 4.5.
>
> According to OpenMP 4.5 the _OPENMP macro name is defined to have the
> decimal value mm where  and mm are the year and month
> designations of the version of the OpenMP API that the implementation
> supports. Clang supports OpenMP 4.5 so updated value of _OPENMP macro
> to 201511.
>
> Modified:
> cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> cfe/trunk/test/OpenMP/predefined_macro.c
>
> Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=270822&r1=27082
> 1&r2=270822&view=diff
> ==
> 
> --- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
> +++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Wed May 25 23:56:05 2016
> @@ -928,7 +928,7 @@ static void InitializePredefinedMacros(c
>  //   macro name is defined to have the decimal value mm where
>  //    and mm are the year and the month designations of the
>  //   version of the OpenMP API that the implementation support.
> -Builder.defineMacro("_OPENMP", "201307");
> +Builder.defineMacro("_OPENMP", "201511");
>}
>
>// CUDA device path compilaton
>
> Modified: cfe/trunk/test/OpenMP/predefined_macro.c
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/OpenMP/predefined_macro.c?rev=270822&r1=2708
> 21&r2=270822&view=diff
> ==
> 
> --- cfe/trunk/test/OpenMP/predefined_macro.c (original)
> +++ cfe/trunk/test/OpenMP/predefined_macro.c Wed May 25 23:56:05 2016
> @@ -5,7 +5,7 @@
>  // -fopenmp option is specified
>  #ifndef _OPENMP
>  #error "No _OPENMP macro is defined with -fopenmp option"
> -#elsif _OPENMP != 201307
> +#elsif _OPENMP != 201511
>  #error "_OPENMP has incorrect value"
>  #endif //_OPENMP
>  #else
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-05-26 Thread Hahnfeld, Jonas via cfe-commits

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: Alexey Bataev [mailto:a.bat...@hotmail.com]
> Sent: Thursday, May 26, 2016 9:57 AM
> To: Hahnfeld, Jonas
> Cc: cfe-commits@lists.llvm.org; Samuel F Antao
> Subject: Re: r270822 - [OPENMP] Set '_OPENMP' macro to '201511' value to
> reflect support for
> 
> Hi,
> 
> I thought about this. Will it be good for you if I add and option '-fopenmp-
> version=[31|40|45]', which will allow you to choose the supported version?
> For now it will just modify the value of _OPENMP, later support can be
> extended for better compatibility.
> 
> Best regards,
> Alexey Bataev
> =
> Software Engineer
> Intel Compiler Team
> 
> 26.05.2016 10:46, Hahnfeld, Jonas пишет:
> > 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 feature tests. That's
> > what we tried to do within the ompt.h header and we had to add an
> > exception because Clang 3.8 reported 201307 but didn't support #pragma
> > omp declare target (which it only recently gained).
> > Would you be ok reverting this commit?
> >
> > Cheers,
> > Jonas
> >
> >> -Original Message-
> >> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On
> >> Behalf Of Alexey Bataev via cfe-commits
> >> Sent: Thursday, May 26, 2016 6:56 AM
> >> To: cfe-commits@lists.llvm.org
> >> Subject: r270822 - [OPENMP] Set '_OPENMP' macro to '201511' value to
> >> reflect support for
> >>
> >> Author: abataev
> >> Date: Wed May 25 23:56:05 2016
> >> New Revision: 270822
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=270822&view=rev
> >> Log:
> >> [OPENMP] Set '_OPENMP' macro to '201511' value to reflect support for
> >> OpenMP 4.5.
> >>
> >> According to OpenMP 4.5 the _OPENMP macro name is defined to have
> the
> >> decimal value mm where  and mm are the year and month
> >> designations of the version of the OpenMP API that the implementation
> >> supports. Clang supports OpenMP 4.5 so updated value of _OPENMP
> macro
> >> to 201511.
> >>
> >> Modified:
> >>  cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> >>  cfe/trunk/test/OpenMP/predefined_macro.c
> >>
> >> Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> >> URL: http://llvm.org/viewvc/llvm-
> >>
> project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=270822&r1=270
> >> 82
> >> 1&r2=270822&view=diff
> >>
> ==
> >> 
> >> --- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
> >> +++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Wed May 25 23:56:05
> >> +++ 2016
> >> @@ -928,7 +928,7 @@ static void InitializePredefinedMacros(c
> >>   //   macro name is defined to have the decimal value mm where
> >>   //    and mm are the year and the month designations of the
> >>   //   version of the OpenMP API that the implementation support.
> >> -Builder.defineMacro("_OPENMP", "201307");
> >> +Builder.defineMacro("_OPENMP", "201511");
> >> }
> >>
> >> // CUDA device path compilaton
> >>
> >> Modified: cfe/trunk/test/OpenMP/predefined_macro.c
> >> URL: http://llvm.org/viewvc/llvm-
> >>
> project/cfe/trunk/test/OpenMP/predefined_macro.c?rev=270822&r1=2708
> >> 21&r2=270822&view=diff
> >>
> ==
> >> 
> >> --- cfe/trunk/test/OpenMP/predefined_macro.c (original)
> >> +++ cfe/trunk/test/OpenMP/predefined_macro.c Wed May 25 23:56:05
> 2016
> >> @@ -5,7 +5,7 @@
> >>   // -fopenmp option is specified
> >>   #ifndef _OPENMP
> >>   #error "No _OPENMP macro is defined with -fopenmp option"
> >> -#elsif _OPENMP != 201307
> >> +#elsif _OPENMP != 201511
> >>   #error "_OPENMP has incorrect value"
> >>   #endif //_OPENMP
> >>   #else
> >>
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits



smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-05-26 Thread Hahnfeld, Jonas via cfe-commits

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: Thursday, May 26, 2016 10:03 AM
> To: Simon Atanasyan
> Cc: cfe-commits
> Subject: Re: r270373 - [driver][mips] Support new versions of MIPS
> CodeScape toolchains
>
> Hi,
>
> I think this is because I enable libc++ by default with -
> DLLVM_ENABLE_LIBCXX=ON , so this tests need an explicit -stdlib=libstdc++
>
> ismail
>
>
> On Thu, May 26, 2016 at 10:08 AM, Simon Atanasyan
>  wrote:
> > I'm trying to reproduce the problem but without success yet. And all
> > buildbots available to me are green. So no ideas right now.
> >
> > By the way, as far as I can see you use some sort of build system
> > probably to get rpm package. Right? Could you try to build Clang by
> > hand (http://clang.llvm.org/get_started.html) and run the tests. Is
> > the problem reproduced in that case?
> >
> > On Thu, May 26, 2016 at 10:01 AM, Ismail Donmez 
> wrote:
> >> Any ideas what's going on?
> >>
> >> On Wed, May 25, 2016 at 1:35 PM, Ismail Donmez 
> wrote:
> >>> Hi,
> >>>
> >>> On Wed, May 25, 2016 at 1:32 PM, Simon Atanasyan
>  wrote:
>  Hi,
> 
>  Thanks for the information. One more question. Does the following
> folder exist?
> 
> 
> /home/abuild/rpmbuild/BUILD/llvm/tools/clang/test/Driver/Inputs/mip
>  s_img_v2_tree/lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img
>  -linux-gnu/include/c++/4.9.2
> 
> >>>
> >>> Yes :
> >>>
> >>> :/ # ls
> >>>
> /home/abuild/rpmbuild/BUILD/llvm/tools/clang/test/Driver/Inputs/mips
> >>> _img_v2_tree/lib/gcc/mips-img-linux-gnu/4.9.2/../../../../mips-img-l
> >>> inux-gnu/include/c++/4.9.2
> >>> mips-img-linux-gnu
> >
> > --
> > Simon
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-05-30 Thread Hahnfeld, Jonas via cfe-commits

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: r270373 - [driver][mips] Support new versions of MIPS
> CodeScape toolchains
>
> It does, thanks!
>
> On Thu, May 26, 2016 at 3:35 PM, Simon Atanasyan 
> wrote:
> > I hope r270842 fixes the problem.
> >
> > Thanks a lot for your help.
> >
> > On Thu, May 26, 2016 at 11:28 AM, Ismail Donmez 
> wrote:
> >> Indeed the problematic option is -DCLANG_DEFAULT_CXX_STDLIB=libc++
> ,
> >> thanks Jonas!
> >>
> >> On Thu, May 26, 2016 at 11:19 AM, Hahnfeld, Jonas
> >>  wrote:
> >>> 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: Thursday, May 26, 2016 10:03 AM
>  To: Simon Atanasyan
>  Cc: cfe-commits
>  Subject: Re: r270373 - [driver][mips] Support new versions of MIPS
>  CodeScape toolchains
> 
>  Hi,
> 
>  I think this is because I enable libc++ by default with -
>  DLLVM_ENABLE_LIBCXX=ON , so this tests need an explicit
>  -stdlib=libstdc++
> >
> > --
> > Simon Atanasyan


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: 3.8 Merge Request: r259776

2016-05-30 Thread Hahnfeld, Jonas via cfe-commits

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: Bataev, Alexey (a.bat...@hotmail.com); llvm-comm...@lists.llvm.org
> Subject: RE: 3.8 Merge Request: r259776
> 
> Ping. I would really much like to see this (and possibly other OpenMP
bugs)
> fixed for 3.8.1.
> 
> Thanks,
> Jonas
> 
> > -Original Message-
> > From: Tom Stellard [mailto:t...@stellard.net]
> > Sent: Thursday, May 19, 2016 7:37 PM
> > To: Hahnfeld, Jonas
> > Cc: llvm-comm...@lists.llvm.org; Bataev, Alexey (a.bat...@hotmail.com)
> > Subject: Re: 3.8 Merge Request: r259776
> >
> > On Thu, May 19, 2016 at 11:25:43AM +, Hahnfeld, Jonas wrote:
> > > This bug also exists in 3.8.0. Alexey already agreed to merge this
> > > back
> in
> > > March:
> > > http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-
> > 20160314/152975.html
> > >
> > > Alexey, are there other OpenMP commits needed for 3.8.1?
> > >
> > Hi,
> >
> > I would also like Richard to take a look at this one to.
> >
> > Richard, does this look OK to merge:
> >
> > reviews.llvm.org/rL259776
> >
> > -Tom
> >
> > > Cheers,
> > > Jonas
> >



smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: 3.8 Merge Request: r259776

2016-05-30 Thread Hahnfeld, Jonas via cfe-commits

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 Tom wants an approve from Richard.
> Ping him!
> 
> Best regards,
> Alexey Bataev
> =
> Software Engineer
> Intel Compiler Team
> 
> 
> 
> 30.05.2016 14:19, Hahnfeld, Jonas пишет:
> > 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: Bataev, Alexey (a.bat...@hotmail.com);
> >> llvm-comm...@lists.llvm.org
> >> Subject: RE: 3.8 Merge Request: r259776
> >>
> >> Ping. I would really much like to see this (and possibly other OpenMP
> > bugs)
> >> fixed for 3.8.1.
> >>
> >> Thanks,
> >> Jonas
> >>
> >>> -Original Message-
> >>> From: Tom Stellard [mailto:t...@stellard.net]
> >>> Sent: Thursday, May 19, 2016 7:37 PM
> >>> To: Hahnfeld, Jonas
> >>> Cc: llvm-comm...@lists.llvm.org; Bataev, Alexey
> >>> (a.bat...@hotmail.com)
> >>> Subject: Re: 3.8 Merge Request: r259776
> >>>
> >>> On Thu, May 19, 2016 at 11:25:43AM +, Hahnfeld, Jonas wrote:
>  This bug also exists in 3.8.0. Alexey already agreed to merge this
>  back
> >> in
>  March:
>  http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-
> >>> 20160314/152975.html
>  Alexey, are there other OpenMP commits needed for 3.8.1?
> 
> >>> Hi,
> >>>
> >>> I would also like Richard to take a look at this one to.
> >>>
> >>> Richard, does this look OK to merge:
> >>>
> >>> reviews.llvm.org/rL259776
> >>>
> >>> -Tom
> >>>
>  Cheers,
>  Jonas
> 



smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2016-03-19 Thread Hahnfeld, Jonas via cfe-commits

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-commits
> Sent: Thursday, February 04, 2016 12:27 PM
> To: cfe-commits@lists.llvm.org
> Subject: r259776 - [OPENMP 4.0] Fixed support of array sections/array
> subscripts.
>
> Author: abataev
> Date: Thu Feb  4 05:27:03 2016
> New Revision: 259776
>
> URL: http://llvm.org/viewvc/llvm-project?rev=259776&view=rev
> Log:
> [OPENMP 4.0] Fixed support of array sections/array subscripts.
> Codegen for array sections/array subscripts worked only for expressions with
> arrays as base. Patch fixes codegen for bases with pointer/reference types.
>
> Modified:
> cfe/trunk/include/clang/AST/ExprOpenMP.h
> cfe/trunk/lib/AST/Expr.cpp
> cfe/trunk/lib/CodeGen/CGExpr.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
> cfe/trunk/lib/CodeGen/CodeGenFunction.h
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
> cfe/trunk/test/OpenMP/for_reduction_codegen.cpp
> cfe/trunk/test/OpenMP/task_codegen.cpp
>
> Modified: cfe/trunk/include/clang/AST/ExprOpenMP.h
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/include/clang/AST/ExprOpenMP.h?rev=259776&r1=25977
> 5&r2=259776&view=diff
> ==
> 
> --- cfe/trunk/include/clang/AST/ExprOpenMP.h (original)
> +++ cfe/trunk/include/clang/AST/ExprOpenMP.h Thu Feb  4 05:27:03 2016
> @@ -85,7 +85,7 @@ public:
>void setBase(Expr *E) { SubExprs[BASE] = E; }
>
>/// \brief Return original type of the base expression for array section.
> -  static QualType getBaseOriginalType(Expr *Base);
> +  static QualType getBaseOriginalType(const Expr *Base);
>
>/// \brief Get lower bound of array section.
>Expr *getLowerBound() { return
> cast_or_null(SubExprs[LOWER_BOUND]); }
>
> Modified: cfe/trunk/lib/AST/Expr.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/AST/Expr.cpp?rev=259776&r1=259775&r2=259776&vie
> w=diff
> ==
> 
> --- cfe/trunk/lib/AST/Expr.cpp (original)
> +++ cfe/trunk/lib/AST/Expr.cpp Thu Feb  4 05:27:03 2016
> @@ -4026,16 +4026,18 @@ unsigned AtomicExpr::getNumSubExprs(Atom
>llvm_unreachable("unknown atomic op");  }
>
> -QualType OMPArraySectionExpr::getBaseOriginalType(Expr *Base) {
> +QualType OMPArraySectionExpr::getBaseOriginalType(const Expr *Base) {
>unsigned ArraySectionCount = 0;
>while (auto *OASE = dyn_cast(Base-
> >IgnoreParens())) {
>  Base = OASE->getBase();
>  ++ArraySectionCount;
>}
> -  while (auto *ASE = dyn_cast(Base->IgnoreParens()))
> {
> +  while (auto *ASE =
> + dyn_cast(Base->IgnoreParenImpCasts()))
> + {
>  Base = ASE->getBase();
>  ++ArraySectionCount;
>}
> +  Base = Base->IgnoreParenImpCasts();
>auto OriginalTy = Base->getType();
>if (auto *DRE = dyn_cast(Base))
>  if (auto *PVD = dyn_cast(DRE->getDecl()))
>
> Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=259776&r1=259775&r2=259
> 776&view=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExpr.cpp Thu Feb  4 05:27:03 2016
> @@ -1949,6 +1949,21 @@ LValue CodeGenFunction::EmitLoadOfRefere
>return MakeAddrLValue(Addr, RefTy->getPointeeType(), Source);  }
>
> +Address CodeGenFunction::EmitLoadOfPointer(Address Ptr,
> +   const PointerType *PtrTy,
> +   AlignmentSource *Source) {
> +  llvm::Value *Addr = Builder.CreateLoad(Ptr);
> +  return Address(Addr, getNaturalTypeAlignment(PtrTy->getPointeeType(),
> Source,
> +
> +/*forPointeeType=*/true)); }
> +
> +LValue CodeGenFunction::EmitLoadOfPointerLValue(Address PtrAddr,
> +const PointerType
> +*PtrTy) {
> +  AlignmentSource Source;
> +  Address Addr = EmitLoadOfPointer(PtrAddr, PtrTy, &Source);
> +  return MakeAddrLValue(Addr, PtrTy->getPointeeType(), Source); }
> +
>  static LValue EmitGlobalVarDeclLValue(CodeGenFunction &CGF,
>const Expr *E, const VarDecl *VD) {
>QualType T = E->getType();
> @@ -2934,21 +2949,54 @@ LValue CodeGenFunction::EmitArraySubscri
>return LV;
>  }
>
> +static Address emitOMPArraySectionBase(CodeGenFunction &CGF, const
> Expr *Base,
> +   AlignmentSource &AlignSource,
> +   QualType BaseTy, QualType ElTy,
> +   bool IsLowerBound) {
> +  LValue Ba

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

2016-01-20 Thread Hahnfeld, Jonas via cfe-commits

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

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Arpith Jacob via cfe-commits
> Sent: Wednesday, January 20, 2016 5:56 PM
> To: acja...@us.ibm.com; a.bat...@hotmail.com; kkw...@gmail.com;
> hfin...@anl.gov; sfan...@us.ibm.com; cber...@us.ibm.com
> Cc: caom...@us.ibm.com; cfe-commits@lists.llvm.org
> Subject: [PATCH] D16358: [OpenMP] Parsing + Sema for nowait clause on
> target directive
>
> arpith-jacob created this revision.
> arpith-jacob added reviewers: ABataev, kkwli0, hfinkel, sfantao,
> carlo.bertolli.
> arpith-jacob added subscribers: cfe-commits, caomhin, fraggamuffin.
>
> Allow nowait clause on target directive in sema and add test cases.
>
> http://reviews.llvm.org/D16358
>
> Files:
>   include/clang/Basic/OpenMPKinds.def
>   test/OpenMP/target_ast_print.cpp
>   test/OpenMP/target_nowait_messages.cpp
>
> Index: test/OpenMP/target_nowait_messages.cpp
> ==
> =
> --- /dev/null
> +++ test/OpenMP/target_nowait_messages.cpp
> @@ -0,0 +1,17 @@
> +// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp
> +-ferror-limit 100 -o - %s
> +
> +void foo() {
> +}
> +
> +int main(int argc, char **argv) {
> +  #pragma omp target nowait( // expected-warning {{extra tokens at the
> +end of '#pragma omp target' are ignored}}
> +  foo();
> +  #pragma omp target nowait (argc)) // expected-warning {{extra tokens
> +at the end of '#pragma omp target' are ignored}}
> +  foo();
> +  #pragma omp target nowait device (-10u)
> +  foo();
> +  #pragma omp target nowait (3.14) device (-10u) // expected-warning
> +{{extra tokens at the end of '#pragma omp target' are ignored}}
> +  foo();
> +
> +  return 0;
> +}
> Index: test/OpenMP/target_ast_print.cpp
> ==
> =
> --- test/OpenMP/target_ast_print.cpp
> +++ test/OpenMP/target_ast_print.cpp
> @@ -25,6 +25,8 @@
>foo();
>  #pragma omp target map(always,alloc: i)
>foo();
> +#pragma omp target nowait
> +  foo();
>return 0;
>  }
>
> @@ -44,6 +46,8 @@
>  // CHECK-NEXT: foo()
>  // CHECK-NEXT: #pragma omp target map(always,alloc: i)  // CHECK-NEXT:
> foo()
> +// CHECK-NEXT: #pragma omp target nowait // CHECK-NEXT: foo()
>  // CHECK: template  char tmain(char argc, 
> char
> *argv) {  // CHECK-NEXT: char i, j, a[20]  // CHECK-NEXT: #pragma omp target
> @@ -60,6 +64,8 @@  // CHECK-NEXT: foo()  // CHECK-NEXT: #pragma omp
> target map(always,alloc: i)  // CHECK-NEXT: foo()
> +// CHECK-NEXT: #pragma omp target nowait // CHECK-NEXT: foo()
>  // CHECK: template  T tmain(T argc, T *argv) {  // 
> CHECK-
> NEXT: T i, j, a[20]  // CHECK-NEXT: #pragma omp target @@ -76,6 +82,8 @@
> // CHECK-NEXT: foo()  // CHECK-NEXT: #pragma omp target
> map(always,alloc: i)  // CHECK-NEXT: foo()
> +// CHECK-NEXT: #pragma omp target nowait // CHECK-NEXT: foo()
>
>  // CHECK-LABEL: int main(int argc, char **argv) {  int main (int argc, char
> **argv) { @@ -115,6 +123,11 @@
>foo();
>  // CHECK-NEXT: foo();
>
> +#pragma omp target nowait
> +// CHECK-NEXT: #pragma omp target nowait
> +  foo();
> +// CHECK-NEXT: foo();
> +
>return tmain(argc, &argc) + tmain(argv[0][0], 
> rgv[0]);  }
>
> Index: include/clang/Basic/OpenMPKinds.def
> ==
> =
> --- include/clang/Basic/OpenMPKinds.def
> +++ include/clang/Basic/OpenMPKinds.def
> @@ -355,6 +355,7 @@
>  OPENMP_TARGET_CLAUSE(device)
>  OPENMP_TARGET_CLAUSE(map)
>  OPENMP_TARGET_CLAUSE(private)
> +OPENMP_TARGET_CLAUSE(nowait)
>
>  // Clauses allowed for OpenMP directive 'target data'.
>  // TODO More clauses for 'target data' directive.
>



smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RE: 3.8 Merge Request: r259776

RE: 3.8 Merge Request: r259776

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

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

23 matches

Site Navigation

Mail list logo

Footer information