search for: offset_s

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

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 if an issue were discovered, it could be easily detected and dealt with. Douglas Yung From: Bob Wilson [mailto:bob.wilson at apple.com] Sent: Friday, September 26, 2014 16:39

As I understand it, the bitcode compatibility promise doesn't extend as far as debug info metadata (happy to be wrong here!). I think we have a usecase where need to guarantee that debug information from any two arbitrary bitcode files going into an LTO link will result in the expected/correct debug information going into the resulting ELF file; unless we can be sure that this will always

Hello all. I've been playing around with theora since it first entered CVS, and I like what I'm seeing. Today I've been fixing xine's theoraplugin to understand theora_info.frame_{width,height} and theora_info.offset_{x,y}. I only got it working after some experimenting and basically copying the code from player_example. A few questions related to this: 1. What are the legal

These assorted patches end up with adding virtio-scsi support to libguestfs. It passes libguestfs-test-tool, but I haven't yet tried to run the full set of tests. In theory > 26 devices can be added, but it's likely that certain parts of the daemon will break if you actually try this. This of course needs to be fixed. Thanks Paolo Bonzini for invaluable help. Rich.

On Sat, Sep 27, 2014 at 11:35 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > How is this use case different from the LTO-supported toolchains shipped > by other vendors such as Apple? Do they have this theoretical problem too? > > If the issue is solely constrained to debug info metadata, then why not > use metadata to describe the format/version of the debug info? >

More comprehensive support for virtio-scsi. Passes all the tests. Rich.

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 > like to write this version into the

Hi, despite the warnings on the website ;-) I played with the current CVS source of theora on Windows 2000 w/ Microsoft Visual C++. The codec and the "experimental" example programs compiled fine. I also encoded a 33 MB MPEG2 (?) video (3 minute trailer) to a 14 MB .OGG using "mplayer -vo yuv4mpeg -ao pcm" and the "encoderwin" sample program, and play it with the

Introduce Cortex-A7 with a scalable proc_info_list which including cpu id and cpu initialize function. In head.S, search cpu specific MIDR in procinfo and call such initialize function. Currently, support Cortex-A7 and Cortex-A15. Signed-off-by: Bamvor Jian Zhang <bjzhang@suse.com> --- changes since v2 1), define cpu_init function instead of assemble jump code in struct proc_info_list 2),

This still isn't working at the moment. See: http://marc.info/?t=139457409300003&r=1&w=2 This set of patches: - Adds new APIs to support discard in libguestfs. - Adds discard support to virt-format. - Adds discard support to virt-sysprep. - Implements virt-sparsify --in-place. Rich.