[llvm-commits] [llvm] r156383 - in /llvm/trunk: include/llvm/Bitcode/LLVMBitCodes.h lib/Bitcode/Reader/BitcodeReader.cpp

[Stephen Hines]

I thought that the consensus from the most recent LLVM Developer Conference
was to not remove opcode support except on major releases. Deprecating an
opcode (not using it further with BitcodeWriter) and generating new opcodes
was considered reasonable. This would seem to go directly against that. I
would prefer that changes like this get reverted before 3.2.

Steve

On Tue, May 22, 2012 at 2:01 PM, Bill Wendling <wendling at apple.com> wrote:

> On May 22, 2012, at 3:55 AM, Kuperstein, Michael M wrote:
>
> > Hello,
> >
> > The commit below (156383) broke binary compatibility with LLVM 3.0.
> > The LLVM 3.1 branch generates bitcode files with the new
> TYPE_CODE_FUNCTION, and can read both. However, 3.0 still generated
> TYPE_CODE_FUNCTION_OLD (it is named TYPE_CODE_FUNCTION in 3.0, the change
> to OLD was made somewhere between 3.0 and the final 3.1 branch) records.
> This means 3.1 is still able to read 3.0 bitcode, but 3.2 will not be able
> to.
> >
> > I'm attaching a small test-case. I will be happy to provide a proper
> patch that resurrects TYPE_CODE_FUNCTION_OLD, if that's helpful.
> >
> I'm not really in favor of reverting this behavior. The old code was in
> there by accident. It's unfortunate that some bitcodes were generated with
> the outdated codes, but it's not something we should wish to perpetuate.
> There is a workaround: use the 3.0 or 3.1 `llvm-dis' tool to create a text
> version of the bitcode file and then run the new `llvm-as' on it.
>
> -bw
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120522/fc600b3b/attachment.html>