[lkml]   [2009]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
    Geert Uytterhoeven wrote:
    > On Mon, 2 Feb 2009, Boaz Harrosh wrote:
    >> Arnd Bergmann wrote:
    >>> No, the compiler is correct, it has to generate more complex code
    >>> if it cannot assume that data is naturally aligned and the architecture
    >>> does not support unaligned loads. If you don't understand this, please
    >>> at least read the list archives about the last five times this came up
    >>> before claiming that the compiler is broken.
    >> Wrong!! Sorry, you guys don't listen.
    >> I'm talking of the case where the structures are EXACTLY the same anyway
    >> you look at them. sizeof(foo) == sizeof(foo_packed) and
    >> offsetof(foo_memmber) == offsetof(foo_packed_member) for every member of
    >> the structure. foo && foo_packed are declared exactly the same but with
    >> __attribute__((packed(1))) applied to the later.
    >> THEN in ia64 case the compiler is brain dead, because it relates
    >> "unalignment" to packed(1) which are two different things.
    > The natural alignment of a structure is max(alignment(member)), for all
    > members. With __attribute__((packed)), the natural alignment of the structure
    > is 1, so the compiler cannot assume anything.

    No the natural alignment is what it is, after the application of
    __attribute__((packed(1))). In a well defined structure that is a no-opt.
    But yes in ai64 the gcc programmers got lazy and did not make that analysis
    after laying out the structure.

    > While the ints in the structure may still be at offsets 0, 4, 8, and so on,
    > this doesn't say anything about their actual memory addresses, as the struct
    > base address itself may be unaligned.

    The base address can be unaligned even if the structure is aligned. In that
    case you need the __atrubute__((aligned)) thingy. It is true that if the sizeof(foo_packed)
    is though unaligned, the compiler will have to assume unalignment in array operations.
    but if the sizeof(foo_packed) is naturally aligned at the output then the compiler
    has all the needed information to know that even if I declared __packed, it calculated
    and knows that it is well aligned at the end.

    > Gr{oetje,eeting}s,
    > Geert

    Please note that I gave up on the compiler and understand that the use of __packed
    is dangerous in some cases, sigh. My standing point is to make sure there are no guesses
    left, and a BUILD_BUG_ON to make sure of that.


     \ /
      Last update: 2009-02-02 10:37    [W:0.025 / U:0.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site