Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #106789 > unrolled thread

struct padding question

Back to article view | Back to comp.lang.c

Contents

  struct padding question MehdiAmini <atorrses@gmail.com> - 2017-03-23 14:28 +0430
    Re: struct padding question David Brown <david.brown@hesbynett.no> - 2017-03-23 11:28 +0100
      Re: struct padding question MehdiAmini <atorrses@gmail.com> - 2017-03-23 16:44 +0430
        Re: struct padding question jm.bourguet@gmail.com - 2017-03-23 05:30 -0700
        Re: struct padding question Keith Thompson <kst-u@mib.org> - 2017-03-23 08:45 -0700
      Re: struct padding question Noob <root@127.0.0.1> - 2017-04-01 19:15 +0200
        Re: struct padding question tim prince <n8tm@aol.com> - 2017-04-01 14:41 -0400
          Re: struct padding question supercat@casperkitty.com - 2017-04-02 09:15 -0700
            Re: struct padding question scott@slp53.sl.home (Scott Lurndal) - 2017-04-03 13:51 +0000
              Re: struct padding question supercat@casperkitty.com - 2017-04-03 07:48 -0700
                Re: struct padding question scott@slp53.sl.home (Scott Lurndal) - 2017-04-03 15:47 +0000
                  Re: struct padding question supercat@casperkitty.com - 2017-04-03 09:24 -0700
        Re: struct padding question Keith Thompson <kst-u@mib.org> - 2017-04-01 11:43 -0700
        Re: struct padding question Robert Wessel <robertwessel2@yahoo.com> - 2017-04-01 13:46 -0500
          Re: struct padding question Keith Thompson <kst-u@mib.org> - 2017-04-01 12:00 -0700
            Re: struct padding question Robert Wessel <robertwessel2@yahoo.com> - 2017-04-01 16:40 -0500
              Re: struct padding question Keith Thompson <kst-u@mib.org> - 2017-04-01 15:24 -0700
                Re: struct padding question Robert Wessel <robertwessel2@yahoo.com> - 2017-04-03 17:46 -0500
    Re: struct padding question BartC <bc@freeuk.com> - 2017-03-23 11:50 +0000
      Re: struct padding question David Brown <david.brown@hesbynett.no> - 2017-03-23 14:08 +0100
        Re: struct padding question BartC <bc@freeuk.com> - 2017-03-23 13:31 +0000
          Re: struct padding question David Brown <david.brown@hesbynett.no> - 2017-03-23 14:46 +0100
            Re: struct padding question BartC <bc@freeuk.com> - 2017-03-23 14:07 +0000
              Re: struct padding question David Brown <david.brown@hesbynett.no> - 2017-03-23 15:52 +0100
                Re: struct padding question scott@slp53.sl.home (Scott Lurndal) - 2017-03-23 17:19 +0000
                  Re: struct padding question David Brown <david.brown@hesbynett.no> - 2017-03-23 19:57 +0100
        Re: struct padding question Ian Pilcher <arequipeno@gmail.com> - 2017-03-23 08:52 -0500
          Re: struct padding question David Brown <david.brown@hesbynett.no> - 2017-03-23 15:54 +0100
            Re: struct padding question supercat@casperkitty.com - 2017-03-23 08:29 -0700
    Re: struct padding question GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-23 14:04 +0100
      Re: struct padding question MehdiAmini <atorrses@gmail.com> - 2017-03-23 20:32 +0430
        Re: struct padding question GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-23 18:35 +0100
        Re: struct padding question supercat@casperkitty.com - 2017-03-23 12:02 -0700
          Re: struct padding question Keith Thompson <kst-u@mib.org> - 2017-03-23 12:21 -0700
            Re: struct padding question supercat@casperkitty.com - 2017-03-23 12:55 -0700
    Re: struct padding question Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:12 -0500

Page 1 of 2  [1] 2  Next page →

#106789 — struct padding question

// struct padding question

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>

#define N 6

static struct data
{   uint64_t ctr[N];
     long double mean;
     long double variance;
     long double * probability_ptr;

} my_data;

void init_data( struct data* const);

int main(void)
{
     init_data(&my_data);

     return EXIT_SUCCESS;
}

void init_data(struct data * const data_ptr)
{
     data_ptr->probability_ptr = NULL;
     for(long i = 0; i<N; i++)
         data_ptr->ctr[i] = 0;
     data_ptr->mean = (long double)0.0;
     data_ptr->variance = (long double)0.0;

     return;
}

// Compiling the above code I get the warning, how to fix it?

clang   -pedantic -Weverything -Wall -m64 -std=c11

warning: padding size of 'struct data' with 8 bytes to alignment 
boundary [-Wpadded]
static struct data
               ^

-- 
Farewell.

[toc] | [next] | [standalone]

#106790

On 23/03/17 10:58, MehdiAmini wrote:
> 
> // struct padding question
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <inttypes.h>
> 
> #define N 6
> 
> static struct data
> {   uint64_t ctr[N];
>     long double mean;
>     long double variance;
>     long double * probability_ptr;
> 
> } my_data;
> 
> void init_data( struct data* const);
> 
> int main(void)
> {
>     init_data(&my_data);
> 
>     return EXIT_SUCCESS;
> }
> 
> void init_data(struct data * const data_ptr)
> {
>     data_ptr->probability_ptr = NULL;
>     for(long i = 0; i<N; i++)
>         data_ptr->ctr[i] = 0;
>     data_ptr->mean = (long double)0.0;
>     data_ptr->variance = (long double)0.0;
> 
>     return;
> }
> 
> // Compiling the above code I get the warning, how to fix it?
> 
> clang   -pedantic -Weverything -Wall -m64 -std=c11
> 
> warning: padding size of 'struct data' with 8 bytes to alignment
> boundary [-Wpadded]
> static struct data
>               ^

When you define a struct in C, the compiler may add extra "padding"
bytes in order to make sure all the alignments are correct for the
struct members.  It may also add padding at the end of the struct, so
that alignments would be correct in an array of the structs.

This is normal C behaviour.  But sometimes, people don't want to waste
this space, or they may have expected their struct to fit accurately so
that padding indicates a mistake in their code.  Thus some compilers
(gcc and clang, certainly, but maybe many others) can warn if they add
padding.  This is controlled by the "-Wpadded" or "-Wno-padded" flags.
Normally, this warning is disabled - gcc does not include it in "-Wall
-Wextra".  Apparently, clang has it in "-Weverything".

You may decide that this warning is not a problem - for most code,
padding bytes are not an issue.  Then you simply add "-Wno-padded" to
your compiler line.  This does not change your code, but it hides the
warning.

Alternatively, you need to re-arrange your struct so that there are no
paddings needed.

The struct you have now is:

struct data {
	uint64_t ctr[6];	// 8-byte alignment, 8x6 data
	long double mean;	// 16-byte alignment, 16-byte data
	long double variance;	// 16-byte alignment, 16-byte data
	long double * p_ptr;	// 8-byte alignment, 8-byte data

	// inserted by compiler...
	uint64_t padding;	// 8-byte alignment, 8-byte data
};

This final hidden padding is added to make the whole struct a multiple
of 16 bytes.  If you add it explicitly, you will get the same structure
in your code and no warning.

Note that such alignments and paddings are implementation-dependent - on
an implementation with 8-byte "long double", or a platform with an 8
byte (or less) maximum alignment, there would be no padding here.

[toc] | [prev] | [next] | [standalone]

#106793

On 03/23/2017 02:58 PM, David Brown wrote:
> On 23/03/17 10:58, MehdiAmini wrote:

[...]

> You may decide that this warning is not a problem - for most code,
> padding bytes are not an issue.  Then you simply add "-Wno-padded" to
> your compiler line.  This does not change your code, but it hides the
> warning.
>
> Alternatively, you need to re-arrange your struct so that there are no
> paddings needed.
>

[...]

Can I use alignas or alignof to fix the warning?


-- 
Farewell.

[toc] | [prev] | [next] | [standalone]

#106794

Le jeudi 23 mars 2017 13:14:39 UTC+1, Mehdi Amini Valashani son of Bahram a écrit :
> On 03/23/2017 02:58 PM, David Brown wrote:
> > On 23/03/17 10:58, MehdiAmini wrote:
> 
> [...]
> 
> > You may decide that this warning is not a problem - for most code,
> > padding bytes are not an issue.  Then you simply add "-Wno-padded" to
> > your compiler line.  This does not change your code, but it hides the
> > warning.
> >
> > Alternatively, you need to re-arrange your struct so that there are no
> > paddings needed.
> >
> 
> [...]
> 
> Can I use alignas or alignof to fix the warning?

No: you can't use alignas to weaken the alignment requirement.

The issue here is that your struct has a natural size which is not a multiple of its alignment and that C demands that the size of a struct is a multiple of its alignment, thus padding is added to increase the size of the struct to the next multiple of its alignment.

You can not "fix" that without modifying the struct, and any fix will have the same effect than what is done automatically, excepted that it would be counterproductive on some platform (for instance, one were long double has a alignment of 8 -- perhaps because it is not represented differently than double).


Insisting to both have every potential warnings active and compile with no warning is usually unwise.  There are some warnings which are there just for periodic review or when issue hunting -- like this one -- or even for special circumstances -- gcc had, perhaps still have, warnings to help porting from K&R C to standard C; activating and fixing those for a program written in standard C makes usually no sense.

Yours,

-- 
Jean-Marc

[toc] | [prev] | [next] | [standalone]

#106809

MehdiAmini <atorrses@gmail.com> writes:
> On 03/23/2017 02:58 PM, David Brown wrote:
>> On 23/03/17 10:58, MehdiAmini wrote:
> [...]
>
>> You may decide that this warning is not a problem - for most code,
>> padding bytes are not an issue.  Then you simply add "-Wno-padded" to
>> your compiler line.  This does not change your code, but it hides the
>> warning.
>>
>> Alternatively, you need to re-arrange your struct so that there are no
>> paddings needed.
>>
>
> [...]
>
> Can I use alignas or alignof to fix the warning?

Exactly what problem are you trying to solve?

The simplest way to avoid the warning is to add "-Wno-padded" to
your compiler command line.  If you want the structure not to have
padding, that's a more complicated question.  In some cases you can
rearrange the member declarations, but in this case you could add
a dummy member to occupy the space that would otherwise be padding.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#107586

On 23/03/2017 11:28, David Brown wrote:

> struct data {
> 	uint64_t ctr[6];	// 8-byte alignment, 8x6 data
> 	long double mean;	// 16-byte alignment, 16-byte data
> 	long double variance;	// 16-byte alignment, 16-byte data
> 	long double * p_ptr;	// 8-byte alignment, 8-byte data
> 
> 	// inserted by compiler...
> 	uint64_t padding;	// 8-byte alignment, 8-byte data
> };

I think some platforms have sizeof(long double) = 10?
(I have x86 in mind, with the 80-bit FP numbers.)

Regards.

[toc] | [prev] | [next] | [standalone]

#107593

On 4/1/2017 1:15 PM, Noob wrote:
> On 23/03/2017 11:28, David Brown wrote:
>
>> struct data {
>> 	uint64_t ctr[6];	// 8-byte alignment, 8x6 data
>> 	long double mean;	// 16-byte alignment, 16-byte data
>> 	long double variance;	// 16-byte alignment, 16-byte data
>> 	long double * p_ptr;	// 8-byte alignment, 8-byte data
>>
>> 	// inserted by compiler...
>> 	uint64_t padding;	// 8-byte alignment, 8-byte data
>> };
>
> I think some platforms have sizeof(long double) = 10?
> (I have x86 in mind, with the 80-bit FP numbers.)
>

No, compilers which follow the precedent of gcc store 80-bit long double 
aligned to 12 bytes for x86 32-bit and 16 bytes for x86_64 64-bit (as 
Intel used to recommend before they began recommending not using that 
data type).  So it's non-portable to make assumptions about this.

-- 
Tim Prince

[toc] | [prev] | [next] | [standalone]

#107650

On Saturday, April 1, 2017 at 1:41:48 PM UTC-5, tim prince wrote:
> No, compilers which follow the precedent of gcc store 80-bit long double 
> aligned to 12 bytes for x86 32-bit and 16 bytes for x86_64 64-bit (as 
> Intel used to recommend before they began recommending not using that 
> data type).  So it's non-portable to make assumptions about this.

Why wouldn't the optimal alignment be 16 bits on any system with a 64-bit or
smaller bus?  Unless the bus size gets to be larger than 64 bits, every load
is either going to precisely fill some number of words (8-bit or 16-bit bus)
or else is going to be whole number of words plus an extra 16-bit chunk (the
larger bus case).  Only in the 128-bit bus case would alignment matter, and
in that case the optimal alignment wouldn't depend upon whether the CPU was
in 32-bit or 64-bit mode.

[toc] | [prev] | [next] | [standalone]

#107671

supercat@casperkitty.com writes:
>On Saturday, April 1, 2017 at 1:41:48 PM UTC-5, tim prince wrote:
>> No, compilers which follow the precedent of gcc store 80-bit long double 
>> aligned to 12 bytes for x86 32-bit and 16 bytes for x86_64 64-bit (as 
>> Intel used to recommend before they began recommending not using that 
>> data type).  So it's non-portable to make assumptions about this.
>
>Why wouldn't the optimal alignment be 16 bits on any system with a 64-bit or
>smaller bus?  

Bus?  What bus?   FWIW, the last three generations of Intel processors
and several other high-end RISC server processors have multiple
bi-directional  512-bit-wide (or more) rings connecting
the cores to each other (and the on-chip memory controllers) sufficient
to transfer entire cache lines from LLC to per-core caches in a single
clock.

Other processors use non-blocking crossbar switches.

The front-side-bus is dead, jim.

>Unless the bus size gets to be larger than 64 bits, every load
>is either going to precisely fill some number of words (8-bit or 16-bit bus)
>or else is going to be whole number of words plus an extra 16-bit chunk (the
>larger bus case).  Only in the 128-bit bus case would alignment matter, and
>in that case the optimal alignment wouldn't depend upon whether the CPU was
>in 32-bit or 64-bit mode.

[toc] | [prev] | [next] | [standalone]

#107673

On Monday, April 3, 2017 at 8:52:01 AM UTC-5, Scott Lurndal wrote:
> supercat writes:
> >Why wouldn't the optimal alignment be 16 bits on any system with a 64-bit or
> >smaller bus?  
> 
> Bus?  What bus?   FWIW, the last three generations of Intel processors
> and several other high-end RISC server processors have multiple
> bi-directional  512-bit-wide (or more) rings connecting
> the cores to each other (and the on-chip memory controllers) sufficient
> to transfer entire cache lines from LLC to per-core caches in a single
> clock.

Nowadays processors have very wide on-chip buses that connect to cache, and
only slightly-less-wide buses that connect to main memory, but it was not
always thus.

> Other processors use non-blocking crossbar switches.
> 
> The front-side-bus is dead, jim.

I'm curious on what systems there would have been an advantage to having
32-bit alignment but not 128-bit alignment.  If objects are randomly aligned
at 64-bit boundaries and cache lines are 128N bits, then 1/(2N-1) objects
will span a cache-line boundary.  If objects were randomly aligned at 32-bit
boundaries, the fraction would be the same, and likewise if they are aligned
at 16-bit boundaries.  It may be that Intel decided not to support efficient
80-bit fetches with all 16-bit alignments, but there is no inherent reason
that objects of that size should need to be less efficient with 16-bit
alignment than with coarser alignment.

[toc] | [prev] | [next] | [standalone]

#107674

supercat@casperkitty.com writes:
>On Monday, April 3, 2017 at 8:52:01 AM UTC-5, Scott Lurndal wrote:
>> supercat writes:
>> >Why wouldn't the optimal alignment be 16 bits on any system with a 64-bit or
>> >smaller bus?  
>> 
>> Bus?  What bus?   FWIW, the last three generations of Intel processors
>> and several other high-end RISC server processors have multiple
>> bi-directional  512-bit-wide (or more) rings connecting
>> the cores to each other (and the on-chip memory controllers) sufficient
>> to transfer entire cache lines from LLC to per-core caches in a single
>> clock.
>
>Nowadays processors have very wide on-chip buses that connect to cache, and
>only slightly-less-wide buses that connect to main memory, but it was not
>always thus.

For which we have NTTP://alt.computers.folklore.

>
>> Other processors use non-blocking crossbar switches.
>> 
>> The front-side-bus is dead, jim.
>
>I'm curious on what systems there would have been an advantage to having
>32-bit alignment but not 128-bit alignment. 

Struct alignment, for example has two important characteristics:

  1) Field alignment on natural boundaries (for optimal access)
  2) Total size alignment on appropriate boundaries for correctness
     when accessing fields in arrays of objects.

Take ARMv8 (64-bit) for instance.   The stack pointer must always
be 16-byte aligned (the hardware will fault any operation that would
result in a non-16-byte aligned stack pointer).

> If objects are randomly aligned
>at 64-bit boundaries and cache lines are 128N bits, then 1/(2N-1) objects
>will span a cache-line boundary.  If objects were randomly aligned at 32-bit
>boundaries, the fraction would be the same, and likewise if they are aligned
>at 16-bit boundaries.  It may be that Intel decided not to support efficient
>80-bit fetches with all 16-bit alignments, but there is no inherent reason
>that objects of that size should need to be less efficient with 16-bit
>alignment than with coarser alignment.

Consider pushing one of those 10-byte floats on the stack... Almost every stack
access thereafter will be unaligned, and thus performance will suffer
(assuming the AF flag isn't set).

Even _within_ a cache line, unaligned accesses have a performance penalty.

[toc] | [prev] | [next] | [standalone]

#107677

On Monday, April 3, 2017 at 10:47:30 AM UTC-5, Scott Lurndal wrote:
> supercat writes:
> >Nowadays processors have very wide on-chip buses that connect to cache, and
> >only slightly-less-wide buses that connect to main memory, but it was not
> >always thus.
> 
> For which we have NTTP://alt.computers.folklore.

You were saying bus width is an antiquated consideration.  So which are
you calling folklore--the idea that it's no longer a consideration (an
idea you were just promoting) or the idea that it ever was (which can be
confirmed by examining data sheets of older processors)?

> >I'm curious on what systems there would have been an advantage to having
> >32-bit alignment but not 128-bit alignment. 

> Take ARMv8 (64-bit) for instance.   The stack pointer must always
> be 16-byte aligned (the hardware will fault any operation that would
> result in a non-16-byte aligned stack pointer).

Many systems have required that the stack pointer have an alignment
coarser than the size of objects placed upon it.  The Motorola 68000, for
example, had instructions to push and pop 16-bit values from the stack,
but such instructions would adjust the stack pointer by 4 rather than by
2, so as to maintain 32-bit alignment.  On family members with a 16-bit
data bus, pushing or popping a 16-bit value would save four cycles versus
a 32-bit value, but keeping the stack aligned would ensure good performance
on the later family members with a 32-bit bus.

> > If objects are randomly aligned
> >at 64-bit boundaries and cache lines are 128N bits, then 1/(2N-1) objects
> >will span a cache-line boundary.  If objects were randomly aligned at 32-bit
> >boundaries, the fraction would be the same, and likewise if they are aligned
> >at 16-bit boundaries.  It may be that Intel decided not to support efficient
> >80-bit fetches with all 16-bit alignments, but there is no inherent reason
> >that objects of that size should need to be less efficient with 16-bit
> >alignment than with coarser alignment.
> 
> Consider pushing one of those 10-byte floats on the stack... Almost every stack
> access thereafter will be unaligned, and thus performance will suffer
> (assuming the AF flag isn't set).

So pad the items when pushing to the stack.  Nothing in the C Standard says
that objects placed on the stack need to have the same padding as those
placed elsewhere.  The 32-bit ARM ABI, for example, seems to call for 64-bit
values to be 64-bit aligned on the stack, even though elsewhere in memory
such values are often only 32-bit aligned.

> Even _within_ a cache line, unaligned accesses have a performance penalty.

If cache lines are divided into power-of-two-size pieces which can be
accessed in whole or in part, the number of accesses required to load or
store an 80-bit value would be independent of bits 1-2 of the address.
Whether a processor includes the circuitry needed to handle shifts of
arbitrary alignment would be another question, though such circuitry would
be advantageous in enough other situations (e.g. a bulk memory copy between
differently-aligned regions) that I would think it worthwhile to include.

[toc] | [prev] | [next] | [standalone]

#107594

Noob <root@127.0.0.1> writes:
> On 23/03/2017 11:28, David Brown wrote:
>> struct data {
>> 	uint64_t ctr[6];	// 8-byte alignment, 8x6 data
>> 	long double mean;	// 16-byte alignment, 16-byte data
>> 	long double variance;	// 16-byte alignment, 16-byte data
>> 	long double * p_ptr;	// 8-byte alignment, 8-byte data
>> 
>> 	// inserted by compiler...
>> 	uint64_t padding;	// 8-byte alignment, 8-byte data
>> };
>
> I think some platforms have sizeof(long double) = 10?
> (I have x86 in mind, with the 80-bit FP numbers.)

The only values for sizeof (long double) I've seen are 8, 12, and 16.
Some implementations might pad a 10-byte long double to 12 bytes.
(Of course I haven't seen all implementations.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#107596

On Sat, 1 Apr 2017 19:15:25 +0200, Noob <root@127.0.0.1> wrote:

>On 23/03/2017 11:28, David Brown wrote:
>
>> struct data {
>> 	uint64_t ctr[6];	// 8-byte alignment, 8x6 data
>> 	long double mean;	// 16-byte alignment, 16-byte data
>> 	long double variance;	// 16-byte alignment, 16-byte data
>> 	long double * p_ptr;	// 8-byte alignment, 8-byte data
>> 
>> 	// inserted by compiler...
>> 	uint64_t padding;	// 8-byte alignment, 8-byte data
>> };
>
>I think some platforms have sizeof(long double) = 10?
>(I have x86 in mind, with the 80-bit FP numbers.)


There have been implementations of, 10-byte (80-bit), x86 long double
which have 2, 4, 8 and 16 byte alignment requirements.

For example, amongst compilers actually supporting the 80-bit type, MS
and Borland's 16-bit compilers use 2-byte alignment, several 32-bit
(typical x86 GCC, for example) compilers use 4B alignment, Watcom uses
8B in both 16 and 32-bit versions, and most *nix compilers on 64B use
16B alignment, as does ICC on Windows in both 32 and 64B modes).  

*Not* intended to be an exhaustive list.

[toc] | [prev] | [next] | [standalone]

#107597

Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> There have been implementations of, 10-byte (80-bit), x86 long double
> which have 2, 4, 8 and 16 byte alignment requirements.
>
> For example, amongst compilers actually supporting the 80-bit type, MS
> and Borland's 16-bit compilers use 2-byte alignment, several 32-bit
> (typical x86 GCC, for example) compilers use 4B alignment, Watcom uses
> 8B in both 16 and 32-bit versions, and most *nix compilers on 64B use
> 16B alignment, as does ICC on Windows in both 32 and 64B modes).  
>
> *Not* intended to be an exhaustive list.

The size of a type must be a whole multiple of its alignment; arrays
cannot have gaps between elements.  If a 10-byte floating-point type
requires 4-byte alignment, it must be padded to at least 12 bytes.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#107603

On Sat, 01 Apr 2017 12:00:00 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>[...]
>> There have been implementations of, 10-byte (80-bit), x86 long double
>> which have 2, 4, 8 and 16 byte alignment requirements.
>>
>> For example, amongst compilers actually supporting the 80-bit type, MS
>> and Borland's 16-bit compilers use 2-byte alignment, several 32-bit
>> (typical x86 GCC, for example) compilers use 4B alignment, Watcom uses
>> 8B in both 16 and 32-bit versions, and most *nix compilers on 64B use
>> 16B alignment, as does ICC on Windows in both 32 and 64B modes).  
>>
>> *Not* intended to be an exhaustive list.
>
>The size of a type must be a whole multiple of its alignment; arrays
>cannot have gaps between elements.  If a 10-byte floating-point type
>requires 4-byte alignment, it must be padded to at least 12 bytes.


That's true, but MS/Borland long doubles on their 16-bit compilers had
a size of 10 bytes (and 2B alignment).

[toc] | [prev] | [next] | [standalone]

#107609

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sat, 01 Apr 2017 12:00:00 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>[...]
>>> There have been implementations of, 10-byte (80-bit), x86 long double
>>> which have 2, 4, 8 and 16 byte alignment requirements.
>>>
>>> For example, amongst compilers actually supporting the 80-bit type, MS
>>> and Borland's 16-bit compilers use 2-byte alignment, several 32-bit
>>> (typical x86 GCC, for example) compilers use 4B alignment, Watcom uses
>>> 8B in both 16 and 32-bit versions, and most *nix compilers on 64B use
>>> 16B alignment, as does ICC on Windows in both 32 and 64B modes).  
>>>
>>> *Not* intended to be an exhaustive list.
>>
>>The size of a type must be a whole multiple of its alignment; arrays
>>cannot have gaps between elements.  If a 10-byte floating-point type
>>requires 4-byte alignment, it must be padded to at least 12 bytes.
>
> That's true, but MS/Borland long doubles on their 16-bit compilers had
> a size of 10 bytes (and 2B alignment).

Which is consistent with what I said.  But you also said that
a 10-byte long double could have a 4, 8, or 16 byte alignment,
which is not possible.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#107706

On Sat, 01 Apr 2017 15:24:21 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>> On Sat, 01 Apr 2017 12:00:00 -0700, Keith Thompson <kst-u@mib.org>
>> wrote:
>>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>>[...]
>>>> There have been implementations of, 10-byte (80-bit), x86 long double
>>>> which have 2, 4, 8 and 16 byte alignment requirements.
>>>>
>>>> For example, amongst compilers actually supporting the 80-bit type, MS
>>>> and Borland's 16-bit compilers use 2-byte alignment, several 32-bit
>>>> (typical x86 GCC, for example) compilers use 4B alignment, Watcom uses
>>>> 8B in both 16 and 32-bit versions, and most *nix compilers on 64B use
>>>> 16B alignment, as does ICC on Windows in both 32 and 64B modes).  
>>>>
>>>> *Not* intended to be an exhaustive list.
>>>
>>>The size of a type must be a whole multiple of its alignment; arrays
>>>cannot have gaps between elements.  If a 10-byte floating-point type
>>>requires 4-byte alignment, it must be padded to at least 12 bytes.
>>
>> That's true, but MS/Borland long doubles on their 16-bit compilers had
>> a size of 10 bytes (and 2B alignment).
>
>Which is consistent with what I said.  But you also said that
>a 10-byte long double could have a 4, 8, or 16 byte alignment,
>which is not possible.


What I (unclearly) meant, was that the x86 80-bit temp-reals
implemented by various compilers as long doubles, had those alignment
requirements, but ignoring the pad bits.

[toc] | [prev] | [next] | [standalone]

#106791

On 23/03/2017 09:58, MehdiAmini wrote:

> static struct data
> {   uint64_t ctr[N];
>     long double mean;
>     long double variance;
>     long double * probability_ptr;
>
> } my_data;

> // Compiling the above code I get the warning, how to fix it?
>
> clang   -pedantic -Weverything -Wall -m64 -std=c11
>
> warning: padding size of 'struct data' with 8 bytes to alignment
> boundary [-Wpadded]
> static struct data

Well, you did ask for 'everything', and the compiler took you literally.

Here, the message shouldn't really be a warning, but a 'note', which is 
just advisory information. There's nothing actually wrong.

A warning would have been justified if the struct /wasn't/ padded, when 
it was necessary.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#106796

On 23/03/17 12:50, BartC wrote:
> On 23/03/2017 09:58, MehdiAmini wrote:
> 
>> static struct data
>> {   uint64_t ctr[N];
>>     long double mean;
>>     long double variance;
>>     long double * probability_ptr;
>>
>> } my_data;
> 
>> // Compiling the above code I get the warning, how to fix it?
>>
>> clang   -pedantic -Weverything -Wall -m64 -std=c11
>>
>> warning: padding size of 'struct data' with 8 bytes to alignment
>> boundary [-Wpadded]
>> static struct data
> 
> Well, you did ask for 'everything', and the compiler took you literally.
> 
> Here, the message shouldn't really be a warning, but a 'note', which is
> just advisory information. There's nothing actually wrong.

The warning exists because for some people, and some code, padding
structs means there /is/ something wrong.  That is why I use it in a lot
of my code.  But in this case, as for most "normal PC" software, it is
not a problem.

> 
> A warning would have been justified if the struct /wasn't/ padded, when
> it was necessary.
> 

That would be a warning along the lines of "internal compiler error -
something is broken in the compiler".  ICE's are generally fatal, not
warnings, and they are not optional.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web