[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #12 from davek at gcc dot gnu dot org  2009-09-15 16:16 -------
(In reply to comment #11)
> The bogus const info is added in at the end of this call chain, when generating
> the var die:
> 
> #0  0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270)
>     at /gnu/gcc/gcc/gcc/tree.h:182

> and indeed, it works by simply punting if the symbol ref in question points to
> a TLS item, but the flags are wrong in the rtx that is passed in:
> 
> (symbol_ref:SI ("gomp_tls_data") [flags 0x42] <var_decl 0x7fe190c0
> gomp_tls_data>)
> 
> This apparently has SYMBOL_REF_TLS_MODEL (rtl) == TLS_MODEL_NONE, so we never
> bail out the escape hatch and end up calling add_AT_addr() to create the
> DW_AT_const_value that needs relocating against the undefined symbol.

  It's this part of add_location_or_const_value_attribute() that is adding the
bad const value:

  /* If we have tried to generate the location otherwise, and it
     didn't work out (we wouldn't be here if we did), and we have a one entry
     location list, try generating a location from that.  */
  if (loc_list && loc_list->first)
    {
      enum var_init_status status;
      node = loc_list->first;
      status = NOTE_VAR_LOCATION_STATUS (node->var_loc_note);
      rtl = NOTE_VAR_LOCATION (node->var_loc_note);
      if (GET_CODE (rtl) == VAR_LOCATION
          && GET_CODE (XEXP (rtl, 1)) != PARALLEL)
        rtl = XEXP (XEXP (rtl, 1), 0);
      if (CONSTANT_P (rtl) || GET_CODE (rtl) == CONST_STRING)
        {
          add_const_value_attribute (die, rtl);
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          return;
        }


(gdb) print (var_loc_list *)0x7fd36d30
$1 = (struct var_loc_list_def *) 0x7fd36d30
(gdb) print $1[0]
$2 = {first = 0x7fd36d20, last = 0x7fd36d20, decl_id = 3277}
(gdb) print $1[0].first
$3 = (struct var_loc_node *) 0x7fd36d20
(gdb) print $1[0].first[0]
$4 = {var_loc_note = 0x7fcdd000, label = 0x7ff27298 "*LVL49",
  section_label = 0xd8e60a "*Ltext0", next = 0x0}
(gdb) print $1[0].first[0].var_loc_note
$5 = (rtx) 0x7fcdd000
(gdb) call debug_rtx($1[0].first[0].var_loc_note)
(note 85 4 66 (var_location thr (expr_list:REG_DEP_TRUE (symbol_ref:SI
("gomp_tl
s_data") [flags 0x42] <var_decl 0x7fe190c0 gomp_tls_data>)
    (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

  So, the NOTE_VAR_LOCATION stored in the location list's first entry's
var_loc_note field points to this definition that already has incorrect
(non-TLS) flags in the rtl.  If we look at the var_decl it's based on:


(gdb) call debug_tree(0x7fe190c0)
 <var_decl 0x7fe190c0 gomp_tls_data
    type <record_type 0x7fe7df90 gomp_thread asm_written type_0 BLK
        size <integer_cst 0x7fe2a8e0 constant 416>
        unit size <integer_cst 0x7fe87dc0 constant 52>
        align 32 symtab 2145789512 alias set 7 canonical type 0x7fe7df90
        fields <field_decl 0x7fe18ca0 fn type <pointer_type 0x7fda5e10>
            unsigned SI file /gnu/gcc/gcc/libgomp/libgomp.h line 327 col 10
            size <integer_cst 0x7fef0580 constant 32>
            unit size <integer_cst 0x7fef0320 constant 4>
            align 32 offset_align 128
            offset <integer_cst 0x7fef0340 constant 0>
            bit offset <integer_cst 0x7fef0b60 constant 0> context <record_type
0x7fe7df90 gomp_thread> chain <field_decl 0x7fe18d00 data>> context
<translation
_unit_decl 0x7fcac550 D.3329>
        pointer_to_this <pointer_type 0x7fe7e230> chain <type_decl 0x7fe7e000
D.
2396>>
    addressable used public external tls-local-exec BLK file
/gnu/gcc/gcc/libgom
p/libgomp.h line 361 col 36 size <integer_cst 0x7fe2a8e0 416> unit size
<integer
_cst 0x7fe87dc0 52>
    align 32
    (mem/s/c:BLK (symbol_ref:SI ("gomp_tls_data") [flags 0x42] <var_decl
0x7fe19
0c0 gomp_tls_data>) [7 gomp_tls_data+0 S52 A32]) chain <function_decl
0x7fdfb000
 gomp_new_icv>>
(gdb)

I notice that the tls-local-exec flag is set but there's no TLS mode in the
RTL, again.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357