Patch to BitcodeReader

[Tom Roeder]

Yes, that triggers it. Here's an updated patch that uses the test you
suggest and uses FileCheck to make sure that the right IR is generated from
llvm-dis. I'm new to the LLVM testing infrastructure, so please tell me if
there's a better way to do this check.

Thanks,

Tom


On Thu, Sep 12, 2013 at 1:16 PM, Tobias Grosser <tobias at grosser.es> wrote:

> On 09/12/2013 10:05 PM, Tom Roeder wrote:
>
>> Performing the select as a regular instruction (%a = select ...) doesn't
>> trigger the bug. It has to end up with a CE_SELECT in the CONSTANTS block
>> of the bitcode file. However, I'm far from an expert in LLVM bitcode, so
>> if
>> there's a smaller test case, I'd be happy to switch to it.
>>
>
> Hi Tom,
>
> just to explain why I even ask for this. Every unneeded code makes me
> start thinking for some reason it is needed to trigger the test case. So by
> removing any unneeded code, it is a lot more clear why something happened.
> As you have seen just know, this was even necessary to make me realize we
> only work on the constant selects (even though it was in fact clear in the
> patch);
>
> What about this test case:
>
> define <2 x i32> @main() {
>  ret <2 x i32> select (<2 x i1> <i1 false, i1 undef>, <2 x i32> <i32 0,
> i32 0>, <2 x i32> <i32 0, i32 undef>)
> }
>
> Does this still trigger the bug?
>
> Also it would be nice to add a small comment that this explicitly tests
> constant expressions.
>
> Ah, and as said before, it would be nice to check that the very same IR is
> actually regenerated.
>
> Cheers,
> Tobias
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130912/2c2a00a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ce_select.patch
Type: application/octet-stream
Size: 2478 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130912/2c2a00a0/attachment.obj>