This is probably more of a comment on the compare_bench.py side of
things, but here goes anyway...
When comparing two results, both the percentage and absolute differences
can be very important. It is very easy to be misled by percentages. It
is harder to be misled with absolute differences.
ault constructable. For this reason
I'm not going to remove "lock_guard<>", at least not without
further discussion.
On Wed, Jun 15, 2016 at 12:47 PM, Craig, Ben
mailto:ben.cr...@codeaurora.org>> wrote:
On 6/15/2016 1:15 PM, Eric Fiselier wrote:
ted
to compile and be default constructable. For this reason I'm not going
to remove "lock_guard<>", at least not without further discussion.
On Wed, Jun 15, 2016 at 12:47 PM, Craig, Ben <mailto:ben.cr...@codeaurora.org>> wrote:
On 6/15/2016 1:15 PM, Er
On 6/15/2016 1:15 PM, Eric Fiselier wrote:
On Wed, Jun 15, 2016 at 11:45 AM, Craig, Ben via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
Does this change (and the paper) permit declarations like the
following?
lock_guard<> guard();
If that synta
Does this change (and the paper) permit declarations like the following?
lock_guard<> guard();
If that syntax is allowed, then this is also likely allowed...
lock_guard<>(guard);
I would really like the prior two examples to not compile. Here is a
common bug that I see in the wild...
On 3/18/2016 11:54 AM, JF Bastien wrote:
Some architectures support byte granularity memory protection.
Accessing unsolicited bytes can cause a trap on those architectures.
I think it makes sense for atomic and Atomic to get
turned into the 4 byte __atomic intrinsics. Those 4
On 3/18/2016 1:50 AM, Joerg Sonnenberger via cfe-commits wrote:
On Thu, Mar 17, 2016 at 05:56:17PM +, JF Bastien via cfe-commits wrote:
C++ atomics are explicitly designed to avoid problems with touching
adjacent bytes: if `atomic` where `sizeof(T) == 1` requires a 4-byte
`cmpxchg` then it's
I know that MIPS does that, and an out-of-tree implementation of hexagon
implements 1-byte cmpxchg in terms of the 4-byte version. The emulation
code isn't particularly small, and it seems reasonable to make it a
libcall. The emulation code seems sketchy from a correctness
perspective, as you
On 3/4/2016 6:23 AM, Joerg Sonnenberger via cfe-commits wrote:
On Thu, Mar 03, 2016 at 04:50:11PM -0800, Nico Weber via cfe-commits wrote:
On Thu, Mar 3, 2016 at 4:28 PM, Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
On Thu, Mar 03, 2016 at 02:09:17PM -0800, Nico Webe
On 2/19/2016 3:32 PM, Joerg Sonnenberger via cfe-commits wrote:
On Fri, Feb 19, 2016 at 06:14:18PM +, Ben Craig via cfe-commits wrote:
Instead of checking _LIBCPP_LOCALE__L_EXTENSIONS all over, instead
check it once, and define the various *_l symbols once.
If you want to rename using macro
On 2/19/2016 8:40 AM, Joerg Sonnenberger via cfe-commits wrote:
On Thu, Feb 18, 2016 at 10:32:11PM +, Ben Craig via cfe-commits wrote:
The fallback locale functions are also useful on their own for other
lightweight platforms. Putting these fallback implementations in
support/xlocale should
On 2/19/2016 8:36 AM, Joerg Sonnenberger via cfe-commits wrote:
On Thu, Feb 18, 2016 at 03:39:29PM +, Ben Craig via cfe-commits
wrote:
Unfortunately, I have no access to an AIX machine to build with, so
this change has been made blind.
Any reason why this is not using "new" and "delete"? I
FYI, this change and the LLVM version have each broken my libcxx
builds. I cross compile from Linux x64 to Hexagon, and my host machine
doesn't have . The LLVM change was particularly offensive
because I wasn't planning on building LLVM itself.
I have since worked around the issue by making
As an alternative, would it be acceptable to heap allocate these
objects, using the original padding numbers?
On 12/15/2015 5:11 PM, Howard Hinnant wrote:
On Dec 15, 2015, at 5:30 PM, Jonathan Roelofs wrote:
Could these large padding things be related to the fact that the test is used
as a
n the usual
order.
Thoughts?
On Mon, Nov 16, 2015 at 2:28 PM, Craig, Ben via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
I'm fine with this approach. How about I leave the file in place,
but replace the contents with a "using DataRecursiveASTVisitor =
I'm fine with this approach. How about I leave the file in place, but
replace the contents with a "using DataRecursiveASTVisitor =
RecursiveASTVisitor;" and see what breaks? That way I won't need to go
through a large retrofit.
On 11/16/2015 3:28 PM, Richard Smith wrote:
Rather than trying t
16 matches
Mail list logo
