Huh, I consider clang not warning on this a feature, not a bug. Why are we
trying to match what gcc does here?
Say you have code like this:
int64_t aligned_start = 0;
int64_t aligned_size = 0;
CalculateVMAlignedBoundaries(region.offset,
region.size,
Author: lebedevri
Date: Thu Oct 12 14:15:26 2017
New Revision: 315622
URL: http://llvm.org/viewvc/llvm-project?rev=315622&view=rev
Log:
[Analysis] Un-silence -Wtautological-unsigned-zero-compare in null-deref-ps.c
Stage-2 builds failed:
error: 'warning' diagnostics expected but not seen:
File
This revision was automatically updated to reflect the committed changes.
Closed by commit rL315624: [CUDA] Added __hmma_m16n16k16_* builtins to support
mma instructions on sm_70 (authored by tra).
Changed prior to commit:
https://reviews.llvm.org/D38742?vs=118636&id=118848#toc
Repository:
r
Author: tra
Date: Thu Oct 12 14:32:19 2017
New Revision: 315624
URL: http://llvm.org/viewvc/llvm-project?rev=315624&view=rev
Log:
[CUDA] Added __hmma_m16n16k16_* builtins to support mma instructions on sm_70
Differential Revision: https://reviews.llvm.org/D38742
Added:
cfe/trunk/test/CodeGen
On Fri, Oct 13, 2017 at 12:12 AM, Nico Weber wrote:
> Huh, I consider clang not warning on this a feature, not a bug. Why are we
> trying to match what gcc does here?
Because i have been bitten by this more than once.
It did result in big amount of wasted time, and this "thread":
https://lists.llv
Author: zturner
Date: Thu Oct 12 14:56:05 2017
New Revision: 315627
URL: http://llvm.org/viewvc/llvm-project?rev=315627&view=rev
Log:
[lit] Raise the logic for enabling clang & lld substitutions to llvm.
This paves the way for other projects which might /use/ clang or
lld but not necessarily need
Author: morehouse
Date: Thu Oct 12 15:00:09 2017
New Revision: 315630
URL: http://llvm.org/viewvc/llvm-project?rev=315630&view=rev
Log:
[cmake] Rename LIB_FUZZING_ENGINE to LLVM_LIB_FUZZING_ENGINE.
Modified:
cfe/trunk/tools/clang-format/CMakeLists.txt
cfe/trunk/tools/clang-format/fuzzer/C
Author: lebedevri
Date: Thu Oct 12 15:03:20 2017
New Revision: 315631
URL: http://llvm.org/viewvc/llvm-project?rev=315631&view=rev
Log:
Revert "[Sema] Diagnose tautological comparison with type's min/max values"
This reverts r315614,r315615,r315621,r315622
Breaks http://bb9.pgr.jp/#/builders/20/b
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
Looks good, thanks!
https://reviews.llvm.org/D38700
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listi
lebedev.ri reopened this revision.
lebedev.ri added a comment.
This revision is now accepted and ready to land.
Reverted due to http://bb9.pgr.jp/#/builders/20/builds/59 that i don't
currently know how to deal with.
It is really sad that i failed to encounter it during testing.
Repository:
rL
On 12 October 2017 at 15:11, Roman Lebedev via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> lebedev.ri reopened this revision.
> lebedev.ri added a comment.
> This revision is now accepted and ready to land.
>
> Reverted due to http://bb9.pgr.jp/#/builders/20/builds/59 that i
vsk created this revision.
LLVM's smul.with.overflow intrinsic isn't supported on X86 for bit
widths larger than 64, or on X86-64 for bit widths larger than 128.
The failure mode is either a linker error ("the __muloti4 builtin isn't
available for this target") or an assertion failure ("Selection
arichardson planned changes to this revision.
arichardson added inline comments.
Comment at: include/clang/Basic/AddressSpaces.h:66
+inline LangAS LangASFromTargetAS(unsigned TargetAS) {
+ return static_cast((TargetAS) +
yaxunl wrote:
> how about `getLangASFro
rjmccall added a comment.
A few minor comments; feel free to commit after addressing them.
Comment at: include/clang/Basic/AddressSpaces.h:34
// OpenCL specific address spaces.
opencl_global,
yaxunl wrote:
> rjmccall wrote:
> > I think you need a real c
rjmccall added inline comments.
Comment at: lib/CodeGen/CGBuiltin.cpp:2263
+ }
+}
+
Is there a reason this only fails on x86? If LLVM doesn't have generic
wide-operation lowering, this probably needs to be a target whitelist rather
than a blacklist.
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
LGTM.
Repository:
rL LLVM
https://reviews.llvm.org/D38788
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cg
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
LGTM.
Repository:
rL LLVM
https://reviews.llvm.org/D38791
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cg
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
LGTM.
Repository:
rL LLVM
https://reviews.llvm.org/D38793
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cg
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
LGTM.
Repository:
rL LLVM
https://reviews.llvm.org/D38795
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cg
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
Yes, thank for you handling the cast case well.
Repository:
rL LLVM
https://reviews.llvm.org/D38796
___
cfe-commits mailing list
cfe-commi
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
This function feels increasingly poorly-named, but let's leave that alone for
now.
Repository:
rL LLVM
https://reviews.llvm.org/D38794
__
On Fri, Oct 13, 2017 at 1:22 AM, Richard Smith wrote:
> On 12 October 2017 at 15:11, Roman Lebedev via Phabricator via cfe-commits
> wrote:
>>
>> lebedev.ri reopened this revision.
>> lebedev.ri added a comment.
>> This revision is now accepted and ready to land.
>>
>> Reverted due to http://bb9.
rjmccall added inline comments.
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:5226
+def err_objc_variable_sized_type_not_at_end : Error<
+ "field %0 with variable sized type %1 is not at the end of class">;
+def note_next_field_declaration : Note<
jkorous-apple created this revision.
https://reviews.llvm.org/D38863
Files:
www/hacking.html
Index: www/hacking.html
===
--- www/hacking.html
+++ www/hacking.html
@@ -246,9 +246,9 @@
For example:
- python C:\Tool\llvm\u
vsk updated this revision to Diff 118857.
vsk added a comment.
Herald added a subscriber: aheejin.
- Update to check against a whitelist of supported targets.
https://reviews.llvm.org/D38861
Files:
lib/CodeGen/CGBuiltin.cpp
test/CodeGen/builtins-overflow-unsupported.c
test/CodeGen/builtin
vsk added inline comments.
Comment at: lib/CodeGen/CGBuiltin.cpp:2263
+ }
+}
+
rjmccall wrote:
> Is there a reason this only fails on x86? If LLVM doesn't have generic
> wide-operation lowering, this probably needs to be a target whitelist rather
> th
Author: erichkeane
Date: Thu Oct 12 16:01:53 2017
New Revision: 315638
URL: http://llvm.org/viewvc/llvm-project?rev=315638&view=rev
Log:
[Sema][Crash] Correctly handle an non-dependent noexcept expr in function
template
It seems that all of the other templated cases are handled correctly,
howeve
rjmccall added a comment.
Okay. Sounds good to me.
We intend to actually implement the generic lowering, I hope?
https://reviews.llvm.org/D38861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo
This revision was automatically updated to reflect the committed changes.
Closed by commit rL315638: [Sema][Crash] Correctly handle an non-dependent
noexcept expr in function… (authored by erichkeane).
Changed prior to commit:
https://reviews.llvm.org/D38700?vs=118245&id=118858#toc
Repository:
vsk added a comment.
In https://reviews.llvm.org/D38861#896435, @rjmccall wrote:
> Okay. Sounds good to me.
>
> We intend to actually implement the generic lowering, I hope?
Yes, I'll make a note of that in PR34920, and am tracking the bug internally in
rdar://problem/34963321.
https://revi
Author: ahatanak
Date: Thu Oct 12 16:24:38 2017
New Revision: 315639
URL: http://llvm.org/viewvc/llvm-project?rev=315639&view=rev
Log:
[Sema][ObjC] Complete merging ObjC methods before checking their
overriding methods.
This should fix test case Analysis/retain-release.m that was failing on
the r
On 12 October 2017 at 15:41, Roman Lebedev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On Fri, Oct 13, 2017 at 1:22 AM, Richard Smith
> wrote:
> > On 12 October 2017 at 15:11, Roman Lebedev via Phabricator via
> cfe-commits
> > wrote:
> >>
> >> lebedev.ri reopened this revision.
> >>
Author: anemet
Date: Thu Oct 12 16:56:54 2017
New Revision: 315643
URL: http://llvm.org/viewvc/llvm-project?rev=315643&view=rev
Log:
Handle/assert on DK_Remark
We don't generate remarks during inline assembly parsing so no need to handle
these for now.
Modified:
cfe/trunk/lib/CodeGen/CodeGen
vsk added a comment.
llvm-profdata is tightly coupled with the host compiler: while this setup may
work if you get lucky, I don't think it's resilient to changes in libProfData.
Also, using the instrumented llvm-profdata will be slow and create extra
profiles.
As an alternative, have you consi
arphaman accepted this revision.
arphaman added a comment.
This revision is now accepted and ready to land.
You generally don't need a pre-commit review for such a change.
https://reviews.llvm.org/D38863
___
cfe-commits mailing list
cfe-commits@list
alexshap added a comment.
yeah, i agree, this is not a good idea. My thoughts were different - right now
it's not particularly convenient that one has to specify LLVM_PROFDATA when
it's not actually used by the build.
Maybe we can create the target "generate-profdata" only if LLVM_PROFDATA is se
vsk added a comment.
In https://reviews.llvm.org/D38859#896517, @alexshap wrote:
> yeah, i agree, this is not a good idea. My thoughts were different - right
> now it's not particularly convenient that one has to specify LLVM_PROFDATA
> when it's not actually used by the build.
> Maybe we can
Author: jkorous
Date: Thu Oct 12 17:31:07 2017
New Revision: 315652
URL: http://llvm.org/viewvc/llvm-project?rev=315652&view=rev
Log:
Typos in tutorial
Modified:
cfe/trunk/www/hacking.html
Modified: cfe/trunk/www/hacking.html
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/hacking.ht
alexshap updated this revision to Diff 118868.
Repository:
rL LLVM
https://reviews.llvm.org/D38859
Files:
utils/perf-training/CMakeLists.txt
Index: utils/perf-training/CMakeLists.txt
===
--- utils/perf-training/CMakeLists.txt
alexshap updated this revision to Diff 118869.
alexshap added a comment.
Update the wording
Repository:
rL LLVM
https://reviews.llvm.org/D38859
Files:
utils/perf-training/CMakeLists.txt
Index: utils/perf-training/CMakeLists.txt
Author: george.karpenkov
Date: Thu Oct 12 17:51:41 2017
New Revision: 315655
URL: http://llvm.org/viewvc/llvm-project?rev=315655&view=rev
Log:
[Analyzer] Assume that CFBooleanRef const globals are non-null
Differential Revision: https://reviews.llvm.org/D38867
Added:
cfe/trunk/lib/StaticAnal
Author: rnk
Date: Thu Oct 12 17:53:02 2017
New Revision: 315656
URL: http://llvm.org/viewvc/llvm-project?rev=315656&view=rev
Log:
[MS] Don't bail on replacing dllimport vbase dtors with base dtors
Fix PR32990 by effectively reverting r283063 and solving it a different
way.
We want to limit the h
bruno created this revision.
Herald added a subscriber: yaxunl.
Change behavior introduced in r298369 and only error out on vector component
invalid length access on OpenCL mode.
https://reviews.llvm.org/D38868
Files:
lib/Sema/SemaExprMember.cpp
test/SemaOpenCL/vector_swizzle_length.cl
I
vsk accepted this revision.
vsk added a comment.
This revision is now accepted and ready to land.
Thanks!
Repository:
rL LLVM
https://reviews.llvm.org/D38859
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/ma
On Thu, Oct 12, 2017 at 8:39 AM, Anastasia Stulova
wrote:
>
> I think this bit is a bit confusing to us. Some of our original OpenCL
> checks were removed in some places because in some cases OpenCL semantic was
> adopted elsewhere.
It's confusing indeed. We should probably enhance the docs for
s
vsapsai added inline comments.
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:5226
+def err_objc_variable_sized_type_not_at_end : Error<
+ "field %0 with variable sized type %1 is not at the end of class">;
+def note_next_field_declaration : Note<
yaxunl added inline comments.
Comment at: tools/libclang/CXType.cpp:402
+ ASTContext &Ctx = cxtu::getASTUnit(GetTU(CT))->getASTContext();
+ return Ctx.getTargetAddressSpace(T);
}
arichardson wrote:
> yaxunl wrote:
> > Is this function suppose to return AST add
joerg added inline comments.
Comment at: lib/CodeGen/CGBuiltin.cpp:2263
+ }
+}
+
vsk wrote:
> rjmccall wrote:
> > Is there a reason this only fails on x86? If LLVM doesn't have generic
> > wide-operation lowering, this probably needs to be a target whi
vsk added inline comments.
Comment at: lib/CodeGen/CGBuiltin.cpp:2263
+ }
+}
+
joerg wrote:
> vsk wrote:
> > rjmccall wrote:
> > > Is there a reason this only fails on x86? If LLVM doesn't have generic
> > > wide-operation lowering, this probably needs
Author: arphaman
Date: Thu Oct 12 18:53:13 2017
New Revision: 315661
URL: http://llvm.org/viewvc/llvm-project?rev=315661&view=rev
Log:
Recommit r315087 "[refactor] add support for refactoring options"
The recommit fixes a UB bug that occurred only on a small number of bots.
Original message:
Th
Author: rsmith
Date: Thu Oct 12 18:55:36 2017
New Revision: 315662
URL: http://llvm.org/viewvc/llvm-project?rev=315662&view=rev
Log:
Support for destroying operator delete, per C++2a proposal P0722.
This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or signi
rjmccall added inline comments.
Comment at: clang/lib/Sema/SemaDecl.cpp:15055
}
+ // If it is the last field is checked elsewhere.
}
vsapsai wrote:
> rjmccall wrote:
> > "Whether" rather than "If", please. You should also leave a com
This revision was automatically updated to reflect the committed changes.
Closed by commit rL315665: [clang] Enable clang build with
LLVM_BUILD_INSTRUMENTED without setting… (authored by alexshap).
Changed prior to commit:
https://reviews.llvm.org/D38859?vs=118869&id=118881#toc
Repository:
r
Author: alexshap
Date: Thu Oct 12 20:21:39 2017
New Revision: 315665
URL: http://llvm.org/viewvc/llvm-project?rev=315665&view=rev
Log:
[clang] Enable clang build with LLVM_BUILD_INSTRUMENTED without setting
LLVM_PROFTDATA
At the moment if LLVM_BUILD_INSTRUMENTED is set to True
one has to set LL
Author: yaxunl
Date: Thu Oct 12 20:37:48 2017
New Revision: 315668
URL: http://llvm.org/viewvc/llvm-project?rev=315668&view=rev
Log:
[OpenCL] Add LangAS::opencl_private to represent private address space in AST
Currently Clang uses default address space (0) to represent private address
space for
This revision was automatically updated to reflect the committed changes.
Closed by commit rL315668: [OpenCL] Add LangAS::opencl_private to represent
private address space in AST (authored by yaxunl).
Changed prior to commit:
https://reviews.llvm.org/D35082?vs=118813&id=118882#toc
Repository:
Lekensteyn added a comment.
ping? I'll push it next week if there is no new feedback.
https://reviews.llvm.org/D37954
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
101 - 157 of 157 matches
Mail list logo
