On Fri, Jan 9, 2009 at 4:59 PM, Ian Lance Taylor wrote:
> "Richard Guenther" writes:
>
>> On Fri, Jan 9, 2009 at 4:31 PM, Ian Lance Taylor wrote:
>>> "Richard Guenther" writes:
>>>
> There are many ways to align data without exposing it in the
> ABI--e.g., the alignment of a global arra
"Richard Guenther" writes:
> On Fri, Jan 9, 2009 at 4:31 PM, Ian Lance Taylor wrote:
>> "Richard Guenther" writes:
>>
There are many ways to align data without exposing it in the
ABI--e.g., the alignment of a global array is not part of the ABI, in
that nothing breaks if the alig
"H.J. Lu" writes:
> You can't use _attribute__ ((aligned(max))) directly with memory
> allocator. How about a new macro, __BIGGEST_ALIGNMENT__?
You can use __attribute__ ((aligned)), you just need to also use
__alignof__. I have no objection to __BIGGEST_ALIGMENT__ but that is
a separate discus
On Fri, Jan 9, 2009 at 4:31 PM, Ian Lance Taylor wrote:
> "Richard Guenther" writes:
>
>>> There are many ways to align data without exposing it in the
>>> ABI--e.g., the alignment of a global array is not part of the ABI, in
>>> that nothing breaks if the alignment is increased. Also, there are
"Richard Guenther" writes:
>> There are many ways to align data without exposing it in the
>> ABI--e.g., the alignment of a global array is not part of the ABI, in
>> that nothing breaks if the alignment is increased. Also, there are
>> many programs which simply don't care about an external ABI
On Thu, Jan 8, 2009 at 9:41 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> There are many ways to align data without exposing it in the
>>> ABI--e.g., the alignment of a global array is not part of the ABI, in
>>> that nothing breaks if the alignment is increased. Also, there are
>>> many
On Fri, Jan 9, 2009 at 2:22 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> For that matter, don't we have a problem on x86 GNU/Linux, where
>>> malloc returns an 8-byte alignment but attribute((aligned)) is a 16
>>> byte alignment?
>>
>> I don't think it is the same as MALLOC_ABI_ALIGNMENT
"H.J. Lu" writes:
>> There are many ways to align data without exposing it in the
>> ABI--e.g., the alignment of a global array is not part of the ABI, in
>> that nothing breaks if the alignment is increased. Also, there are
>> many programs which simply don't care about an external ABI.
>>
>
>
On Thu, Jan 8, 2009 at 5:22 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> For that matter, don't we have a problem on x86 GNU/Linux, where
>>> malloc returns an 8-byte alignment but attribute((aligned)) is a 16
>>> byte alignment?
>>
>> I don't think it is the same as MALLOC_ABI_ALIGNMENT
"H.J. Lu" writes:
>> For that matter, don't we have a problem on x86 GNU/Linux, where
>> malloc returns an 8-byte alignment but attribute((aligned)) is a 16
>> byte alignment?
>
> I don't think it is the same as MALLOC_ABI_ALIGNMENT.
> attribute((aligned)) is something determined by compiler,
> w
On Thu, Jan 8, 2009 at 3:35 PM, Ian Lance Taylor wrote:
> "Richard Guenther" writes:
>
>> I don't think we should encourage more uses of __attribute__((aligned)).
>
> But then how can one write a general purpose portable memory
> allocator?
Your C library may provide
int posix_memalign(void **m
On Thu, Jan 8, 2009 at 3:35 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> For 4.4, we can apply my patch:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00367.html
>>
>> and update document with
>>
>> As in the preceding examples, you can explicitly specify the alignment
>> (in bytes)
Michael Meissner writes:
>> For that matter, don't we have a problem on x86 GNU/Linux, where
>> malloc returns an 8-byte alignment but attribute((aligned)) is a 16
>> byte alignment?
>
> In that case, malloc should be changed to return items that are 16-byte
> aligned
> if any type needs 16-byte
On Thu, Jan 08, 2009 at 03:35:29PM -0800, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
> > For 4.4, we can apply my patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00367.html
> >
> > and update document with
> >
> > As in the preceding examples, you can explicitly specify the alignme
"Richard Guenther" writes:
> I don't think we should encourage more uses of __attribute__((aligned)).
But then how can one write a general purpose portable memory
allocator?
Ian
"H.J. Lu" writes:
> For 4.4, we can apply my patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00367.html
>
> and update document with
>
> As in the preceding examples, you can explicitly specify the alignment
> (in bytes) that you wish the compiler to use for a given variable or
> structur
On Thu, Jan 8, 2009 at 1:36 PM, Richard Guenther
wrote:
> On Thu, Jan 8, 2009 at 10:17 PM, H.J. Lu wrote:
>> On Thu, Jan 8, 2009 at 12:40 PM, Ian Lance Taylor wrote:
>>> "H.J. Lu" writes:
>>>
We can solve it with
1. A target should define MALLOC_ABI_ALIGNMENT properly.
2. g+
On Thu, Jan 8, 2009 at 10:17 PM, H.J. Lu wrote:
> On Thu, Jan 8, 2009 at 12:40 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> We can solve it with
>>>
>>> 1. A target should define MALLOC_ABI_ALIGNMENT properly.
>>> 2. g++ should issue an error when the default new operator
>>> is used
On Thu, Jan 8, 2009 at 12:40 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> We can solve it with
>>
>> 1. A target should define MALLOC_ABI_ALIGNMENT properly.
>> 2. g++ should issue an error when the default new operator
>> is used on a type whose alignment is greater than
>> MALLOC_ABI_AL
"H.J. Lu" writes:
> We can solve it with
>
> 1. A target should define MALLOC_ABI_ALIGNMENT properly.
> 2. g++ should issue an error when the default new operator
> is used on a type whose alignment is greater than
> MALLOC_ABI_ALIGNMENT.
> 3. It is user's responsibility to provide a new operator
On Thu, Jan 8, 2009 at 11:38 AM, Ian Lance Taylor wrote:
>> For the memory allocator writers, they should provide an interface
>> with a parameter to specify alignment requirement. User can use
>> __attribute__ ((aligned (XXX))) to tell compiler memory alignment.
>
> Think harder about new[] and a
"H.J. Lu" writes:
> On Thu, Jan 8, 2009 at 10:49 AM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> It it hard to guess what the alignment should be for C++ new operator.
>>> Whatever you choose today may not be appropriate tomorrow
>>> or for others. I think g++ should issue a warning whe
On Thu, Jan 8, 2009 at 10:49 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> It it hard to guess what the alignment should be for C++ new operator.
>> Whatever you choose today may not be appropriate tomorrow
>> or for others. I think g++ should issue a warning when new operator
>> is used o
"H.J. Lu" writes:
> It it hard to guess what the alignment should be for C++ new operator.
> Whatever you choose today may not be appropriate tomorrow
> or for others. I think g++ should issue a warning when new operator
> is used on a type whose alignment greater than MALLOC_ABI_ALIGNMENT:
The
On Thu, Jan 8, 2009 at 10:15 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> Given that __attribute__ ((aligned (max))) may change, I don't
>>> think it is very useful. A portable generic memory allocator should
>>> take an additional argument for alignment.
>>>
>>
>> If we really want the
"H.J. Lu" writes:
>> Given that __attribute__ ((aligned (max))) may change, I don't
>> think it is very useful. A portable generic memory allocator should
>> take an additional argument for alignment.
>>
>
> If we really want the maximum useful alignment for the target machine
> we are compiling
On Thu, Jan 8, 2009 at 7:56 AM, H.J. Lu wrote:
> On Wed, Jan 7, 2009 at 4:44 PM, Ian Lance Taylor wrote:
>> "Ye, Joey" writes:
>>
>>> From: Ian Lance Taylor [mailto:i...@google.com]:
Therefore, I propose that we do the following:
1) Introduce __attribute__ ((aligned (scalar))). T
On Wed, Jan 7, 2009 at 4:44 PM, Ian Lance Taylor wrote:
> "Ye, Joey" writes:
>
>> From: Ian Lance Taylor [mailto:i...@google.com]:
>>> Therefore, I propose that we do the following:
>>>
>>> 1) Introduce __attribute__ ((aligned (scalar))). This will be
>>>documented as having a fixed value fo
"Ye, Joey" writes:
> From: Ian Lance Taylor [mailto:i...@google.com]:
>> Therefore, I propose that we do the following:
>>
>> 1) Introduce __attribute__ ((aligned (scalar))). This will be
>>documented as having a fixed value for each ABI. The value will be
>>guaranteed to be sufficient
From: Ian Lance Taylor [mailto:i...@google.com]:
> Therefore, I propose that we do the following:
>
> 1) Introduce __attribute__ ((aligned (scalar))). This will be
>documented as having a fixed value for each ABI. The value will be
>guaranteed to be sufficient to hold any ordinary non-ve
"H.J. Lu" writes:
> On Wed, Jan 7, 2009 at 2:47 PM, Ian Lance Taylor wrote:
>> 2) Introduce __attribute__ ((aligned (max))). This will be documented
>> as having the largest value available for any version of the
>> architecture, and thus in particular it may change if new versions
>> of
On Wed, Jan 7, 2009 at 2:47 PM, Ian Lance Taylor wrote:
> 2) Introduce __attribute__ ((aligned (max))). This will be documented
> as having the largest value available for any version of the
> architecture, and thus in particular it may change if new versions
> of the architecture are relea
Jakub pointed out on gcc-patches that changing the value of
__attribute__ ((aligned)) has difficulties.
Historically this value was never intended to be fixed for all time.
For example, for the i386, it was last changed here:
Tue Jan 18 16:19:55 MET 2000 Jan Hubicka
* i386.h (BIGGEST_
"H.J. Lu" writes:
> Index: gcc/doc/extend.texi
> ===
> --- gcc/doc/extend.texi (revision 4884)
> +++ gcc/doc/extend.texi (working copy)
> @@ -3697,9 +3697,8 @@ that forces the union to be double-word
> As in the precedi
On Wed, Jan 7, 2009 at 8:30 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Fixing BIGGEST_ALIGNMENT to 16 may require extensive changes.
>> I am thinking to add DEFAULT_ALIGNMENT with
>>
>> #ifndef DEFAULT_ALIGNMENT
>> #define DEFAULT_ALIGNMENT BIGGEST_ALIGNMENT
>> #endif
>>
>> and use it o
"Richard Guenther" writes:
>> That is, there are two conflicting requirements: maintaining a stable
>> ABI on a single platform, and supporting a cross-platform API. I
>> would argue that code which runs on a single platform and needs a
>> stable ABI should avoid __attribute__ ((aligned)). That
"H.J. Lu" writes:
> Fixing BIGGEST_ALIGNMENT to 16 may require extensive changes.
> I am thinking to add DEFAULT_ALIGNMENT with
>
> #ifndef DEFAULT_ALIGNMENT
> #define DEFAULT_ALIGNMENT BIGGEST_ALIGNMENT
> #endif
>
> and use it only for attribute((aligned)).
This does need to be done, but DEFAUL
On Wed, Jan 7, 2009 at 5:27 PM, Ian Lance Taylor wrote:
> "Richard Guenther" writes:
>
>> As there is no hardware implementation of AVX available I think
>> we definitely should stay with 16 for 4.4.
>
> That makes sense.
>
>> And IMNSHO also for
>> all future - __attribute__((aligned)) is part o
"Richard Guenther" writes:
> As there is no hardware implementation of AVX available I think
> we definitely should stay with 16 for 4.4.
That makes sense.
> And IMNSHO also for
> all future - __attribute__((aligned)) is part of the ABI, and if it is
> not the only user of BIGGEST_ALIGNMENT the
On Wed, Jan 7, 2009 at 4:55 PM, Ian Lance Taylor wrote:
> "Ye, Joey" writes:
>
>> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for
>> all x86 target, and extend to 64 or more bytes in future.
>
> Assuming that code compiled with -mavx is intended to interoperate
> with code compi
On Wed, Jan 7, 2009 at 7:55 AM, Ian Lance Taylor wrote:
> "Ye, Joey" writes:
>
>> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for
>> all x86 target, and extend to 64 or more bytes in future.
>
> Assuming that code compiled with -mavx is intended to interoperate
> with code compi
"Ye, Joey" writes:
> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for
> all x86 target, and extend to 64 or more bytes in future.
Assuming that code compiled with -mavx is intended to interoperate
with code compiled without -mavx, I believe that this is the only
viable long-term
On Wed, Jan 7, 2009 at 1:22 AM, Ye, Joey wrote:
> This is about http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38736 and I'd
> rather discuss it in gcc mail list. Basicly the problem is shown as following
> example:
>
> Case 1 (on x86 or x86_64):
> $ cat i.h
> struct s
> {
>char dummy0;
>//
On Wed, Jan 7, 2009 at 10:22 AM, Ye, Joey wrote:
> This is about http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38736 and I'd
> rather discuss it in gcc mail list. Basicly the problem is shown as following
> example:
>
> Case 1 (on x86 or x86_64):
> $ cat i.h
> struct s
> {
>char dummy0;
>/
44 matches
Mail list logo
