similar to: [LLVMdev] can you provide backward compatibility for win32 users

Hello, Vikas > can any one help me a way to back port the solution files to > VisualStudio 6.0 project files. Unfortunately, this is pretty useless: VC6 C++ is deeply broken in order to compile LLVM. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello list, I have been requested privately for vorbis-tools 1.2.0 binaries for Windows. Twice. Which means there are people out there who'd really like to have them available. I cannot compile stuff for Windows, though, so if someone could make available said binaries, it would be much appreciated. -Ivo

Hi Guus, I know this comes up from time to time. So it is time to update our expectations. Is there a roadmap for a 1.1 backward compatibility already? -rsd -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20141228/fcb2b44a/attachment.html>

Hi Justin, There are some backward incompatible features of PTX; for example, special registers are redefined as v4i32 (they were v4i16) in PTX 2.0. And CUDA 4.0 was rolled out last week. I heard that some instructions are deprecated. I am not sure how stable (or unstable) PTX specification is. Do you have a rough assessment of its stability? If PTX specification is still fast evolving, I would

On Sun, Dec 28, 2014 at 10:33:47AM -0200, Raul Dias wrote: > I know this comes up from time to time. So it is time to update our > expectations. > > Is there a roadmap for a 1.1 backward compatibility already? The roadmap looks like this: 1.1pre1: backwards compatible with 1.0.x 1.1pre2: backwards compatible with 1.0.x, but not 1.1pre1 ... 1.1preN: backwards compatible with 1.0.x,

And how distant are we from a 1.1.0? :) On Sun, Dec 28, 2014 at 10:49 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sun, Dec 28, 2014 at 10:33:47AM -0200, Raul Dias wrote: > > > I know this comes up from time to time. So it is time to update our > > expectations. > > > > Is there a roadmap for a 1.1 backward compatibility already? > > The roadmap

Hi all, Turns out there''s a small backward compatibility problem in 0.22.2. If you''ve got clients in older versions sending reports to a daemon running the newer version, you''ll run into a problem because I renamed the Puppet::Metric class to Puppet::Util::Metric. I''ve committed a fix to svn, but it''s not a big enough problem to require a new

Hello folks, I had to make a bit change in speex.pc in FreeBSD ports to make it more backward compatibility with the other ports (applications). Before: ================================== # pkg-config --cflags speex -I/usr/local/include ================================== After: ================================== # pkg-config --cflags speex -I/usr/local/include -I/usr/local/include/speex

Hello Syslinux Team, Syslinux 5.xx / 6.xx are currently showing some backward compatibility issues. Between the ML and the IRC, there have been some comments / reports regarding memtest, older kernels, plop boot manager, ifplop.c32, hdt.c32... In some cases, the problems were seen when booting with some specific variant of Syslinux 5.xx / 6.xx (say, ISOLINUX only, or PXELINUX only); or with

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The latest version of rsync apparently can't talk to version 2.5 clients. When I tried connecting, I got an error message that the client needed to be upgraded to use more modern protocol. Was this intentional? As I can't change the version of rsync on the client side, I had to downgrade my version of rsync to connect to them. - ---Michael

Quite often I get to work on an old bug, where an old ll/bc file is attached as a testcase. These files, in most cases (if not all), need to be converted somehow to the latest format, for the trunk version to be able to parse it without an error. So a few questions arise: 1. Is there a standard way to convert an old ll/bc to the latest? If not, what is the common approach for these cases? 2.

Does anyone have anything else to say about .bc/.ll compatibility? It is important to be clear to users about what compatibility we provide. I'd like to get consensus about this and put it in the docs somewhere. -- Sean Silva On Wed, Jun 18, 2014 at 11:15 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 18, 2014 at 10:35 AM, Tim Northover

> On Jun 17, 2014, at 2:10 PM, Eric Christopher <echristo at gmail.com> wrote: > >>> 2. Metadata compatibility. We already had precedence of introducing >>> incompatible changes into metadata format in the past within release. >>> Should we use relaxes rules for metadata compatibility? >> >> I think we have a special case for debug metadata (and

On 18 June 2014 17:10, Sean Silva <chisophugis at gmail.com> wrote: >> >> Do others agree that this is the case or at least that this would be a >> >> reasonable balance? >> > IMO it's easier to be compatible on .ll level, no? >> >> That is not my experience with the bitcode format. The way the API is >> structured makes it really easy

Hi all, Hobbeswalsh on IRC has discovered a backward compatibility issue in 0.24.0, preventing 0.23.x clients working well with 0.24.0 servers. Specifically, you can''t specify relationships to builtin resources when the client is 0.23.x, although specifying relationships to defined resources still works. The problem is that prior to 0.24.0 there was no central class

I''ve attached the patch I had to make to get open3 to work under 1.8.3. It doesn''t take backwards compatibility in to account, so that''ll probably have to be addressed. Thanks, -- Nathaniel Talbott <:((>< -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32-open3-0.2.0.txt Url:

A bit of history first: Back when we transitioned from bytecode to bitcode (2.0) we had a tool called llvm-upgrade which would read .ll files from 1.9 and output 2.0 format which could then be passed to llvm-as to produce bitcode. The release notes for 2.3 note that llvm-upgrade was not supported any more. During the 2.X development we tried to keep reading older bitcodes. Once we got to 3.1,

Dear R developers, I am seeking advice on some $subject matter. My package will have an update soon, that is not backward compatible with the current version. It will likely break much of the existing code. Many (~50) packages depend on 'igraph' and they, too, will most probably break with the new version. My intended solution is, that I create a snapshot of the current package, under

On Jul 9, 2014, at 3:51 PM, Eric Christopher <echristo at gmail.com> wrote: > On Wed, Jul 9, 2014 at 3:12 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> >>> On Jun 17, 2014, at 2:10 PM, Eric Christopher <echristo at gmail.com> wrote: >>> >>>>> 2. Metadata compatibility. We already had precedence of introducing >>>>>

Hi all, I am working on adding PGO to LDC (LLVM D Compiler). The current implementation 1) uses LLVM's InstrProf pass to generate an instrumented executable 2) links to compiler-rt/lib/profile for the runtime functionality to write a raw profile data file 3) uses llvm-profdata to merge profile data and convert from profraw to profdata format 4) uses llvm::IndexedInstrProfReader to read-in