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
> c-family/c-common.c:check_cxx_fundamental_ali
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.
(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( alignof(
>PR libstdc++/62259
>PR libstdc++/65147
>* include/std/atomic (atomic): 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.
>* testsuite/29_atomics/atomi
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 1/2/4/
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 a
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 myse
On 07/04/15 10:51 -0400, Hans-Peter Nilsson wrote:
I was more thinking of something like:
#include
#include
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): " << alignof(s
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
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 t
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 wrot
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) (t
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 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::atomic ao;
+};
+
+container
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)
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-by
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 r
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 r
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 pa
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::atomic (i.e. not the integral or pointer
> specializations) we should increase the alignment
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 hardc
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?
>>
>
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 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 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
Date: Wed Sep 3 15:39:53
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 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.
Instea
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::atomic) > align
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 c
On 03/25/2015 09:22 AM, Jonathan Wakely wrote:
> +static_assert( alignof(std::atomic) > 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 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(
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 align
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.
Instea
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 point
34 matches
Mail list logo
