GCC note: non-delegitimized UNSPEC UNSPEC_PCALAU12I_GR (28) found in variable location

[xen0n]

Just encountered this while compiling binutils trunk on loongarch64:

../../gdb/solib-svr4.c: In function ‘svr4_info* _ZL13get_svr4_infoP13program_space.part.0(program_space*)’:
../../gdb/solib-svr4.c:489:1: note: non-delegitimized UNSPEC UNSPEC_PCALAU12I_GR (28) found in variable location
  489 | get_svr4_info (program_space *pspace)
      | ^~~~~~~~~~~~~

gcc --version:

gcc (Gentoo 15.1.0 p1) 15.1.0
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This may or may not be a problem but it's probably worth looking into.

[xry111]

It'd be better to have a reduced test case to diagnose further.

I vaguely remember I saw something similar when I worked on the extreme code model, and the underlying issue was an incorrect CSE of addi.d/lu32i.d/lu52i.d sequences when addressing the same symbol twice. The issue was fixed before the work got committed. But here I think it's perfectly valid to CSE two pcalau12i against the same symbol...

[xen0n]

cvise-minimized reproducer:

// g++ -S -o /dev/null -g -O2 ./solib-svr4.ii 2>&1 | grep -q UNSPEC_PCALAU12I_GR

struct _Rb_tree_node_base {
  typedef _Rb_tree_node_base *_Base_ptr;
  int _M_color;
  _Base_ptr _M_parent;
  _Base_ptr _M_left;
  _Base_ptr _M_right;
};
struct _Rb_tree_key_compare {
  int _M_key_compare;
};
struct _Rb_tree_header {
  _Rb_tree_node_base _M_header;
  long _M_node_count;
  _Rb_tree_header() { _M_header._M_parent = 0; }
};
struct _Rb_tree {
  struct : _Rb_tree_key_compare, _Rb_tree_header {
  } _M_impl;
};
struct set {
  _Rb_tree _M_t;
};
struct registry {
  template <typename DATA> struct key {
    key();
    key(key &);
    void emplace() {
      DATA *result = new DATA();
      registry reg_obj;
      reg_obj.set(m_key, result);
    }
    unsigned m_key;
  };
  void set(unsigned, void *);
};
struct map {
  _Rb_tree _M_t;
};
struct svr4_info {
  long interp_text_sect_high;
  long interp_plt_sect_low;
  long interp_plt_sect_high;
  map solib_lists;
  set active_namespaces;
};
registry::key<svr4_info> solib_svr4_pspace_data;
void svr4_in_dynsym_resolve_code() { solib_svr4_pspace_data.emplace(); }

It would be better to minimize this further but for now I'd need some rest. ;-)

[xry111]

I vaguely remember I reproduced it on nanmen2, but now it seems offline and I cannot reproduce it locally.

[xry111]

If GCC is built with --enable-checking=release, the issue will be hidden.

[xry111]

We have something really weird in dfinish:

(note 133 16 176 (var_location this (unspec:DI [
        (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
    ] UNSPEC_PCALAU12I_GR)) NOTE_INSN_VAR_LOCATION)
(note 176 133 121 0x7ffff14adee0 NOTE_INSN_BLOCK_BEG)
(note 121 176 134 bad.i:39 NOTE_INSN_INLINE_ENTRY)
(note 134 121 177 (var_location this (plus:DI (unspec:DI [
            (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
        ] UNSPEC_PCALAU12I_GR)

What the f**k is (note 133) doing? It cannot be correct as we cannot guarantee this points to something page-aligned.