search for: douglas_yung

...al to add Bitcode version field to bitcode file wrapper Bitcode backward compatibility, at least for the current major version, is supposed to make this unnecessary. Can you provide more information about what “known incompatibilities” you’re seeing? On Sep 26, 2014, at 2:40 PM, Yung, Douglas <douglas_yung at playstation.sony.com<mailto:douglas_yung at playstation.sony.com>> wrote: Hi, We would like to add a version number to the bitcode wrapper. This feature would allow easier identification of what compiler produced the bitcode so that known incompatibilities with LTO compilation could b...

On Sun, Oct 5, 2014 at 8:10 PM, Yung, Douglas < douglas_yung at playstation.sony.com> wrote: > Hi – > > > > I realize the thread has drifted a little, but I wanted to get back to my > original proposal. I would like to make a change to the bitcode file > wrapper to include the version of llvm that produced the bitcode. I would >...

...g up an incompatibility and providing useful information on the reason to the user. --Greg Bedwell SN Systems - Sony Computer Entertainment Group On 27 September 2014 02:24, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 26, 2014 at 5:18 PM, Yung, Douglas < > douglas_yung at playstation.sony.com> wrote: > >> Sorry if I was unclear. There are currently no “known >> incompatibilities” that I am aware of, although I fully admit to not being >> an expert on the topic. The idea is that we add versioning information to >> the bitcode so that...

...l information on the reason to the user. > > --Greg Bedwell > SN Systems - Sony Computer Entertainment Group > > On 27 September 2014 02:24, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Fri, Sep 26, 2014 at 5:18 PM, Yung, Douglas < >> douglas_yung at playstation.sony.com> wrote: >> >>> Sorry if I was unclear. There are currently no “known >>> incompatibilities” that I am aware of, although I fully admit to not being >>> an expert on the topic. The idea is that we add versioning information to >>>...

Hi, We would like to add a version number to the bitcode wrapper. This feature would allow easier identification of what compiler produced the bitcode so that known incompatibilities with LTO compilation could be detected. Roughly speaking, this version number would consist of the major, minor and optionally the patch version of the compiler used to produce the bitcode. The version information

Hi Sean, > Rafael gave me some of the backstory on this. Basically it is to work around some buggy behavior in the Darwin ar. Adding that on the front of the bitcode file just to get a version doesn't seem > like a very clean thing to do. > > Doug, what other alternatives did you guys consider before settling on this? > > As for #2 above, the non-universality of the wrapper

Hi, The conversation has drifted slightly, so I wanted to bring it back to the version field in the bitcode wrapper. Currently in the toolchain which we ship and support, we use a proprietary linker. That linker is unable to read bitcode files and we do not have any plans to enable it to as far as I’m aware. Because of this, we need a way of identifying the version of a bitcode file without