[Bug c++/57271] New: ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271
Bug ID: 57271
Summary: ARM: gcc generates insufficient alignment for memory
passed as extra argument for function return large
composite type
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: java4ada at yahoo dot com
Created attachment 30109
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30109&action=edit
Testcase and output
Please find enclosed input Vector4.ii and Vector4.s compiled with "./xgcc -fpic
-mfloat-abi=softfp -mthumb -Os -march=armv7-a -mfpu=neon -S Vector4.ii".
Because function initVector4() returns instance of Vector4 16-byte in size, GCC
passes internal memory buffer as the first argument to hold the return value.
This is shown in Vector4.s line#54 "add r0,sp,#8", and the buffer is filled at
line#33 "vst1.64 {d16-d17}, [r0:128]". The 128-bit alignment hint is due to
the fact that class Vector4 is declared to be 16-byte aligned. Problem is, r0
may not be aligned to 16-byte if sp is 16-byte aligned, which results in crash
at vst1.64 [:128]. It seems that GCC doesn't honor the alignment of internal
memory buffer.
If Vector4 is declared to be 32-byte align, GCC generates extra code to ensure
r0 is properly aligned. I assume GCC should do it as low as 16-byte too.
[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271 --- Comment #2 from java4ada at yahoo dot com --- I don't know if ABI dictates it but from observation the stack is aligned to 8-byte for the largest primitive type "double" (or long long). I configure it on Ubuntu 12.04 64-bit with the following: ~/m/gcc/gcc-4.8/configure \ --prefix=/tmp/gcc/prefix --target=arm-linux-androideabi --host=x86_64-linux-gnu --build=x86_64-linux-gnu \ --with-gnu-as --with-gnu-ld --enable-languages=c,c++ \ --with-gmp=/tmp/gcc/temp-install \ --with-mpfr=/tmp/gcc/temp-install \ --with-mpc=/tmp/gcc/temp-install \ --with-cloog=/tmp/gcc/temp-install \ --with-isl=/tmp/gcc/temp-install \ --with-ppl=/tmp/gcc/temp-install \ --disable-ppl-version-check --disable-cloog-version-check --disable-isl-version-check \ --enable-cloog-backend=isl \ --with-host-libstdcxx="-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm" \ --disable-libssp \ --enable-threads \ --disable-libmudflap --disable-libstdc__-v3 --disable-sjlj-exceptions --disable-shared \ --disable-tls --disable-libitm --disable-nls --disable-bootstrap --disable-libquadmath --disable-libsanitizer \ --with-float=soft --with-fpu=vfp --with-arch=armv5te \ --enable-target-optspace --enable-initfini-array \ --with-sysroot=/tmp/gcc/prefix/sysroot \ --enable-plugins --enable-libgomp \ --enable-gold=default
[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271 --- Comment #5 from java4ada at yahoo dot com --- NEON instructions like vst/vld [:128] and [:256] need 16-byte and 32-byte alignment, respectively. Does it mean under ARM EABI both should be replaced with [:64] ? (Probably only at the cost of 1-2 cycle anyway) What other ARM ABI we can configure to get higher alignment than 8-byte?
[Bug c/61280] New: GCC 4.8.2 suppresses -Wsign-compare caused by macro defined in system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61280 Bug ID: 61280 Summary: GCC 4.8.2 suppresses -Wsign-compare caused by macro defined in system header Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: java4ada at yahoo dot com It seems that since 4.8 GCC grants -Wsign-compare immunity to macro defined in system header. To reproduce it: $ cat > test.h < test.c <
[Bug target/61202] gcc generates invalid sqdmulh instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202 java4ada at yahoo dot com changed: What|Removed |Added CC||java4ada at yahoo dot com --- Comment #5 from java4ada at yahoo dot com --- Will this bug cover 4.8.x as well? (or file separate bug for 4.8.x)
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 java4ada at yahoo dot com changed: What|Removed |Added CC||java4ada at yahoo dot com --- Comment #16 from java4ada at yahoo dot com --- Question: There are ~98 calls to gomp_thread() which allocates struct gomp_thread when HAVE_TLS isn't defined, but only gomp_free_thread() frees this instance. Possible memory leak?
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 --- Comment #17 from java4ada at yahoo dot com --- Is this fixed by https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218576 ?
