On Mon, 13 Apr 2015, Hans-Peter Nilsson wrote:
b.cc:5:25: warning: requested alignment 16 is larger than 8 [-Wattributes]
alignas (16) char x[16];
which is mysterious (where does the 8 come from?), until I grep
the error string and find
(check_cxx_fundamental_alignment_constraints is Dodji's, others
CC:ed were already in the thread)
Looking into those atomic things and running tests for cris-elf,
I get FAIL for
libstdc++-v3/testsuite/29_atomics/atomic/65147.cc, specifically
struct S16 {
char c[16];
};
static_assert(
On 13/04/15 06:45 +0200, Hans-Peter Nilsson wrote:
Ever since aligmnent was made sane-ish, 62259.cc has failed for
reasons obvious in the patch. Can I please commit this?
Yes, OK for trunk and the gcc-5-branch, thanks.
PR libstdc++/62259
PR libstdc++/65147
* include/std/atomic (atomicT): Increase alignment for types with
the same size as one of the integral types.
* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error line number.
*
On 07/04/15 14:14 +0100, Jonathan Wakely wrote:
On 03/04/15 12:13 -0700, Richard Henderson wrote:
On 04/03/2015 07:13 AM, Jonathan Wakely wrote:
+++ b/libstdc++-v3/include/std/atomic
@@ -165,9 +165,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct atomic
{
private:
- // Align
On 07/04/15 23:58 -0400, Hans-Peter Nilsson wrote:
I'd expect
alignof(ai): 4 .is_lock_free(): 1
No... wait, that's because atomic_base.h doesn't have the
natural-alignment fix, so it's still broken for
less-than-natural-alignment targets. But will be fixed?
Yes, with my uncommitted patch to
On 05/04/15 21:07 -0400, Hans-Peter Nilsson wrote:
On Fri, 3 Apr 2015, Jonathan Wakely wrote:
On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote:
On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
Why then use __alignof(_M_i) (the object-alignment)
instead of _S_alignment (the deduced alas
On Tue, 7 Apr 2015, Jonathan Wakely wrote:
On 05/04/15 21:07 -0400, Hans-Peter Nilsson wrote:
On Fri, 3 Apr 2015, Jonathan Wakely wrote:
On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote:
On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
Why then use __alignof(_M_i) (the
On Tue, 7 Apr 2015, Jonathan Wakely wrote:
On 07/04/15 06:51 -0400, Hans-Peter Nilsson wrote:
On Tue, 7 Apr 2015, Jonathan Wakely wrote:
On 05/04/15 21:07 -0400, Hans-Peter Nilsson wrote:
We did specify that with the alignas. Is the alignof always
exactly the same as an alignas, if
On 07/04/15 10:51 -0400, Hans-Peter Nilsson wrote:
I was more thinking of something like:
#include atomic
#include iostream
using std::cout;
using std::endl;
struct SoSo {
double d;
int x alignas(sizeof(int));
};
SoSo s __attribute__((__aligned__(16)));
int main(void)
{
cout alignof(s):
On 03/04/15 12:13 -0700, Richard Henderson wrote:
On 04/03/2015 07:13 AM, Jonathan Wakely wrote:
+++ b/libstdc++-v3/include/std/atomic
@@ -165,9 +165,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct atomic
{
private:
- // Align 1/2/4/8/16-byte types the same as integer types of
On 07/04/15 06:51 -0400, Hans-Peter Nilsson wrote:
On Tue, 7 Apr 2015, Jonathan Wakely wrote:
On 05/04/15 21:07 -0400, Hans-Peter Nilsson wrote:
On Fri, 3 Apr 2015, Jonathan Wakely wrote:
On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote:
On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
On Tue, 7 Apr 2015, Jonathan Wakely wrote:
The docs are clear that alignof(s.x) is not related to its position in
struct SoSo: https://gcc.gnu.org/onlinedocs/gcc/Alignment.html
I'm not going to worry about that behaviour changing.
'kthen thanks, quite clear; I should have checked that myself.
On Thu, 26 Mar 2015, Jonathan Wakely wrote:
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/62259.cc
+static_assert(alignof(obj1) == alignof(int64_t),
+ std::atomic not suitably aligned );
+
+struct container_struct {
+ char c[1];
+ std::atomicpower_of_two_obj ao;
On Fri, 3 Apr 2015, Jonathan Wakely wrote:
On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote:
On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
Why then use __alignof(_M_i) (the object-alignment)
instead of _S_alignment (the deduced alas insufficiently
increased type-alignment)?
Isn't
On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
Why then use __alignof(_M_i) (the object-alignment)
instead of _S_alignment (the deduced alas insufficiently
increased type-alignment)?
(The immediate reason is that _S_alignment wasn't there until a
later revision, but the gist of the question
On 04/03/2015 07:13 AM, Jonathan Wakely wrote:
+++ b/libstdc++-v3/include/std/atomic
@@ -165,9 +165,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct atomic
{
private:
- // Align 1/2/4/8/16-byte types the same as integer types of that size.
+ // Align 1/2/4/8/16-byte
On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote:
On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
Why then use __alignof(_M_i) (the object-alignment)
instead of _S_alignment (the deduced alas insufficiently
increased type-alignment)?
Isn't the object aligned to _S_alignment?
(The immediate
On Wed, 25 Mar 2015, Jonathan Wakely wrote:
I've convinced myself that Richard's patch is correct in all cases,
but I think we also want this patch, to fix PR62259 and PR65147.
For the generic std::atomicT (i.e. not the integral or pointer
specializations) we should increase the alignment of
On Thu, 12 Feb 2015, Richard Henderson wrote:
When we fixed PR54005,
Hm, there's confusion. When was this fixed? (Not fixed
AFAICT.) Maybe you mean PR54004, but there was no note there
either. Or maybe there's a typo and you meant some other PR and
that PR54005 is supposedly fixed by this
On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
This is the best I've come up with, does anyone have any better ideas
than the #else branch to hardcode alignment of 16-byte types to 16?
If there's no 16 byte type, are we convinced this matters? I mean, there isn't
a 16-byte atomic instruction
On 31/03/15 07:54 -0700, Richard Henderson wrote:
On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
This is the best I've come up with, does anyone have any better ideas
than the #else branch to hardcode alignment of 16-byte types to 16?
If there's no 16 byte type, are we convinced this matters?
On 03/31/2015 08:03 AM, Jonathan Wakely wrote:
On 31/03/15 07:54 -0700, Richard Henderson wrote:
On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
This is the best I've come up with, does anyone have any better ideas
than the #else branch to hardcode alignment of 16-byte types to 16?
If there's
On 31/03/15 08:13 -0700, Richard Henderson wrote:
On 03/31/2015 08:03 AM, Jonathan Wakely wrote:
On 31/03/15 07:54 -0700, Richard Henderson wrote:
On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
This is the best I've come up with, does anyone have any better ideas
than the #else branch to
On 26/03/15 13:21 +, Jonathan Wakely wrote:
This includes your fix to avoid decreasing alignment, but I didn't add
a test for that as I couldn't make it fail on any of the targets I
test on.
commit f796769ad20c0353490b9f1a7e019e2f0c1771fb
Author: Jonathan Wakely jwak...@redhat.com
Date:
On 12/02/15 13:23 -0800, Richard Henderson wrote:
When we fixed PR54005, making sure that atomic_is_lock_free returns the same
value for all objects of a given type, we probably should have changed the
interface so that we would pass size and alignment rather than size and object
pointer.
On 25/03/15 12:04 -0700, Richard Henderson wrote:
On 03/25/2015 11:49 AM, Jonathan Wakely wrote:
On 25/03/15 11:36 -0700, Richard Henderson wrote:
On 03/25/2015 09:22 AM, Jonathan Wakely wrote:
On 25/03/15 11:39 -0700, Richard Henderson wrote:
On 03/25/2015 09:22 AM, Jonathan Wakely wrote:
On 18/02/15 12:15 +, Jonathan Wakely wrote:
On 12/02/15 13:23 -0800, Richard Henderson wrote:
When we fixed PR54005, making sure that atomic_is_lock_free returns the same
value for all objects of a given type, we probably should have changed the
interface so that we would pass size and
On 25/03/15 11:36 -0700, Richard Henderson wrote:
On 03/25/2015 09:22 AM, Jonathan Wakely wrote:
private:
- _Tp _M_i;
+ // Align 1/2/4/8/16-byte types the same as integer types of that size.
+ // This matches the alignment effects of the C11 _Atomic qualifier.
+ static
On 03/25/2015 11:49 AM, Jonathan Wakely wrote:
On 25/03/15 11:36 -0700, Richard Henderson wrote:
On 03/25/2015 09:22 AM, Jonathan Wakely wrote:
On 25/03/15 11:39 -0700, Richard Henderson wrote:
On 03/25/2015 09:22 AM, Jonathan Wakely wrote:
+static_assert( alignof(std::atomictwoints)
On 03/25/2015 09:22 AM, Jonathan Wakely wrote:
private:
- _Tp _M_i;
+ // Align 1/2/4/8/16-byte types the same as integer types of that size.
+ // This matches the alignment effects of the C11 _Atomic qualifier.
+ static constexpr int _S_alignment
+ = sizeof(_Tp)
On 03/25/2015 09:22 AM, Jonathan Wakely wrote:
+static_assert( alignof(std::atomictwoints) alignof(int),
+ std::atomic not suitably aligned );
This is only true if int64_t has alignment larger than int32_t,
which is unfortunately not always the case.
r~
On 12/02/15 13:23 -0800, Richard Henderson wrote:
When we fixed PR54005, making sure that atomic_is_lock_free returns the same
value for all objects of a given type, we probably should have changed the
interface so that we would pass size and alignment rather than size and object
pointer.
When we fixed PR54005, making sure that atomic_is_lock_free returns the same
value for all objects of a given type, we probably should have changed the
interface so that we would pass size and alignment rather than size and object
pointer.
Instead, we decided that passing null for the object
34 matches
Mail list logo
