[LLVMbugs] [Bug 18132] New: -Wpacked warns even though packed structure has different size/memory layout

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Dec 4 05:23:21 PST 2013


http://llvm.org/bugs/show_bug.cgi?id=18132

            Bug ID: 18132
           Summary: -Wpacked warns even though packed structure has
                    different size/memory layout
           Product: clang
           Version: 3.3
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hanauska at equinux.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider the following rather simple code snippet:

----- packed.c ----

#include <stdint.h>
#include <stdio.h>

struct S1 {
    uint16_t addr;
    uint32_t value;
};

struct S2 {
    uint16_t addr;
    uint32_t value;
} __attribute__((packed));


int main (int argc, char ** argv) {
    struct S1 s1;
    struct S2 s2;

    printf("%zu - %zu\n", sizeof(s1), sizeof(s2));
    return 0;
};

-------------------

Compiling and running this code should produce the following output on a 32/64
bit system:

8 - 6

(I think it may be 6 - 6 on a 16 bit system)

So whether the struct is packed or not *DOES* make a difference here. Yet,
compiling the code above using "-Wpacked", I get the following:

packed.c:10:11: warning: packed attribute is unnecessary for 'addr' [-Wpacked]
        uint16_t addr;
                 ^

This doesn't seem correct to me. As I understand "-Wpacked", it should only
produce a warning if the presence of the packed attribute has no influence on
the structure size and thus also no influence on the relative memory layout of
the fields within the structure.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131204/e887d682/attachment.html>


More information about the llvm-bugs mailing list