[Bug c/70407] New: alignment of array elements is greater than element size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70407
Bug ID: 70407
Summary: alignment of array elements is greater than element
size
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dxin at usc dot edu
Target Milestone: ---
To verify, declare a POD type plus aligned attribute as a custom type.
typedef struct S_ { short f[3]; } S __attribute__ ((aligned (8)));
Then make an array of such type.
S test[16]={};
Then the code won't compile, with "error: alignment of array elements is
greater than element size".
Basically the `__attribute__ ((aligned (8)));` left the size of such type
unchanged, as opposed to including the alignment/padding in the size and
violates the C standard that `sizeof` operator returns the storage size plus
all necessary padding and maintain `sizeof(Type[N])==N*sizeof(Type)`.
This error is added in 2005 (
https://gcc.gnu.org/ml/gcc-patches/2005-09/msg01853.html ) to prevent GCC from
generating broken code, and is brought up again in a stackoverflow.com question
(http://stackoverflow.com/questions/36211864/how-can-i-apply-attribute-aligned32-to-an-int)
.
Note that clang-3.8 does include the extra padding as the size and allow
declaring arrays of extra-aligned types.
This problem is verified on GCC 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1) and also
here https://ideone.com/oxGyiN .
If this bug is not to be fixed, please update the documentation
(https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes)
and mark it as a feature.
[Bug c/70407] alignment of array elements is greater than element size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70407 Dehuan Xin changed: What|Removed |Added Severity|normal |minor
[Bug c/70407] alignment of array elements is greater than element size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70407
--- Comment #2 from Dehuan Xin ---
(In reply to Richard Biener from comment #1)
> Confirmed as a documentation issue. Note that
>
> typedef struct S_ { short f[3] __attribute((aligned(8))); } S;
>
> works (and increases sizeof (S_)).
So for a struct, aligning the first field of it is effectively aligning the
struct.
But that seems a variable attribute rather than type attribute, a very
different usage. (as is documented here
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes).
And for
typedef int more_aligned_int __attribute__ ((aligned (8)));
it's still an issue.
[Bug c/68123] New: GCC vector extension behaves funny with large vector size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68123 Bug ID: 68123 Summary: GCC vector extension behaves funny with large vector size Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dxin at usc dot edu Target Milestone: --- Created attachment 36599 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36599&action=edit test source file It would complete unroll the loop and produces a huge assembly. With -O3 the produced assembly is smaller, but compilation takes a lot longer than no -O3. I attached test source file. With CFLAGS=-std=gnu11 -O3 -mcpu=cortex-a9 -mfloat-abi=hard -mfpu=neon -fPIE -Wall -S -fverbose-asm it compiles to a 57K line assembly and takes about 2min to compile, on a XEON 1245v3 machine. Tested on "GCC: (crosstool-NG linaro-1.13.1-4.8-2013.11 - Linaro GCC 2013.10) 4.8.3 2013 (prerelease)"
[Bug c/68123] GCC vector extension behaves funny with large vector size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68123 --- Comment #1 from Dehuan Xin --- compiler info: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.11 - Linaro GCC 2013.10) 4.8.3 2013 (prerelease)
[Bug c/68960] New: __attribute__ ((aligned ())) is ignored for OpenMP private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68960
Bug ID: 68960
Summary: __attribute__ ((aligned ())) is ignored for OpenMP
private variables
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dxin at usc dot edu
Target Milestone: ---
Test code:
#include
int main(void)
{
int temp[4][4] __attribute__ ((aligned (256)))={{0}};
//#pragma omp for private(temp)
for(size_t i=0; i<4;i++){
printf("chunk %zu: &temp[0][0]=%p\n", i, &temp[0][0]);
}
return 0;
}
Without OpenMP, alignment is correctly set to 256 bytes:
gcc main.c -fopenmp -std=gnu11
./a.out
chunk 0: &temp[0][0]=0x7be0ef00
chunk 1: &temp[0][0]=0x7be0ef00
chunk 2: &temp[0][0]=0x7be0ef00
chunk 3: &temp[0][0]=0x7be0ef00
With OpenMP, alignment is default 16 bytes:
gcc main.c -fopenmp -std=gnu11
./a.out
chunk 0: &temp[0][0]=0x7fff16c56ac0
chunk 1: &temp[0][0]=0x7fff16c56ac0
chunk 2: &temp[0][0]=0x7fff16c56ac0
chunk 3: &temp[0][0]=0x7fff16c56ac0
Tested with:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4, on x86-64
gcc (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04) 4.8.4, on arm v7
[Bug libgomp/106490] New: loop counter overflow within omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106490
Bug ID: 106490
Summary: loop counter overflow within omp
Product: gcc
Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: dxin at usc dot edu
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 53390
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53390&action=edit
minimum test case
gcc's omp implementation seems to use a signed integer type for the loop
counter. As a result, if the user's code use an unsigned loop variable with a
large loop count, the internal loop counter overflows and the loop body never
run.
This is bug only happens when omp is used, i.e. the test case runs as expected
if the omp pragma is removed.
gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
-test case begin
#include
#include
#include"omp.h"
//const unsigned int I_LIMIT=(UINT_MAX)>>1;// good, printf runs for a while
const unsigned int I_LIMIT=UINT_MAX;// bad case, crash before any printf
int main()
{
#pragma omp parallel for
for(unsigned int i=0;i<=I_LIMIT;i++){
printf("i=%u,i=%f\n",i,(float)(i));
}
return 0;
}
-test case end
gcc test_omp_overflow.c -fopenmp
./a.out
