bug in gcc 4.0.1/5250/i386
bug in gcc 4.0.1/5250/i386
- Subject: bug in gcc 4.0.1/5250/i386
- From: "Scott Smith" <email@hidden>
- Date: Fri, 24 Feb 2006 12:40:39 -0800
There is a bug in the gcc optimizer that only shows up with the darwin
build, not on the 4.0.1 I download from gnu and use on a non-mac.
The following C code snippet:
#include <inttypes.h>
#include <stdlib.h>
#define ALIGN_PTR(p,a) ((void *)( (((size_t)(p))+(a)-1)&~((size_t)(a)-1)))
void *foo(void)
{
float x[13];
return ALIGN_PTR(x,16);
}
is designed to align 'x' on a 16-byte boundary. This code is for
illustrative purposes only (I know you can't return local variables
from a function, and if you align a array of 13 4-byte elements, the
most you can use is 10 elements)... etc.
The problem is that with '-O1', gcc will discard the alignment
instructions. I figured out that gcc is using
'-mpreferred-stack-boundary=4' to assume the stack frame is
automatically aligned on a 16-byte boundary. That's great, however
that says nothing about the variables declared inside the stack frame.
In this case, 'x' is only aligned on a 4-byte boundary, not 16-byte.
I can fix this one of two ways: using '-mpreferred-stack-boundary=2'
will cause gcc to emit the correct code, however that causes other
problems (called functions will no longer able to assume a nice stack
alignment).
The other way is to add '__attribute__((aligned(16)))'. Since the
stack frame is already aligned, gcc can force the alignment of the
variable for me.
The real problem is that gcc should not assume that the variable is
aligned in the first place!
Is this the right place for the bug report, or should I forward it
somewhere else?
--
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden