hfinkel accepted this revision.
hfinkel added a comment.
This revision is now accepted and ready to land.
LGTM
Comment at: lib/Driver/Driver.cpp:1949
+SpecializedBuilders.push_back(new OpenMPActionBuilder(C, Args, Inputs));
+
//
sfantao wrote:
> hfinke
Author: jlebar
Date: Wed Oct 26 17:13:20 2016
New Revision: 285250
URL: http://llvm.org/viewvc/llvm-project?rev=285250&view=rev
Log:
[CUDA] Switch cuda_wrappers/complex to use a proper include guard instead of
#pragma once.
This is consistent with the rest of our internal headers.
Modified:
hfinkel accepted this revision.
hfinkel added a comment.
This revision is now accepted and ready to land.
LGTM
https://reviews.llvm.org/D21848
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
hfinkel accepted this revision.
hfinkel added a comment.
This revision is now accepted and ready to land.
LGTM
Comment at: lib/Driver/Driver.cpp:2091
+InputArg->getOption().getKind() == llvm::opt::Option::InputClass &&
+!types::isSrcFile(HostAction->getType()))
Author: jlebar
Date: Wed Oct 26 17:13:26 2016
New Revision: 285251
URL: http://llvm.org/viewvc/llvm-project?rev=285251&view=rev
Log:
[CUDA] Move device placement new definitions into a wrapper header.
Previously, these were always included -- after this change, you have to
#include , which is co
hfinkel accepted this revision.
hfinkel added a comment.
This revision is now accepted and ready to land.
LGTM
Comment at: lib/Driver/Tools.cpp:334
+ LksStream << " OpenMP Offload Linker Script.\n";
+ LksStream << "*/\n";
+ LksStream << "TARGET(binary)\n";
hfinkel added a comment.
...
>
>
>> I guess I don't understand the motivation for this change.
>
> To make work in CUDA, we do the following terrible, awful,
> horrible, no good thing: ...well, I can just show you the code.
> https://github.com/llvm-project/llvm-project/blob/master/clang/l
jlebar added a comment.
> Is this because the functions are in instead of in are you
> don't want to mark all of as host/device?
Yes. cmath is its own beast; we need to have our own implementation of it in
order to direct the std functions to the appropriate low-level device
functions. (A
hfinkel added a comment.
In https://reviews.llvm.org/D25403#580416, @jlebar wrote:
> > Is this because the functions are in instead of in are
> > you don't want to mark all of as host/device?
>
> Yes. cmath is its own beast; we need to have our own implementation of it in
> order to direct
jlebar added a comment.
In https://reviews.llvm.org/D25403#580422, @hfinkel wrote:
> Okay. Why not fix the Clang builtins so that they're evaluatable for constant
> inputs in a constexpr context? Then we can do this and test the change.
I am not sure how much value we would derive from testing
hfinkel added a comment.
In https://reviews.llvm.org/D25403#580432, @jlebar wrote:
> In https://reviews.llvm.org/D25403#580422, @hfinkel wrote:
>
> > Okay. Why not fix the Clang builtins so that they're evaluatable for
> > constant inputs in a constexpr context? Then we can do this and test the
Author: zaks
Date: Wed Oct 26 17:51:47 2016
New Revision: 285253
URL: http://llvm.org/viewvc/llvm-project?rev=285253&view=rev
Log:
[analyzer] Report CFNumberGetValue API misuse
This patch contains 2 improvements to the CFNumber checker:
- Checking of CFNumberGetValue misuse.
- Treating all CFNu
This revision was automatically updated to reflect the committed changes.
Closed by commit rL285253: [analyzer] Report CFNumberGetValue API misuse
(authored by zaks).
Changed prior to commit:
https://reviews.llvm.org/D25876?vs=75488&id=75961#toc
Repository:
rL LLVM
https://reviews.llvm.org/
jlebar added a comment.
> I'm not sure about that. It seems like a useful feature for the builtins to
> have. Logically speaking, they should be constexpr.
I agree that it's logically correct for the builtins to be
constexpr-evaluatable. My point is just that doing this work and then writing
chandlerc added a comment.
In https://reviews.llvm.org/D23754#580277, @mgorny wrote:
> In https://reviews.llvm.org/D23754#580268, @beanz wrote:
>
> > @mgorny, I don't think LLVMgold qualifies as a runtime in the traditional
> > sense. It more closely aligns with the tools vended by LLVM even tho
hfinkel added a comment.
In https://reviews.llvm.org/D25403#580439, @jlebar wrote:
> > I'm not sure about that. It seems like a useful feature for the builtins to
> > have. Logically speaking, they should be constexpr.
>
> I agree that it's logically correct for the builtins to be
> constexpr-e
jlebar added a comment.
//Let "CE" mean "constexpr-evaluatable". //
libc++ attempts to be backwards-compatible with old versions of clang, right?
Old versions of clang are going to fail, since the builtin will not be CE. Is
the idea to write a test that checks that, if __builtin_isfinite is C
hfinkel added a comment.
Here's what I suggest:
1. We commit this patch (I think it logically makes sense; the builtins should
be constexpr evaluatable, even if they're currently not)
2. We follow up by fixing Clang to make the builtins constexpr evaluatable
(since I think that makes sense rega
hfinkel added a comment.
In https://reviews.llvm.org/D25403#580444, @jlebar wrote:
> //Let "CE" mean "constexpr-evaluatable". //
>
> libc++ attempts to be backwards-compatible with old versions of clang, right?
Yea, we'd need to ifdef the test for older versions of Clang. I've just
summarized
Author: mehdi_amini
Date: Wed Oct 26 18:23:08 2016
New Revision: 285254
URL: http://llvm.org/viewvc/llvm-project?rev=285254&view=rev
Log:
Unconditionally pass `-lto_library` to the linker on Darwin
We're only doing it with -flto currently, however it never "hurt"
to pass it, and users that are li
This revision was automatically updated to reflect the committed changes.
Closed by commit rL285254: Unconditionally pass `-lto_library` to the linker on
Darwin (authored by mehdi_amini).
Changed prior to commit:
https://reviews.llvm.org/D25932?vs=75668&id=75963#toc
Repository:
rL LLVM
http
mehdi_amini reopened this revision.
mehdi_amini added a comment.
This revision is now accepted and ready to land.
Reopen: this hasn't been committed yet apparently.
@sashab : are you still interested in moving this forward?
https://reviews.llvm.org/D24289
jlebar added a comment.
So, good news -- these three builtins are already constexpr-evaluatable. :)
I'll add a test.
https://reviews.llvm.org/D25403
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/list
Author: rjmccall
Date: Wed Oct 26 18:46:34 2016
New Revision: 285258
URL: http://llvm.org/viewvc/llvm-project?rev=285258&view=rev
Log:
Refactor call emission to package the function pointer together with
abstract information about the callee. NFC.
The goal here is to make it easier to recognize
rtrieu updated this revision to Diff 75970.
rtrieu marked 2 inline comments as done.
https://reviews.llvm.org/D21675
Files:
include/clang/AST/DeclBase.h
include/clang/AST/DeclCXX.h
include/clang/AST/Stmt.h
include/clang/AST/TemplateBase.h
include/clang/AST/Type.h
include/clang/Basic/D
rtrieu added a comment.
In https://reviews.llvm.org/D21675#560297, @rsmith wrote:
> There are a bunch of cases here that do this:
>
> if (auto t = getThing())
> ID.addThing(t);
> if (auto t = getOtherThing())
> ID.addThing(t);
>
>
> That will result in hash collisions between objects
Author: sfantao
Date: Wed Oct 26 19:53:34 2016
New Revision: 285263
URL: http://llvm.org/viewvc/llvm-project?rev=285263&view=rev
Log:
Fix bug when compiling CUDA code with -emit-llvm and -o.
In this case the device code is not injected into an host action and therefore
the
user should get an e
Author: sfantao
Date: Wed Oct 26 20:08:58 2016
New Revision: 285264
URL: http://llvm.org/viewvc/llvm-project?rev=285264&view=rev
Log:
Remove check for -o option in offloading actions builder.
This check is also present when jobs are built, so the offloading builder check
is not needed anymore.
sfantao added a comment.
In https://reviews.llvm.org/D18172#580276, @jlebar wrote:
> Hi, Samuel.
>
> This change introduced a new crash / assertion failure in the driver.
>
> $ echo | llvm-run clang -emit-llvm -c -x cuda - -o /dev/null
>
>
> Before this patch, we get an error (perhaps not as
Thank you for fixing this!
On Wed, Oct 26, 2016 at 5:53 PM, Samuel Antao via cfe-commits
wrote:
> Author: sfantao
> Date: Wed Oct 26 19:53:34 2016
> New Revision: 285263
>
> URL: http://llvm.org/viewvc/llvm-project?rev=285263&view=rev
> Log:
> Fix bug when compiling CUDA code with -emit-llvm and
kubabrecka added a comment.
Does this also disable checking for the compiler generated `.cxx_destruct`
Obj-C methods? Can we add a testcase both here and into compiler-rt?
https://reviews.llvm.org/D25857
___
cfe-commits mailing list
cfe-commits@li
craig.topper created this revision.
craig.topper added reviewers: delena, igorb.
craig.topper added a subscriber: cfe-commits.
Inverting the mask argument currently fails isel and even if that was fixed it
does not reflect the intended semantics of the intrinsic.
https://reviews.llvm.org/D26019
dberris accepted this revision.
dberris added a comment.
This revision is now accepted and ready to land.
Thanks @rSerge -- I'll land this now.
https://reviews.llvm.org/D24799
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm
dberris added a comment.
Actually I tried again, but still the patch doesn't apply cleanly through git
(and it still complains of whitespace issues). Let me go through this manually
again, and see whether there are still failures that come up.
https://reviews.llvm.org/D24799
___
Author: dberris
Date: Wed Oct 26 23:56:14 2016
New Revision: 285266
URL: http://llvm.org/viewvc/llvm-project?rev=285266&view=rev
Log:
[XRay] Check in Clang whether XRay supports the target when -fxray-instrument
is passed
Summary:
Added the code which explicitly emits an error in Clang in case
`
This revision was automatically updated to reflect the committed changes.
Closed by commit rL285266: [XRay] Check in Clang whether XRay supports the
target when -fxray-instrument… (authored by dberris).
Changed prior to commit:
https://reviews.llvm.org/D24799?vs=75452&id=75980#toc
Repository:
Author: nemanjai
Date: Thu Oct 27 01:23:57 2016
New Revision: 285268
URL: http://llvm.org/viewvc/llvm-project?rev=285268&view=rev
Log:
[PPC] add vector byte reverse functions to altivec.h
This patch corresponds to review https://reviews.llvm.org/D25915.
Committing on behalf of Sean Fertile.
Modi
mgorny added a comment.
In https://reviews.llvm.org/D23754#580441, @chandlerc wrote:
> In https://reviews.llvm.org/D23754#580277, @mgorny wrote:
>
> > The difference is that LLVMgold.so is not used by LLVM or clang directly
> > but by the system binutils, and so it must match the ABI of the link
101 - 138 of 138 matches
Mail list logo
