[PATCH] Fix LTO handling of module-level assembly (Bug 14152)

[Tom Roeder]

Here's a patch that adds the test in LLVM IR to test/tools/lto with a
lit.local.cfg that checks if LTO is present. Also, the check for LTO
seems wrong to me in test/Makefile: it looks like it's checking to see
if -flto is in the command-line flags for the current build (rather
than -flto being possible with the compiler that was built). This
patch changes that to look for LLVMgold.so in the lib directory.  No
other tests seem to be using the flag lto_is_enabled at the moment.
Please let me know what you think.

Tom

On Fri, Sep 13, 2013 at 5:30 PM, Tom Roeder <tmroeder at google.com> wrote:
> OK, thanks. I'll figure out another place to put it.
>
> On Sep 13, 2013 5:05 PM, "Bill Wendling" <wendling at apple.com> wrote:
>>
>> On Sep 13, 2013, at 4:54 PM, Tom Roeder <tmroeder at google.com> wrote:
>>
>> > Here is a pair of patches that fix and test
>> > http://llvm.org/bugs/show_bug.cgi?id=14512. The fix applies to LLVM,
>> > and I have currently put the test in the clang test suite. The test is
>> > a minor tweak to the test proposed in the bug. Please take a look.
>> >
>> > The problem in this case is that the RecordStreamer implementation of
>> > MCStreamer in the LTO module doesn't implement EmitCFIEndProcImpl, and
>> > the default implementation in MCStreamer doesn't finish the frame.
>> >
>> > This patch touches the LTO code in tools/lto, but the test uses clang.
>> > Is this the right way to do it? Is there a better location for LTO
>> > tests?
>> >
>> Hi Tom,
>>
>> I haven't looked at the patch yet. However, the rule-of-thumb for where
>> tests should go is that they should be in located where the code that tests
>> them is. Clang doesn't have anything to do with LTO, so putting it in the
>> clang test suite isn't really good. You'll want to generate a .ll file and
>> place it in the LLVM part. That said, it's hard to know where such a test
>> would go, since we don't really have many for LTO...But just pick a good
>> place that's kind of related. :-)
>>
>> -bw
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lto_unfinished_frame.patch
Type: application/octet-stream
Size: 2471 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130916/59048948/attachment.obj>