In article <5912ca9e-b4e7-423d-a45d-f4693d1c9...@zoulas.com>,
Christos Zoulas wrote:
>-=-=-=-=-=-
Here's the final changes
- Make ALIGNED_POINTER use __alignof(t) instead of sizeof(t). This is more
correct because it works with non-primitive types and provides the ABI
alignment for the type
> On Feb 17, 2021, at 4:20 PM, Valery Ushakov wrote:
>
> On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote:
>
> This incrementally improves wrong things b/c you still have the "is
> aligned" and "ought to be aligned" conflated in one.
The incremental patch improves things and does
On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote:
> In article ,
> Valery Ushakov wrote:
>
> >But to get back to my main point, PLEASE, can we stop making random
> >aimless changes without prior discussion?
>
> Here's the change I'd like to make:
> - pass the alignment instead of
In article ,
Valery Ushakov wrote:
>But to get back to my main point, PLEASE, can we stop making random
>aimless changes without prior discussion?
Here's the change I'd like to make:
- pass the alignment instead of the mask (as Roy asked and to match the
other macro)
- use alignof to determin
On Tue, Feb 16, 2021 at 18:51:43 -0500, Christos Zoulas wrote:
> On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote:
> -- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)
>
> | Well, it was you who did the definion of ALIGNED_POINTER centralized
> |
On Wed, Feb 17, 2021 at 00:51:03 +0100, Roland Illig wrote:
> 17.02.2021 00:25:10 Valery Ushakov :
> > On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
> >> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the
> >> test is for.
> >>
> >> I intentionally placed it between
On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)
| Well, it was you who did the definion of ALIGNED_POINTER centralized
| and overridable :)
|
| revision 1.400
| date: 2012-01-25 00:03:36 +0400; author: christos
17.02.2021 00:25:10 Valery Ushakov :
> On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
>> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the
>> test is for.
>>
>> I intentionally placed it between (which defines that
>> macro on x86 and some other platforms) and (whi
On 16.02.2021 23:32, Jason Thorpe wrote:
On Feb 16, 2021, at 1:56 PM, Roland Illig wrote:
A downside of this test is that the macro from gets only
evaluated at compile time of the test. The test therefore cannot cover
future updates to without being reinstalled itself. But
at least for th
On Tue, Feb 16, 2021 at 17:53:09 -0500, Christos Zoulas wrote:
> In this case "type" is a struct and we have __alignof() to handle
> it, but does this give the right answer?
>
> Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT and
> can be overriden (the opposite goes for POINTER_
On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
> On 16.02.2021 23:40, Valery Ushakov wrote:
> > On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
> >
> > > On 16.02.2021 19:46, Roy Marples wrote:
> > > > I suggest we change POINTER_ALIGNED_P to accept the alignment value we
On 16.02.2021 23:40, Valery Ushakov wrote:
On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
On 16.02.2021 19:46, Roy Marples wrote:
I suggest we change POINTER_ALIGNED_P to accept the alignment value we
want rather than the bitwise test we supply, like so:
#define POINTER_ALIGNED_P
In this case "type" is a struct and we have __alignof() to handle it, but does
this give the
right answer? Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT
and can be overriden (the opposite goes for POINTER_ALIGNED_P) I am all for
having one
macro, but how can we satisfy all the
On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
> On 16.02.2021 19:46, Roy Marples wrote:
> > I suggest we change POINTER_ALIGNED_P to accept the alignment value we
> > want rather than the bitwise test we supply, like so:
> >
> > #define POINTER_ALIGNED_P(p, a) (((uintptr_t)(p) & ((a
> On Feb 16, 2021, at 1:56 PM, Roland Illig wrote:
>
> A downside of this test is that the macro from gets only
> evaluated at compile time of the test. The test therefore cannot cover
> future updates to without being reinstalled itself. But
> at least for the release builds, it ensures a
On 16.02.2021 19:46, Roy Marples wrote:
I suggest we change POINTER_ALIGNED_P to accept the alignment value we
want rather than the bitwise test we supply, like so:
#define POINTER_ALIGNED_P(p, a) (((uintptr_t)(p) & ((a) - 1))
That's a good definition, clear, simple, obvious, without
16 matches
Mail list logo
