Description of problem:
In some code sequences, gcc creates __thread variables with inadequate offset, 
causing applications to crash when accessing these variables.

Version-Release number of selected component (if applicable):
[/tmp/gcc-bug-2]gcc -v
Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --host=ia64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)


How reproducible:
consistent

Steps to Reproduce:
[/tmp/gcc-bug-2]cat main.c
struct foo_t {
        unsigned long ll[2] __attribute__ ((aligned (16)));
};
typedef struct foo_t foo_t;

__thread long t1  = 0l, t2 = 0l;
__thread foo_t fooo;

int g_dont_core = 0;
char * search_path[] = { "/usr/local/bin", "/usr/bin",
        "/bin", "/usr/lib/foo", ""
};
long bar (void *addr)
{
        return bar2 (addr);
}
[/tmp/gcc-bug-2]make
cc -fpic -ffixed-r13 -nostdinc   -c -o main.o main.c
gcc -shared -o libfoo.so main.o

  
Actual results:

The alignment of the thread variable 'fooo' has to be 16. Nevertheless, the 
value gcc assigns to it is 0x18, causing it to be non-aligned :

reading the output of readelf on the resulted shared object, one can see the 
alignment of TLS segment is 0x10:

  TLS            0x0000000000000ee8 0x0000000000010ee8 0x0000000000010ee8
                 0x0000000000000018 0x0000000000000028  R      10

but the value assigned to 'fooo' is 0x18:

   55: 0000000000000018    16 TLS     GLOBAL DEFAULT   18 fooo

which together sums up to 0x8 alignment, instead of 0x10.

ofcourse - this is a very simplified test case, the real case has a jmp_buf 
aligned incorrectly on 8 bytes, resulting with SIGBUS as soon as it is accessed.

Additional info:
I found the problem on RHEL3 U5 beta ( which is the latest one I have ), and 
checking with previous EL3 versions, i see the same behavior on EL3U3.