Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8307147

[x86] Dangling pointer warning for Assembler::_attributes

    XMLWordPrintable

Details

    • b22
    • x86

    Backports

      Description

        When compiling with gcc13.1 for release we get some -Wdangling-pointer warnings like this (earlier versions of gcc don't warn):

        In member function 'void Assembler::set_attributes(InstructionAttr*)',
            inlined from 'int Assembler::vex_prefix_and_encode(int, int, int, VexSimdPrefix, VexOpcode, InstructionAttr*)' at ../../src/hotspot/cpu/x86/assembler_x86.cpp:11491:17,
            inlined from 'void Assembler::vpclmulqdq(XMMRegister, XMMRegister, XMMRegister, int)' at ../../src/hotspot/cpu/x86/assembler_x86.cpp:10823:37:
        ../../src/hotspot/cpu/x86/assembler_x86.hpp:921:66: warning: storing the address of local variable 'attributes' in '*this.Assembler::_attributes' [-Wdangling-pointer=]
          921 | void set_attributes(InstructionAttr *attributes) { _attributes = attributes; }
              | ~~~~~~~~~~~~^~~~~~~~~~~~
        ../../src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::vpclmulqdq(XMMRegister, XMMRegister, XMMRegister, int)':
        ../../src/hotspot/cpu/x86/assembler_x86.cpp:10822:19: note: 'attributes' declared here
        10822 | InstructionAttr attributes(AVX_128bit, /* vex_w */ false, /* legacy_mode */ true, /* no_mask_reg */ true, /* uses_vl */ true);
              | ^~~~~~~~~~
        ../../src/hotspot/cpu/x86/assembler_x86.cpp:10820:87: note: 'this' declared here
        10820 | void Assembler::vpclmulqdq(XMMRegister dst, XMMRegister nds, XMMRegister src, int mask) {
              | ^

        Some places set the _attributes member of the assembler. The attributes object's destructor checks for that situation and clears the assembler's _attributes. So we aren't leaving a dead object in the assembler to be accidentally used later, making this warning "harmless". Since the lifetime of the attributes object doesn't end until it's storage has been released, e.g. after it's destructor is invoked, the warning is a false positive. However, the structure isn't helping by somewhat obfuscating what's being done.

        Attachments

          Issue Links

            Activity

              People

                kbarrett Kim Barrett
                kbarrett Kim Barrett
                Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: