On 12/18/05, Dorit Naishlos <[EMAIL PROTECTED]> wrote:
> Richard Guenther <[EMAIL PROTECTED]> wrote on 15/12/2005 14:52:27:
>
> > On 12/15/05, Dorit Naishlos <[EMAIL PROTECTED]> wrote:
> >
> > > So, in short - when can we assume that pointer types have the minimum
> > > alignment required by their underlying type?
> >
> > I think the C standard always guarantees this.
>
> As far as I saw in the C standard, if you convert a pointer to a type to a
> pointer to a different type and the resulting pointer is not correctly
> aligned for the pointed-to type, then the behavior is undefined. Can we
> conclude from that the behavior of un-naturally-aligned pointers in general
> is undefined (even when it's not a result of unsafe casts)?
>
> > Of course with packed
> > structs or malicious users this is not always true but may (at least in
> > the case of malicious users) be invoking unspecified behavior.
> >
>
> Does the testcase in PR25413 fall into the category of "malicious users"?
> This is the relevant code snippet from the testcase:
>
> ===========================================
> struct oct_tt;
> typedef struct oct_tt oct_t;
> typedef unsigned int var_t;
> typedef enum {
> OCT_EMPTY = 0,
> OCT_NORMAL = 1,
> OCT_CLOSED = 2
> } oct_state;
> struct oct_tt {
> var_t n;
> int ref;
> oct_state state;
> struct oct_tt* closed;
> num_t* c;
> };
>
> oct_t*
> octfapg_universe (const var_t n)
> {
> oct_t* m;
> size_t i, nn = (2*(size_t)(n)*((size_t)(n)+1));
> m = octfapg_alloc(n);
> for (i=0;i<nn;i++) *(m->c+i) = num__infty; ## <-- the loop
> .....
> return m;
> }
> ============================
>
> When we vectorize the loop above, we assume that the dataref *(m->c+i),
> which is of type double, is aligned on size of double, whereas it turns out
> that on some targets it isn't. What did the user do wrong here? (there are
> no bad type casts, or even usage of attribute "packed").
The ABI may specify that the required alignment for a type is less than
its size. In fact, for things like 8 byte double it's quite common to do this
on a 32bit target. We must have this information accessible somewhere
from the backends, but I can't find a target hook or def for it at the
moment. The C standard does not guarantee alingment >= type size,
but you can usually count on it for all types <= pointer size.
Richard.
> And what is GCC's policy w.r.t packed-structs? are we not guaranteeing to
> compile references to fields of packed-structs correctly when they violate
> natural-alignment? (as in this testcase:
> http://gcc.gnu.org/viewcvs/branches/apple-local-200502-branch/gcc/testsuite/gcc.dg/vect/vect-align-1.c?rev=108214&view=markup)
>
>
> My concern is that these testcases are handled correctly by GCC if
> vectorization is not enabled. Is it just "accidental" that the unvectorized
> code provides the expected behavior, or is the vectorizer making an
> assumption it shouldn't be making?
It's a difficult question, but the middle-end should either present
a reference through the struct that is packed (so you can check this
attribute), or marking a pointer indirection with UNALIGNED_INDIRECT_REF
(or whatever it is called). The problem is again that we don't track
proper alignment information in our types.
Richard.
> thanks,
> dorit
>
>
> > Richard.
>
>
