[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables

[thomas at reactsoft dot com]

------- Comment #2 from thomas at reactsoft dot com  2006-09-01 07:10 -------
We also have severe problems with GCC4.1.1 which generates wrong machine code
on i386 when there's a (volatile) structure with __attribute__((aligned (16)))
on the stack. If the code is not very complex, the alignment works flawlessly.
But as soon as the code becomes complex, GCC screwes the alignment (and even
accesses variables that don't exist (I'll go into detail later).

Basically code like this is affected (this is *NOT* a test case, I'm going to
post a test case as soon as I get it to work):

typedef struct _somestruct {
    int a;
};

static void checkstruct (volatile struct _somestruct *palignedvar)
{
    if ((size_t)palignedvar & 0xF)
        printf("structure misaligned!\n");
}

void somefunc(int a, int b, int c) {
    __attribute__((aligned (16))) volatile struct _somestruct alignedvar;

    while (1)
    /* [other code] */
    if (a) {
        if (c) {
            /* [other code] */
            alignedvar.a = c;
            checkstruct(&alignedvar);
        } else {
            /* [other code] */
            break;
        }
    } else {
        if (b) {
            /* [other code] */
            alignedvar.a = a;
            checkstruct(&alignedvar);
        } else {
            if (c) {
                break;
            } else {
                /* [other code] */
                alignedvar.a = a;
                checkstruct(&alignedvar);
            }
        }
        /* [other code] */
    }
}

I analyzed the generated assembly code. GCC reserves an area big enough to hold
the structure plus padding, so it can align the structure dynamically at
runtime. It stores a pointer to the reserved area and a pointer to the
structure within the area. As long as the code is simple, GCC uses the pointer
to the structure to access the data. However, if the code is complex enough,
GCC mistakenly uses the pointer to the reserved area - which of course is
sometimes not properly aligned. As a result, also the data of the structure
members are read/write incorrectly.

the stack is organized like this (the order may not match as showed in this
abstracted example):

struct {
    void *reserved_area;     /* this is the pointer GCC sometimes accidently
grabs */
    void *aligned_structure; /* this is the pointer GCC should always grab */

    char reserved[sizeof(structure) + sizeof(padding)];
};

I encountered this bug with -O3, I don't know if GCC also generates broken code
without optimizations. I tried to create a simple test case that triggers the
problem, but I failed last night. I'm going to do that this weekend. In the
meanwhile, you can find some real-world code that fails due to this bug:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/srw.c?revision=23806&view=markup
(see the ASSERT_SRW_WAITBLOCK macro).


-- 

thomas at reactsoft dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas at reactsoft dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862