similar to: LLVM 3.9 RC binaries should NOT disable assertions.

> I would argue that you should build the RC and the release the same way. I've had to fix bugs were someone had an assert with a side-effect, and the code with asserts turned off didn't work. OK, so it's clearly important to provide and test against RC's in the actual release configuration, especially since assertions can introduce bugs on their own. Arguably however

@Tobias The poly docs build step is still failing, but due to a bug in the particular version of Sphinx used by the www-scripts builder. This seems like something best worked around inside poly. The builds take place hourly and their output is reported on the www-scripts at lists.llvm.org mailing list. On Thu, May 25, 2017 at 12:58 AM, Tobias Grosser <tobias.grosser at inf.ethz.ch > wrote:

Hi Bill, I committed a fix already as r355743 [1], and it fixes `test2` as well. I believe we should merge this into 8.0. /Eric [1] https://github.com/llvm/llvm-project/commit/680e865c313a80b6ec329abde61e1f0c66bdc103 On Fri, Mar 8, 2019 at 5:46 PM Bill Wendling <isanbard at gmail.com> wrote: > Hi Eric, > > The attached patch may help matters, though it now fails because

Hi Will, I would like to request collaborator permissions for the Libc++ github mirror. I plan to use the access to setup Appveyor buildbots for libc++. In order to do this I need to be listed as a collaborator on Github. The alternative to Github access would be setting up the correct webhooks for llvm.org/git/libcxx.git, but this seems harder to both do and maintain. /Eric --------------

> On Apr 20, 2017, at 12:39 AM, Eric Fiselier <eric at efcs.ca> wrote: > > > > On Wed, Apr 19, 2017 at 11:19 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > What would be the status of these buildbots? Is it for your private usage? > > I intend for them to be public Windows buildbots for libc++. I’m not sure

What would be the status of these buildbots? Is it for your private usage? Otherwise having “project' bots” using a non-official mirror may sound like a strange situation to me. — Mehdi > On Apr 19, 2017, at 5:04 PM, Eric Fiselier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Adding cfe-dev list... > > On Wed, Apr 19, 2017 at 5:50 PM, Eric Fiselier <eric at

> On Apr 20, 2017, at 12:30 PM, Eric Fiselier <eric at efcs.ca> wrote: > > > > On Thu, Apr 20, 2017 at 11:06 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Apr 20, 2017, at 12:39 AM, Eric Fiselier <eric at efcs.ca <mailto:eric at efcs.ca>> wrote: >> >> >> >> On Wed, Apr

> Test suite is green but I'm seeing two libc++ test failures when running check-all. What tests are failing? On Fri, Jun 10, 2016 at 5:13 PM, Nikola Smiljanic via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Uploaded Fedora and openSUSE binaries. Test suite is green but I'm seeing > two libc++ test failures when running check-all. I'm pretty sure these were >

On Thu, Jan 21, 2016 at 9:52 PM, Brian Cain <brian.cain at gmail.com> wrote: > On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier <eric at efcs.ca> wrote: > >> >> On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> SuSE Linux Enterprise Server 11SP3 x86_64 >>> >>> Looks like I

Hi all, I would really like to get a patch into 3.6 for libc++. The patch renames template parameters with the names '_A' and '_V' to longer names. '_A' is frequently defined in ctypes.h and that could cause libc++ to not compile. I'm fairly sure the code was added between 3.5 and 3.6 so that would make this a regression. The patch can be found here:

On Aug 10, 2018, at 9:35 PM, Eric Fiselier <eric at efcs.ca> wrote: > > Part of me is still concerned with the future, and the filesystems which are yet to exist. > Me too. But it is best to target modern systems when targeting future systems adds an unnecessary cost. When future systems come into being, it is likely because future hardware is making those future systems

LLVM developers: Does anyone have time and interest to review a libc++ change? https://reviews.llvm.org/D26920 Eric

Hi All, I know we're late in the release process, but I've discovered a regression I believe is serious enough to hold the release [1]. The regression is in usages of `__builtin_constant_p` applied to a dereferenced pointer in a constant expression. In certain cases Clang now rejects this as a non-constant expression [2]. This regression will have a larger impact than it initially

Why did you want the symbols moved out of libc++experimental, and for the header to be moved from <experimental/filesystem> to <filesystem>? It certainly seems like it'd be safer and clearer to move them back to the old locations, but it's not clear to me if that'd be trading off something else of value. Was there some other greater purpose served by the change in

Hans, Are these new RC3 Windows binaries now with asserts disabled? Kind Regards Dan From: Hans Wennborg via cfe-dev<mailto:cfe-dev at lists.llvm.org> Sent: 26 August 2016 22:30 To: llvm-dev<mailto:llvm-dev at lists.llvm.org>; cfe-dev<mailto:cfe-dev at lists.llvm.org>; LLDB Dev<mailto:lldb-dev at lists.llvm.org>; openmp-dev (openmp-dev at

Is there a simple method for compiling a custom assertion header/call into all the LLVM libraries? I want my application to be able to handle any thrown assertions (ie; as an exception) and recover or crash gracefully. I already have a custom header in place in the application's source, however this doesn't have an effect on [most of] the already compiled lib's. -------------- next

Hi All, I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has. First, it's been put in a separate library, libc++fs, for now. Users are responsible for linking the library when they use filesystem. Second, it should still not be considered ABI stable. Vendors should be aware of this before shipping it. Hopefully all the standard and

On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote: > SuSE Linux Enterprise Server 11SP3 x86_64 > > Looks like I see several failures that weren't in 3.7.1. Is there any way > to tell whether these are regressions vs new-to-3.8.0-but-failing? The > MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were > not

Ping. It's been another week. When are we going to get the docs building and updating again? On Tue, May 16, 2017 at 9:01 PM, Eric Fiselier <eric at efcs.ca> wrote: > Ping. Everything is still broken. > > On Wed, May 10, 2017 at 2:39 PM, Eric Fiselier <eric at efcs.ca> wrote: > >> I don't know if that would make a difference. Whenever a CMake file is

> On Aug 10, 2018, at 13:28, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > > > On Thu, Jul 26, 2018 at 9:20 PM, Eric Fiselier via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > Hi All, > > I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has.