[llvm-bugs] [Bug 39899] New: Clang/LLVM Produces a constant description of a global constant, even when that constant has storage

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Dec 5 15:10:00 PST 2018


https://bugs.llvm.org/show_bug.cgi?id=39899

            Bug ID: 39899
           Summary: Clang/LLVM Produces a constant description of a global
                    constant, even when that constant has storage
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dblaikie at gmail.com
                CC: aprantl at apple.com, echristo at gmail.com,
                    jdevlieghere at apple.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, paul.robinson at am.sony.com,
                    richard-llvm at metafoo.co.uk

Given this:

  static const int x = 3;
  const int *y() {
      return &x;
  }
  int z() {
      return 1;
  }

Clang produces IR with a variable description like this:

  @_ZL1x = internal constant i32 3, align 4, !dbg !0
  !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())

Which seems all right and good.

but if you change the "return 1" to "return x", you get IR like this:

  @_ZL1x = internal constant i32 3, align 4, !dbg !0
  !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression(DW_OP_constu,
3, DW_OP_stack_value))


It's weird that the !dbg is even attached to the global anymore, since it
doesn't use its address in the location expression at all.

But also, it's a regression to describe something with a constant when it does
have storage - it means you can't, say evaluate "&i" in a debugger, or pass the
address of the global to a function that wants an address, etc.

According to some rough debugging with godbolt, this regression first appeared
in the 4.0 release.

-- 
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/20181205/2284acd2/attachment.html>


More information about the llvm-bugs mailing list