Historically Clang's policy on warnings was, I think, much more
conservative than it seems to be today. There was a strong desire not to
implement off-by-default warnings, and to have warnings with an
exceptionally low false-positive rate - maybe the user-defined operator
detection was either assum
Author: dblaikie
Date: Fri Mar 23 15:16:59 2018
New Revision: 328380
URL: http://llvm.org/viewvc/llvm-project?rev=328380&view=rev
Log:
Change for an LLVM header file move
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://llvm.org/vie
While implementing the warning is great (wonder if there's any codebase
that isn't -Wunused-using clean, that we could use to compare Clang and
GCC's behavior broadly - make sure it's catching the same cases (or
justify/investigate differences)) - and using it to motivate the debug info
is an impro
The only data we have is that where .o files go, .dwo files go beside them.
How to generalize this to other situations isn't really obvious to me -
even for a.out (do you put all the .dwo files next to a.out? in the same
directory? if the names collide, where then? etc).
Interestingly GCC for "g++
In implicit ThinLTO, the object files are only temporary.
Sort of similar to using -gsplit-dwarf when compiling straight to an
executable (without using -c): "clang++ x.cpp y.cpp -o a.out" - where
should the .dwo files go then? If they go where the .o files go, then
they'll be in /tmp/ and get del
Author: dblaikie
Date: Wed Mar 21 15:34:27 2018
New Revision: 328166
URL: http://llvm.org/viewvc/llvm-project?rev=328166&view=rev
Log:
Fix for LLVM change (Transforms/Utils/Local.h -> Analysis/Utils/Local.h)
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
Modified: cfe/trunk/lib/CodeGen/CGCall.cp
Might be useful in the future to use a more specific commit message such as
"add missing override" (or "add missing override to address
-Wmissing-override warning"), etc.
On Wed, Feb 28, 2018 at 6:03 AM Gabor Horvath via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: xazax
> Date: Wed
Author: dblaikie
Date: Wed Feb 21 08:00:50 2018
New Revision: 325692
URL: http://llvm.org/viewvc/llvm-project?rev=325692&view=rev
Log:
Remove use of the 'gmlt' term from the -fsplit-dwarf-inlining flag description
to make it more readily legible
Modified:
cfe/trunk/include/clang/Driver/Optio
Author: dblaikie
Date: Tue Feb 20 08:35:08 2018
New Revision: 325594
URL: http://llvm.org/viewvc/llvm-project?rev=325594&view=rev
Log:
PR36442: Correct description of -fsplit-dwarf-inlining
Modified:
cfe/trunk/include/clang/Driver/Options.td
Modified: cfe/trunk/include/clang/Driver/Options.t
Maybe - though that'd actually make for larger debug info & not be much
use.
With nodebug+always_inline (which is how the intrinsics are provided) the
function call dissolves into the raw instruction it's meant to represent.
The debug info describes that instruction as if it had been written at th
Ah.. hrm :/
On Mon, Feb 12, 2018 at 6:03 PM Eric Fiselier wrote:
> On Mon, Feb 12, 2018 at 4:01 PM, David Blaikie wrote:
>
>> ah, sweet :)
>>
>> On Mon, Feb 12, 2018 at 2:59 PM Eric Fiselier wrote:
>>
>>> On Mon, Feb 12, 2018 at 3:35 PM, David Blaikie
>>> wrote:
>>>
On Mon, Feb
ah, sweet :)
On Mon, Feb 12, 2018 at 2:59 PM Eric Fiselier wrote:
> On Mon, Feb 12, 2018 at 3:35 PM, David Blaikie wrote:
>
>>
>>
>> On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier wrote:
>>
>>> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie
>>> wrote:
>>>
On Wed, Feb 7, 2018 at
On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier wrote:
> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie wrote:
>
>>
>>
>> On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ericwf
>>> Date: Wed Feb 7 10:36:51 2018
>>> New Revision:
FWIW, you can write "*M" rather than M.getValue() if you reckon that's
neater.
And you could roll the declaration/initialization of M into the 'if'
condition - but I can understand why you might prefer not to, given it's a
many-line statement, etc.
On Tue, Feb 6, 2018 at 4:39 PM Erich Keane via c
Unit test?
On Fri, Feb 9, 2018 at 10:45 AM Phabricator via Phabricator via
llvm-commits wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL324761: Introduce an API for LLDB to compute the
> default module cache path (authored by adrian, commit
On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ericwf
> Date: Wed Feb 7 10:36:51 2018
> New Revision: 324498
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
> Log:
> [Driver] Add option to manually control discarding v
Fair - maybe just a comment in the test case (and/or the source code that
handles this) saying "hey, let's make sure dtors aren't here - but if/when
there's support for a low priority completion group, these should appear
there" or the like.
On Mon, Jan 29, 2018 at 9:49 AM Sam McCall wrote:
> On
Any chance of making this a really low priority completion? (maybe just
leaving in a FIXME or expected-fail check of some kind if it's not
practical to implement it right now) For those handful of times when you
actually want to do this.
On Mon, Jan 22, 2018 at 1:06 PM Sam McCall via cfe-commits <
Author: dblaikie
Date: Mon Jan 22 17:25:24 2018
New Revision: 323167
URL: http://llvm.org/viewvc/llvm-project?rev=323167&view=rev
Log:
NewPM: Improve/fix GCOV - which needs to run early in the pass pipeline.
Using a new extension point in the new PM, register GCOV at the start of
the pipeline rat
I feel like this sort of change will regress quite quickly - in the sense
that most 'cp' in tests is probably there to put it somewhere writable (in
some cases its to put it in a particular location, not about writability).
Any way we could fix 'cp' in lit to do the right thing here? (I doubt any
t
I'm surprised this problem is unique to friend functions with definitions
inline and the friend declaration site - doesn't a similar issue occur with
member functions of templates that are not instantiated in some (similar)
contexts?
Is there a common solution that could be used for both cases?
O
might be worth having an explanation (probably in both the commit message
and in a comment in the source) about why this test isn't supported on
windows?
On Fri, Jan 12, 2018 at 1:50 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rtrieu
> Date: Fri Jan 12 13:49:20
I haven't as yet, no. Sorry - happy if someone else wants to have a go, or
I'll take a closer look soon.
- Dave
On Thu, Jan 11, 2018 at 11:38 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:
> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D41455#963752, @aaron.ba
Author: dblaikie
Date: Tue Jan 9 14:03:47 2018
New Revision: 322126
URL: http://llvm.org/viewvc/llvm-project?rev=322126&view=rev
Log:
Wire up GCOV to the new pass manager
GCOV in the old pass manager also strips debug info (if debug info is
disabled/only produced for profiling anyway) after the
Excellent :)
On Mon, Jan 8, 2018 at 8:39 AM Adrian Prantl wrote:
>
> On Jan 8, 2018, at 8:14 AM, David Blaikie wrote:
>
> Great - are you tracking/planning to implement this for trivial_abi once
> it's in? (was mentioned in the code review, but not sure if it's on your
> plate/plan or not (no w
Great - are you tracking/planning to implement this for trivial_abi once
it's in? (was mentioned in the code review, but not sure if it's on your
plate/plan or not (no worries if it isn't, just keeping these things in
mind))
On Thu, Jan 4, 2018 at 5:14 PM Adrian Prantl via cfe-commits <
cfe-commit
Rough guess: That seems like a lot of code changes for relatively little
test changes - are all parts of this change tested? (Might well be - just
lots of layers to plumb things through - but if there's lots of places that
get locations and only a few of those are tested, maybe this could use more
It helps to have the first line of the commit message be roughly
descriptive, since it forms the brief commit summary in version tools and
the subject line in commit email - just "NFC" is a bit unclear. Usually
these sort of commits are described as, say "Suppress -Asserts
unused-variable warning f
I'm sure it's something obvious I don't understand here, but maybe someone
else doesn't either & could benefit from it:
What exactly does this change do? In what important way is "cp X Y"
different from "cat X > Y"?
On Mon, Jan 8, 2018 at 7:06 AM Sam McCall via cfe-commits <
cfe-commits@lists.llv
(just a side note: perhaps this conversation would've been more suited to
cfe-dev? I sort of missed it because I only check commits once a week,
unless I'm specifically cc'd on something. All good though :))
On Wed, Jan 3, 2018 at 4:06 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org>
Sure, this is post-commit review feedback.
vim with dvorak works in the sense that it's not unusable, but it's pretty
awkward (see, for example, discussions like this:
http://vim.wikia.com/wiki/Using_Vim_with_the_Dvorak_keyboard_layout )
On Tue, Jan 2, 2018 at 10:03 AM George Karpenkov
wrote:
>
On Tue, Dec 19, 2017 at 9:43 PM Akira Hatanaka wrote:
> On Tue, Dec 12, 2017 at 12:12 PM, John McCall wrote:
>
>> On Tue, Dec 12, 2017 at 1:45 PM, David Blaikie
>> wrote:
>>
>>> On Mon, Dec 11, 2017 at 5:38 PM John McCall wrote:
>>>
On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie
wro
any chance this can be implemented based on keyboard layout, so it's good
for dvorak users as well? (maybe it already is, I don't know - just
mentioning it in case)
On Thu, Dec 21, 2017 at 2:58 PM George Karpenkov via Phabricator via
cfe-commits wrote:
> This revision was automatically updated t
Test case?
On Thu, Dec 21, 2017 at 2:39 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rtrieu
> Date: Thu Dec 21 14:38:29 2017
> New Revision: 321319
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321319&view=rev
> Log:
> [ODRHash] Canonicalize Decl's before pro
Generally I'd encourage you/anyone to use [&] for any lambda that doesn't
escape its scope - avoids any issues like this & doesn't really hinder
readability imho.
On Wed, Dec 20, 2017 at 9:23 AM Eric Liu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ioeric
> Date: Wed Dec 20 09:2
ied (I suppose, at least
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:
ven with long term solution implemented
>> in clang/lldb, gdb still won't resolve dynamic types properly for the
>> described cases.
>>
>> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>>
>> 15.12.2017 21:25, David Blaikie via cfe-commits
st
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:25, David Blai
This operator bool should probably be explicit (as most/all of them should
be - and most of them in LLVM are) - to avoid undue implicit conversion to
other int types.
On Wed, Dec 13, 2017 at 7:43 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ibiryukov
> Date: Wed
On Fri, Dec 15, 2017 at 8:09 AM xgsa wrote:
> David, thank you for the detailed answer and corner cases.
>
> Just to clarify: everywhere in my mail where I mentioned "debugger", I
> meant LLDB, but not GDB (except, where I mentioned GDB explicitly).
> Currently, I have no plans to work on GDB, ho
On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator <
revi...@reviews.llvm.org> wrote:
> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>
> > Philosophically, mangled names and DWARF information serve different
> purposes, and I don't think you will find o
On Mon, Dec 11, 2017 at 5:38 PM John McCall wrote:
> On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie wrote:
>
>> On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> rjmccall added a comment.
>>>
>>> In https://reviews.llvm.org/D41039#951648, @a
On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
revi...@reviews.llvm.org> wrote:
> rjmccall added a comment.
>
> In https://reviews.llvm.org/D41039#951648, @ahatanak wrote:
>
> > I had a discussion with Duncan today and he pointed out that perhaps we
> shouldn't allow users to annota
My bet would be: warn and ignore it, but probably Richard's & John might
have stronger thoughts/justifications/etc.
On Mon, Dec 11, 2017 at 1:38 PM Akira Hatanaka via Phabricator <
revi...@reviews.llvm.org> wrote:
> ahatanak added a comment.
>
> I had a discussion with Duncan today and he pointed
Thanks!
On Wed, Dec 6, 2017 at 2:12 AM Sven van Haastregt via Phabricator <
revi...@reviews.llvm.org> wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rC319883: [OpenCL] Fix layering violation by
> getOpenCLTypeAddrSpace (authored by svenvh).
>
Ping - I have a pretty clear workaround internally, but still would be
happy to remove any workarounds given the opportunity.
As for layering. For now the issue is that libAST depends on libBasic, and
libraries can't have circular dependencies. Modular builds (well,
especially modular codegen, but
Author: dblaikie
Date: Mon Nov 20 17:09:17 2017
New Revision: 318719
URL: http://llvm.org/viewvc/llvm-project?rev=318719&view=rev
Log:
FormatInternal.h: Add missing includes.
Modified:
cfe/trunk/lib/Format/FormatInternal.h
Modified: cfe/trunk/lib/Format/FormatInternal.h
URL:
http://llvm.org
Author: dblaikie
Date: Mon Nov 20 17:09:18 2017
New Revision: 318720
URL: http://llvm.org/viewvc/llvm-project?rev=318720&view=rev
Log:
ASTMatchers{,Macros}.h: Add some extra macros to use for decl/def of matchers
Fix ODR violations caused by using internal linkage variables in
non-internal inline
Author: dblaikie
Date: Thu Nov 16 17:07:20 2017
New Revision: 318491
URL: http://llvm.org/viewvc/llvm-project?rev=318491&view=rev
Log:
Update for layering fix in LLVM CodeGen<>Target
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://
Ping on this layering violation. A simple way to demonstrate this is to
move the definition of clang::Type::getTypeClass out of line: This results
in an unresolved symbol due to incorrect/broken dependencies.
Richard? Anyone else? Ideas on how to address this layering violation?
Anastasia: Could
Author: dblaikie
Date: Wed Nov 15 08:52:12 2017
New Revision: 318304
URL: http://llvm.org/viewvc/llvm-project?rev=318304&view=rev
Log:
ASTMatchers.h: Fix ODR violations by avoiding internal linkage variables in
headers
Internal linkage variables ODR referenced from inline functions create
ODR vi
On Sun, Nov 12, 2017 at 12:53 PM Anton via Phabricator <
revi...@reviews.llvm.org> wrote:
> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#919579, @aprantl wrote:
>
> > For clarification: what is the "symbols table" you are referring to in
> the description?
>
>
> I meant the data du
Ping \/
On Fri, Nov 3, 2017 at 4:22 PM David Blaikie wrote:
> When you say "symbols table" - what are you referring to?
>
> On Fri, Nov 3, 2017 at 4:20 PM Adrian Prantl via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> aprantl added a comment.
>>
>> Can you add a testcase?
>>
>>
>> Repos
When you say "symbols table" - what are you referring to?
On Fri, Nov 3, 2017 at 4:20 PM Adrian Prantl via Phabricator <
revi...@reviews.llvm.org> wrote:
> aprantl added a comment.
>
> Can you add a testcase?
>
>
> Repository:
> rL LLVM
>
> https://reviews.llvm.org/D39622
>
>
>
>
__
Author: dblaikie
Date: Thu Nov 2 15:28:50 2017
New Revision: 317279
URL: http://llvm.org/viewvc/llvm-project?rev=317279&view=rev
Log:
Modular Codegen: Don't home always_inline functions
Since they'll likely (not always - if the address is taken, etc) be
inlined away, even at -O0, separately prov
Author: dblaikie
Date: Thu Nov 2 14:55:40 2017
New Revision: 317274
URL: http://llvm.org/viewvc/llvm-project?rev=317274&view=rev
Log:
Modular Codegen: Don't home/modularize static functions in headers
Consistent with various workarounds in the backwards compatible modules
that allow static funct
On Mon, Oct 23, 2017 at 5:01 PM George Karpenkov via Phabricator via
cfe-commits wrote:
> george.karpenkov added a comment.
>
> @dcoughlin the context I was thinking about is that if everyone
> consistently runs `clang-format` (if we want that), then we never would
> have discussion.
> The altern
Could this be a value rather than indirected through a unique_ptr? Simply:
BodyFarm BdyFrm;
& initialized in the ctors init list?
On Tue, Oct 24, 2017 at 4:53 PM George Karpenkov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: george.karpenkov
> Date: Tue Oct 24 16:53:19 2017
>
I realize this was changed in a follow-up commit anyway, but for future
reference: There's no need (& best to avoid - simpler to read, avoids bugs
like this, etc) to conditionalize delete like this. Delete is a no-op on
null pointers anyway, so this dtor should just contain an unconditional
"delete
Author: dblaikie
Date: Fri Oct 27 13:40:45 2017
New Revision: 316793
URL: http://llvm.org/viewvc/llvm-project?rev=316793&view=rev
Log:
Sanitizers.h: Modularize/Fix ODR violations by making inline functions
non-static
Modified:
cfe/trunk/include/clang/Basic/Sanitizers.h
Modified: cfe/trunk/i
Author: dblaikie
Date: Fri Oct 27 13:40:45 2017
New Revision: 316792
URL: http://llvm.org/viewvc/llvm-project?rev=316792&view=rev
Log:
CharInfo.h: Modularize/fix ODR violations by making inline functions in header
not static
Modified:
cfe/trunk/include/clang/Basic/CharInfo.h
Modified: cfe/t
Author: dblaikie
Date: Fri Oct 27 13:40:44 2017
New Revision: 316791
URL: http://llvm.org/viewvc/llvm-project?rev=316791&view=rev
Log:
ASTContext.h: Modularize/fix ODR violations by removing 'static' from inline
functions in headers
Modified:
cfe/trunk/include/clang/AST/ASTContext.h
Modifie
Author: dblaikie
Date: Fri Oct 27 13:40:46 2017
New Revision: 316794
URL: http://llvm.org/viewvc/llvm-project?rev=316794&view=rev
Log:
StaticAnalyzer: Modularize/fix ODR violations making functions inline but
non-static in headers
Also move these out of the llvm namespace & rely on ADL as is
app
What John said, but also a narrower test would be good - checking that the
appropriate call instruction gets a debug location, rather than checking
that a bunch of inlining doesn't cause the assertion/verifier failure,
would be good. (Clang tests should, as much as possible, not rely on or run
the
Generally it's preferably to avoid adding dead code (partly for this reason
- it's hard to track when it gets used and ensure it's appropriately
tested) could the member function's body be replaced with llvm_unreachable
for now, then?
On Mon, Oct 16, 2017 at 10:27 AM Alex L wrote:
> At the momen
Is there missing test coverage for this?
On Tue, Oct 10, 2017 at 9:12 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ibiryukov
> Date: Tue Oct 10 09:12:47 2017
> New Revision: 315323
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315323&view=rev
> Log:
> [clangd
Is there a test that could be added to cover this new code?
On Fri, Oct 13, 2017 at 2:15 PM Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Fri Oct 13 14:15:25 2017
> New Revision: 315755
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315755&view=rev
Would it be better/possible to improve the warning to not have this false
positive, rather than suppressing it?
On Sun, Oct 15, 2017 at 1:12 PM Roman Lebedev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: lebedevri
> Date: Sun Oct 15 13:12:42 2017
> New Revision: 315874
>
> URL: h
I mention it only out of interest of deduplication of functionality/code
within the LLVM project as a whole. Be nice not to maintain two things if
one would suffice.
On Thu, Oct 12, 2017 at 6:21 AM Sam McCall wrote:
> Interesting - this is pretty primitive, and still fairly tightly coupled
> to
hey Lang (& folks here) any chance there's some overlap between the RPC
functionality here and the RPC functionality in ORC that could be
deduplicated/refactored?
On Fri, Oct 6, 2017 at 5:30 AM Ilya Biryukov via Phabricator via
cfe-commits wrote:
> ilya-biryukov accepted this revision.
> ilya-bi
On Wed, Sep 27, 2017 at 1:58 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:
> probinson added a reviewer: rnk.
> probinson added a comment.
>
> +rnk for the CodeView question.
>
>
>
>
> Comment at: include/clang/Frontend/CodeGenOptions.def:222
>
On Wed, Sep 27, 2017 at 11:50 AM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:
> probinson added a comment.
>
> In https://reviews.llvm.org/D14358#882445, @dblaikie wrote:
>
> > > I would prefer to eliminate the `` from the instance name as
> well, because our debugger reconstru
Is there also missing test coverage here?
On Sun, Sep 24, 2017 at 8:19 AM Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rksimon
> Date: Sun Sep 24 08:17:46 2017
> New Revision: 314079
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314079&view=rev
> Log:
> Fix impl
On Tue, Sep 5, 2017 at 2:47 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Tue Sep 5 14:46:22 2017
> New Revision: 312580
>
> URL: http://llvm.org/viewvc/llvm-project?rev=312580&view=rev
> Log:
> Fix memory leak after r312467. The ModuleMap is the o
Fine to remove it if it didn't change the test - it just wasn't clear to me
what exactly was being tested at the time so it was more "does this test
still work with/without -disable-llvm-passes".
No worries.
On Tue, Sep 5, 2017 at 10:58 PM Karl-Johan Karlsson via Phabricator <
revi...@reviews.llv
Seems like the test case should/could be simplified a bit, maybe? (could it
be something really simple like "void f(bool b) { #pragma ... while (b) ;
}"?)
Also, is it relying on LLVM optimizations to run (add
"-disable-llvm-passes" to the command line to be sure it isn't, perhaps?)?
On Sun, Sep 3
Author: dblaikie
Date: Thu Aug 31 11:49:34 2017
New Revision: 312268
URL: http://llvm.org/viewvc/llvm-project?rev=312268&view=rev
Log:
Disable clang-format's MemoizationTest as it becomes prohibitive with
EXPENSIVE_CHECKS
EXPENSIVE_CHECKS enables libstdc++'s library consistency checks, which
inc
On Mon, Aug 28, 2017 at 5:21 PM Reid Kleckner wrote:
> On Mon, Aug 28, 2017 at 5:02 PM, David Blaikie wrote:
>
>> Feels like this alignment attribute may be a bit of a death trap, then?
>> Should other uses of the attribute be scrutinized, or could we come up with
>> a portable way to use it saf
Feels like this alignment attribute may be a bit of a death trap, then?
Should other uses of the attribute be scrutinized, or could we come up with
a portable way to use it safely? (using a different attribute on different
compilers - sounded like maybe one form worked with MSVC and a different
for
On Fri, Aug 18, 2017 at 6:59 PM Stephan T. Lavavej via Phabricator via
cfe-commits wrote:
> STL_MSFT added a comment.
>
> In https://reviews.llvm.org/D36860#846232, @thakis wrote:
>
> > Many driver tests check in a basic representative directory structure
> (e.g. test/Driver/Inputs/basic_freebsd_
*nod* Thanks - let me know if you have trouble simplifying or explaining it
& I'll see if fresh eyes help :)
On Mon, Aug 28, 2017 at 4:46 PM Adrian Prantl wrote:
> It's possible that this testcase can be golfed some more. I copied it
> almost verbatim from the PR. I'll see what I can do. The imp
Seems like a rather complex test case - could you explain what's going on
there? (maybe in the form of a comment in the code - what path through all
those classes is required to tickle this)
On Wed, Aug 23, 2017 at 2:25 PM Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Autho
It's helpful to mention why a patch is reverted in the commit message that
reverts. Thought for next time! :)
On Tue, Aug 8, 2017 at 9:46 AM Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: abataev
> Date: Tue Aug 8 09:45:36 2017
> New Revision: 310379
>
> URL: http:/
OK - go ahead and remove the tests then, if the functionality is now
covered by the buildbot+existing tests.
On Wed, Aug 9, 2017 at 12:04 PM Grang, Mandeep Singh
wrote:
> > Ah, OK. I'm still curious about whether this results in a loss of test
> coverage. Without this test, would the bug it was
On Wed, Aug 9, 2017 at 1:44 AM Grang, Mandeep Singh
wrote:
> In D35043 I have removed the llvm tests which use -reverse-iterate. This
> patch removes the clang tests.
>
Ah, OK. I'm still curious about whether this results in a loss of test
coverage. Without this test, would the bug it was testin
Author: dblaikie
Date: Wed Aug 9 11:34:22 2017
New Revision: 310508
URL: http://llvm.org/viewvc/llvm-project?rev=310508&view=rev
Log:
PointerLikeTypeTraits: class->struct to match LLVM change
Modified:
cfe/trunk/include/clang/AST/CanonicalType.h
cfe/trunk/include/clang/AST/DeclCXX.h
On Mon, Aug 7, 2017 at 12:08 PM Mandeep Singh Grang via Phabricator <
revi...@reviews.llvm.org> wrote:
> mgrang added a comment.
>
> This patch does 3 things:
>
> 1. Get rid of the unit test objc-modern-metadata-visibility2.mm because
> this test check uses flag -reverse-iterate. This flag will be
Not sure I understand the context for these changes - could you describe
the motivation(s) in more detail?
On Sun, Aug 6, 2017 at 10:39 PM Mandeep Singh Grang via Phabricator <
revi...@reviews.llvm.org> wrote:
> mgrang created this revision.
>
> This patch is in response to https://reviews.llvm.o
On Thu, Jul 27, 2017 at 8:30 AM Dehao Chen via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> danielcdh marked an inline comment as done.
> danielcdh added a comment.
>
> Thanks for the review!
>
> In https://reviews.llvm.org/D35746#822498, @chandlerc wrote:
>
> > LGTM with a t
On Tue, Jul 25, 2017 at 1:19 AM Roman Lebedev via Phabricator via
cfe-commits wrote:
> lebedev.ri added a comment.
>
> How does this relate to the gcc behavior?
> I suspect not everyone would want to have this relaxed `-Wshadow` mode.
>
Generally I think the goal hasn't been to allow a clang use
Test coverage?
On Sun, Jul 30, 2017 at 5:52 AM Lenar Safin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: lll
> Date: Sat Jul 29 13:42:58 2017
> New Revision: 309496
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309496&view=rev
> Log:
> Improve readability of CXX method overrid
On Thu, Jul 27, 2017 at 6:35 PM Erik Pilkington via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: epilk
> Date: Thu Jul 27 18:35:14 2017
> New Revision: 309349
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309349&view=rev
> Log:
> [demangler] Fix some overzealous -Wreturn-type erro
On Fri, Jul 28, 2017 at 4:01 PM Kevin Enderby wrote:
> On Jul 28, 2017, at 10:30 AM, David Blaikie wrote:
>
>
>
> On Fri, Jul 28, 2017 at 10:24 AM Kevin Enderby wrote:
>
>> On Jul 27, 2017, at 9:50 PM, Saleem Abdulrasool via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>> compnerd added
On Fri, Jul 28, 2017 at 10:24 AM Kevin Enderby wrote:
> On Jul 27, 2017, at 9:50 PM, Saleem Abdulrasool via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> compnerd added a comment.
>
> Does anyone use the overload with the `O` for `exports` with `nullptr`
> instead of `this`? If not, we co
On Fri, Jul 21, 2017 at 12:57 PM David Blaikie wrote:
> On Fri, Jul 21, 2017 at 11:34 AM David Majnemer via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> majnemer added a comment.
>>
>> This might be a silly question but why not do this by default?
>>
>
> I'd hazard a guess that GDB would
On Fri, Jul 21, 2017 at 11:34 AM David Majnemer via Phabricator <
revi...@reviews.llvm.org> wrote:
> majnemer added a comment.
>
> This might be a silly question but why not do this by default?
>
I'd hazard a guess that GDB wouldn't cope well with this (in terms of
identifying templates as the sa
Looks good - does this support available_externally definitions of strong
external linkage functions in the users of a module? (is that tested?)
Should it?
Also should we consider having two flags for modular codegen - one for
correctness (external function definitions), one for linkage size
optim
Thanks all!
On Wed, Jul 12, 2017 at 7:46 AM Alexander Kornienko
wrote:
> Done in r307661.
>
> On Mon, Jul 10, 2017 at 2:08 PM, Alexander Kornienko
> wrote:
>
>> Benjamin has actually fixed the issue by reverting to the old behavior in
>> r306822.
>> I'll add a test for this behavior anyway.
>>
I'm roughly where I was before, I think:
"In any case, it seems like it might make sense for you to upstream your
template naming change and put it under the PS4 debugger tuning option, and
put this change there too, once the motivation for it is in-tree. At that
point, while I'd be curious about
On Mon, Jul 10, 2017 at 10:58 AM Dehao Chen wrote:
> This test was originally added in https://reviews.llvm.org/D34721 with
> clang change. It's kind of dup of the previous test
> (-check-prefix=SAMPLEPGO) in terms of testing the clang bits. But we
> want to make sure the new PM has the expected
701 - 800 of 1427 matches
Mail list logo
