I'm totally cool with this change; however, it's been a while since I've taken a look at this part of MCA. I'll let other's chime in as well, but +1 from me.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 4 2020
Feb 21 2020
Feb 20 2020
In D74917#1885621, @JDevlieghere wrote:In D74917#1885615, @mattd wrote:In D74917#1885590, @JDevlieghere wrote:It should never be possible for LLDB_ENABLE_PYTHON to be true but SWIG_FOUND to be false. The modules FindPythonInterpAndLibs.cmake and FindLuaAndSwig.cmake should fail early when SWIG isn't found.
Thanks for taking a look. Would you be okay with making the status message() in FindPythonInterpAndLibs.cmake and FindLuaAndSwig.cmake fatal, that way the dependency error is clearer?
That would defeat the purpose of auto-detecting these dependencies. Please take a look at D71306 for all the details. The summary is that all optional dependencies default to Auto: where we enable them if we can find them. You can override this behavior by passing LLDB_ENABLE_PYTHON=ON to CMake, in which case not finding Python (or SWIG) will be a fatal error.
In D74917#1885590, @JDevlieghere wrote:It should never be possible for LLDB_ENABLE_PYTHON to be true but SWIG_FOUND to be false. The modules FindPythonInterpAndLibs.cmake and FindLuaAndSwig.cmake should fail early when SWIG isn't found.
Sep 26 2019
Sep 25 2019
In D67735#1682203, @ruiu wrote:LGTM
I don't have a strong preference over silently accepting or reporting an error on an empty YAML, so this change seems fine. Thank you for doing htis.
Sep 18 2019
Sep 11 2019
Aug 27 2019
LGTM, nice change! I assume all of the existing LSUnit testing is sufficient.
Jun 24 2019
This looks great! Thanks.
Jun 19 2019
Awesome patch. I'm cool with this as long as Simon's comments are addressed.
Jun 11 2019
Thanks for the patch @Maxpm! Can we close PR42173? Is there anything left for that ticket?
Jun 10 2019
May 9 2019
May 8 2019
This looks nice! We should probably also have a test for the case where a user specifies an END before a BEGIN tag.
Apr 22 2019
Apr 19 2019
Thanks for the review, I addressed your comments:
- Removed the reference, and pass the AST node as a pointer.
- Made a few decls auto
Apr 17 2019
Apr 2 2019
LGTM, I'll let @jhenderson weigh-in to see what he says.
LGTM, as long as @rupprecht's comment is addressed.
Apr 1 2019
In D53832#1450240, @troyj wrote:Could you simply rebase the patch, or acknowledge the new LLVM license, as your patch was written prior to the license change.
My organization (Cray Inc) already signed the new license agreement, so I'm not sure what you need here. I can write that I acknowledge the new LLVM license, if that helps.
Mar 30 2019
In D53832#1443179, @troyj wrote:I do not have commit access. I probably should request it at some point, but I'm fine with someone else merging this for me.
Mar 28 2019
LGTM!
Mar 22 2019
In D53832#1439874, @troyj wrote:This revision is now accepted and ready to land.Dec 3 2018, 12:55 PM
Been about 3.5 months since accepted. Can this be committed?
Mar 13 2019
Mar 7 2019
Makes sense. LGTM.
Mar 1 2019
Thanks for the reviews everyone. This update addresses the feedback, all of which was incorporated.
Feb 28 2019
LGTM
Feb 27 2019
I like this and think users will find it very helpful. The changes seem sensible to me; however, I had a few nits... mostly stylistic things, no big deals. Anyways, I'll mark this patch as accept, as long as you cover the suggestions made by @lebedev.ri.
- Fixed the test case (removed underscore typo, and extraneous shstrtab test).
- Emit ANDROID_REL ANDROID_RELA instead of section offsets.
- Modified the range check, allowing us to remove some now redundant code for printing the lower-bound section names.
Feb 26 2019
In D58701#1411546, @Bigcheese wrote:lgtm
Should the +0 be +0x0 so that it's always a hex digit? Or is the +0 what the binutils already output?
- Added a more complicated test.
- Made a few variables 'auto' instead of their iterator type.
Feb 20 2019
LGTM. Thanks for adding these.
Feb 19 2019
In D58416#1403227, @compnerd wrote:Previously we would have emitted Foo [[:space:]] . right?
Feb 18 2019
In D57149#1388361, @uabelho wrote:In D57149#1387325, @mattd wrote:Hi @uabelho
The test case in your patch definitely causes a problem, but that's because the -start-before/-stop-after is used. If I run that same test through llc, the UnreachableBlockElim pass kicks-in and drops the dead code.
I took a look at the code in your Janurary 24th comment. I was unable to get the same dead block to surface, but most likely I had the wrong flag set. How did you build the sample in that comment?It can be reproduced with the full llc -O1 pipe on current trunk using:
llc -O1 -o - pr40436.ll
pr40436.ll825 BDownload