[llvm-bugs] [Bug 38408] New: nested opaque types confuse the linker
    via llvm-bugs 
    llvm-bugs at lists.llvm.org
       
    Wed Aug  1 13:36:06 PDT 2018
    
    
  
https://bugs.llvm.org/show_bug.cgi?id=38408
            Bug ID: 38408
           Summary: nested opaque types confuse the linker
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Linker
          Assignee: unassignedbugs at nondot.org
          Reporter: andrew.kaylor at intel.com
                CC: llvm-bugs at lists.llvm.org
Given the four input IR files below, the llvm-link should generate a single
defintion of %struct.outer which contains a 
pointer to a version of %struct.middle that in turn contains "%struct.inner =
type { i32, i32, %struct.foo* }.
Instead, the linker mistakenly maps %struct.middle to %struct.middle.1 and
produces a second version of %struct.outer 
which must be bitcast back to the correct definition in the calls to
use_outer() in the body of f1() and f3().
-=-=-=-=-=-=-=-
File1.ll
-=-=-=-=-=-=-=-
%struct.outer = type { i32, i32, %struct.middle* }
%struct.middle = type opaque
declare void @use_outer(%struct.outer* %o)
define void @f1(%struct.outer* %o) {
  call void @use_outer(%struct.outer* %o)
  ret void
}
-=-=-=-=-=-=-=-
File2.ll
-=-=-=-=-=-=-=-
%struct.middle.1 = type { %struct.inner.1 }
%struct.inner.1 = type { i32, i32, %struct.bar }
%struct.bar = type { i32, i32 }
define void @use_middle(%struct.middle.1* %m) {
  %pbar = getelementptr %struct.middle.1, %struct.middle.1* %m, i64 0, i32 0,
i32 2
  call void @use_bar(%struct.bar* %pbar)
  ret void
}
define void @use_bar(%struct.bar* %b) {
  ret void
}
-=-=-=-=-=-=-=-
File3.ll
-=-=-=-=-=-=-=-
%struct.outer = type { i32, i32, %struct.middle* }
%struct.middle = type { %struct.inner }
%struct.inner = type { i32, i32, %struct.foo* }
%struct.foo = type { i16, i16, i32 }
declare void @use_outer(%struct.outer* %o) {
  ret void
}
-=-=-=-=-=-=-=--=-=-=-=-=-=-=--=-=-=-=-=-
llvm-link -S File1.ll File2.ll File3.ll
-=-=-=-=-=-=-=--=-=-=-=-=-=-=--=-=-=-=-=-
%struct.outer = type { i32, i32, %struct.middle* }
%struct.middle = type { %struct.inner.1 }
%struct.inner.1 = type { i32, i32, %struct.bar }
%struct.bar = type { i32, i32 }
%struct.outer.0 = type { i32, i32, %struct.middle.1* }
%struct.middle.1 = type { %struct.inner }
%struct.inner = type { i32, i32, %struct.foo* }
%struct.foo = type { i16, i16, i32 }
define void @f1(%struct.outer* %o) {
  call void bitcast (void (%struct.outer.0*)* @use_outer to void
(%struct.outer*)*)(%struct.outer* %o)
  ret void
}
define void @use_middle(%struct.middle* %m) {
  %pbar = getelementptr %struct.middle, %struct.middle* %m, i64 0, i32 0, i32 2
  call void @use_bar(%struct.bar* %pbar)
  ret void
}
define void @use_bar(%struct.bar* %b) {
  ret void
}
define void @use_outer(%struct.outer.0* %o) {
  ret void
}
This also applies to LTO, of course.
-- 
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/20180801/f856ca5d/attachment.html>
    
    
More information about the llvm-bugs
mailing list