--- Comment #7 from stevenj at alum dot mit dot edu 2007-02-02 02:06
---
> Well the C standard mentions there can be non standard integer types so that
> exists for x86_64, __int128_t which has normally aligned 16bytes so again this
> is a bug in glibc.
First, 16-byte alignment for SIM
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-01 23:04 ---
(In reply to comment #5)
> (In reply to comment #4)
> > This is really a glibc bug and needs to be fixed. The C standard says that
> > malloc allocates that the right alignment so this is a glibc bug.
>
> The C sta
--- Comment #5 from stevenj at alum dot mit dot edu 2007-02-01 23:00
---
(In reply to comment #4)
> This is really a glibc bug and needs to be fixed. The C standard says that
> malloc allocates that the right alignment so this is a glibc bug.
The C standard does not cover SIMD instruc
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 11:19 ---
This is really a glibc bug and needs to be fixed. The C standard says that
malloc allocates that the right alignment so this is a glibc bug.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
--- Comment #3 from mick at nag dot co dot uk 2005-10-11 09:26 ---
Thanks - the problem is now fixed in 64-bit compilations. However, if I compile
try.f and sub.c with the -m32 flag, I still get memory allocated on 8-byte
boundaries rather than 16-byte. As Andrew said, this is down to th
--- Comment #2 from kargl at gcc dot gnu dot org 2005-10-07 17:25 ---
On amd64-*-freebsd with Jakub's patch, I get
troutmask:sgk[206] gfc41 -static -o z try.f sub.c
troutmask:sgk[207] ./z
Address of x = 0x00554000
x is aligned on a 16-byte boundary
--
http://gcc.gnu.org/b
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 17:05 ---
Fixed by:
2005-10-01 Jakub Jelinek <[EMAIL PROTECTED]>
* runtime/memory.c (malloc_t): Remove.
(GFC_MALLOC_MAGIC, HEADER_SIZE, DATA_POINTER, DATA_HEADER): Remove.
(mem_root, runtime_cleanup,
