search for: bumped

...dler signature for ABI 23 Check ABI major not encoded ABI Chris Lamb (1): Altering the compilation build script to make it reproducible. Dylan Aïssi (2): Fix a spelling error inside via_xv.c Switch to https for all links to freedesktop.org Kevin Brace (270): Version bumped to 0.5.99 viaIGAInitCommon will now initialize certain legacy VGA registers Version bumped to 0.5.100 Accessing CRTC after miscellaneous output register initialization Limiting IGA1 Address Mode Selection bit access to UniChrome Pro or later Limiting IGA2 Address Mode...

On 03/25/2020 06:20 AM, Louis Dionne wrote: > > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com> wrote: >> >> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: >>> In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html. No decision was made, but maybe we

On Wed, Dec 19, 2018, 13:21 David Greene via llvm-dev < llvm-dev at lists.llvm.org wrote: > [ Consider all of this to be preferences, not anything close to an > objection. ] > > Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > There haven't been many more responses in the last few days, so can we > > try to come to some kind of

On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: > In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects, I'd prefer to bump the minimum CMake version for all of LLVM.

> On Mar 25, 2020, at 13:07, Nikita Popov <nikita.ppv at gmail.com> wrote: > > On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 03/25/2020 06:20 AM, Louis Dionne wrote: > > > > > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com

> On Mar 25, 2020, at 19:42, Chris Tetreault <ctetreau at quicinc.com> wrote: > > I would like to just chime in and say that I’m fairly strongly opposed to any blanket version increases without justification. Having a low version requirement is a feature. It means that more people can build the codebase. We should increase the minimum CMake version requirement only if we need to do

Hi, The minimum CMake version currently advertised for libc++ and libc++abi is currently 3.4.3. I think the oldest version of CMake actually being tested on any builder is 3.7.0, so advertising 3.4.3 is somewhat of a lie (I'm pretty sure we're using features that require a more recent version already). However, we do need to bump it to 3.8.0 at least because CMake 3.7 doesn't know

...drop old metadata (i.e. bitcode upgrade isn't performance proof in general but only "best effort", there have been multiple instance of this in the past). Usually IIRC we try not to version the bitcode at all this way (i.e. bitcode does not have a linear versioning that is regularly bumped) but instead make sure the encoding itself allows an easy upgrade. I.e. the encoding of the FMF should have been such that the reader can detect and upgrade to the new IR representation. Now this is too late here I guess, so bumping may be a possible trade-off. What about any bitcode shipped after...

I understand organization restrictions and old operating systems (I use CentOS 7 myself), but I’ll note that the only requirement for running a new CMake is the ability to download and untar a tarball; in particular, you don’t require sudo. (I understand that there may be restrictions around running arbitrary executables downloaded from the internet, which of course make sense, but I wanted to

We do not promise API compatibility for filters between stable releases of nbdkit, however, we should at least ensure that when we do break API, that we refuse to load a filter compiled against one version of nbdkit with another server running a different API. A single bump once per stable release is good enough (rather than once per API change). We did this correctly for commits

Hi there, I would like to make a 'bumps chart' like the ones described e.g. here: http://junkcharts.typepad.com/junk_charts/bumps_chart/ Purpose: I'd like to plot the proportion of people in select countries living for less then one USD pr day in 1994 and 2004 respectively. I have already constructed a barplot - but I think a bumps chart would be better # The barplot and data

Hi, TL;DR r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling a llvm-6.0 bitcode will potentially generate incorrect code w.r.t. fast math expectations. Should we bump the bitcode version because of that and have the autoupgrader

On Mon, Aug 26, 2019 at 12:15:27PM -0500, Eric Blake wrote: > We do not promise API compatibility for filters between stable > releases of nbdkit, however, we should at least ensure that when we do > break API, that we refuse to load a filter compiled against one > version of nbdkit with another server running a different API. A > single bump once per stable release is good enough

...metadata (i.e. bitcode upgrade isn't performance proof in general but only "best effort", there have been multiple instance of this in the past). > > Usually IIRC we try not to version the bitcode at all this way (i.e. bitcode does not have a linear versioning that is regularly bumped) but instead make sure the encoding itself allows an easy upgrade. I.e. the encoding of the FMF should have been such that the reader can detect and upgrade to the new IR representation. > Now this is too late here I guess, so bumping may be a possible trade-off. Do you think we should do it,...

Compiz 0.8.4 is released! This is the second stable release of Compiz 0.8 series. This release brings two new plugins, translation updates, many bug fixes, improved stability, and better screen resolution change handling. Also included is additional integration work for KDE 4. In particular, window thumbnails are now supported in Plasma window tooltips with the new KDE compatibility plugin, the

Does the language reference need to be updated? http://llvm.org/docs/LangRef.html#fast-math-flags It still mentions "fast" On Thu, Feb 8, 2018 at 8:34 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > TL;DR > r317488 changed the way fast math flags are laid out in the bitcode and > anyone compiling a pre-llvm-6.0 bitcode with

Just wanted to point out part of this even becoming a problem is the use of `isFast()`. There should be warnings against using isFast() and the existing code should be changed to query specific flags instead... - Matthias > On Feb 8, 2018, at 5:34 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > TL;DR > r317488 changed the way fast math

Op 2013-12-11 om 02:09 schreef syslinux-bot for Matt Fleming: > Commit-ID: 5e59ac11d6d105591d6da742750ea2f804534d43 > Gitweb: http://www.syslinux.org/commit/5e59ac11d6d105591d6da742750ea2f804534d43 > Author: Matt Fleming <matt.fleming at intel.com> > AuthorDate: Wed, 11 Dec 2013 10:03:13 +0000 > Committer: Matt Fleming <matt.fleming at intel.com> >

Agree, but that wouldn’t solve the downgrade problem plus this is probably too late to fix LLVM 6.0 for all the isFast uses. > On Feb 9, 2018, at 10:05 AM, Matthias Braun <mbraun at apple.com> wrote: > > Just wanted to point out part of this even becoming a problem is the use of `isFast()`. > There should be warnings against using isFast() and the existing code should be

Hello! I'm using NVIDIA GeForce GT 640M. And beginning with this commit: commit 142c21b8d493318551932eee2e9d98ff14b473da Author: Christoph Bumiller <e0425955 at student.tuwien.ac.at> Date: Wed Mar 27 22:25:52 2013 +0100 drm/nouveau/drm: bump the driver version to 1.1.1 to report new features till the latest kernel 3.15-rc5 OpenArena game looks like this: