[LLVMbugs] [Bug 17246] New: section attribute extension causes miscompile

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sun Sep 15 03:34:25 PDT 2013


            Bug ID: 17246
           Summary: section attribute extension causes miscompile
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

const int i2 __attribute__((section("INITDATA"))) = 30;
int i1 __attribute__((section("INITDATA"))) = 0;

clang using C language semantics will IR-gen:
@i2 = constant i32 30, section "INITDATA", align 4
@i1 = global i32 0, section "INITDATA", align 4

LLVM CodeGen gives us:
        .type   i2, at object              # @i2
        .section        INITDATA,"a", at progbits
        .globl  i2
        .align  4
        .long   30                      # 0x1e
        .size   i2, 4

        .type   i1, at object              # @i1
        .globl  i1
        .align  4
        .long   0                       # 0x0
        .size   i1, 4

notice the flags in the section directive, we only state that it is allocatable
but do not mention that it is writable.

Where do we fix this? Is this valid IR? The IR verifier has no issue with it.

note that flipping the order of i1 and i2 yields "aw" for the section
directive's flags, making everything A-OK.

1. icc gets it wrong in the exact same way
2. gcc fails at understanding this semantically but it's assembler catches it
in the end.

My opinion:
We shouldn't tie down our IR to whatever whacky thing happens in GCC.  Instead,
we should widen the flags of the section as much as possible to capture
everything specified with the attribute.  Then it will Just Work (TM) without
having to teach clang when it's ok for two global variables to be in the same

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/20130915/c80b3116/attachment.html>

More information about the llvm-bugs mailing list