[Bug target/41357] New: libgomp build fail

[Bug target/41357] New: libgomp build fail

[jzhang918 at gmail dot com]

libtool: link: /home/jie/blackfin-sources/build45220-5/gcc_build-4.5/./gcc/xgcc
-B/home/jie/blackfin-sources/build45220-5/gcc_build-4.5/./gcc/
-B/home/jie/installs/bfin-45-220-5/bfin-linux-uclibc/bin/
-B/home/jie/installs/bfin-45-220-5/bfin-linux-uclibc/lib/ -isystem
/home/jie/installs/bfin-45-220-5/bfin-linux-uclibc/include -isystem
/home/jie/installs/bfin-45-220-5/bfin-linux-uclibc/sys-include    -shared 
.libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o
.libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o
.libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o
.libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o
.libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o    -pthread
-Wl,-O1   -Wl,-soname -Wl,libgomp.so.1 -o .libs/libgomp.so.1.0.0
/home/jie/installs/bfin-45-220-5/bfin-linux-uclibc/bin/ld: fde encoding in
/home/jie/blackfin-sources/build45220-5/gcc_build-4.5/./gcc/libgcc.a(_udivdi3.o)(.eh_frame)
prevents .eh_frame_hdr table being created.
.libs/iter.o:(.debug_info+0x8fb): undefined reference to `_gomp_tls_data'
.libs/iter.o:(.debug_info+0x98e): undefined reference to `_gomp_tls_data'
.libs/iter.o:(.debug_info+0xa73): undefined reference to `_gomp_tls_data'
.libs/iter.o:(.debug_info+0xb2d): undefined reference to `_gomp_tls_data'
.libs/iter_ull.o:(.debug_info+0x90e): undefined reference to `_gomp_tls_data'
.libs/iter_ull.o:(.debug_info+0x9a5): more undefined references to
`_gomp_tls_data' follow
/home/jie/installs/bfin-45-220-5/bfin-linux-uclibc/bin/ld:
.libs/libgomp.so.1.0.0: hidden symbol `_gomp_tls_data' isn't defined
/home/jie/installs/bfin-45-220-5/bfin-linux-uclibc/bin/ld: final link failed:
Nonrepresentable section on output
collect2: ld returned 1 exit status
make[4]: *** [libgomp.la] Error 1
make[4]: Leaving directory
`/home/jie/blackfin-sources/build45220-5/gcc_build-4.5/bfin-linux-uclibc/libgomp'


-- 
           Summary: libgomp build fail
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jzhang918 at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: bfin-linux-uclibc


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

[Bug target/41357] libgomp build fail

[jzhang918 at gmail dot com]

------- Comment #1 from jzhang918 at gmail dot com  2009-09-15 05:57 -------
The cause is that DW_TAG_variable references gomp_tls_data instead of
___emutls_v.gomp_tls_data.


-- 


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

[Bug target/41357] libgomp build fail

[rainer at emrich-ebersheim dot de]

------- Comment #2 from rainer at emrich-ebersheim dot de  2009-09-15 11:23 -------
I think it's the same issue for PR41357.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #3 from davek at gcc dot gnu dot org  2009-09-15 12:47 -------
This bug is also present on i686-pc-cygwin at r.151703, so given Jie's
diagnosis in comment 2, let's switch the component from 'target' to 'debug'.


libtool: link: /gnu/gcc/obj.libstdc.enabled/./gcc/xgcc
-B/gnu/gcc/obj.libstdc.enabled/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/
-B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem
/opt/gcc-tools/i686-pc-cygwin/include -isystem
/opt/gcc-tools/i686-pc-cygwin/sys-include    -shared  .libs/alloc.o
.libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o
.libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o
.libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o
.libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o
.libs/time.o .libs/fortran.o .libs/affinity.o    -pthread -Wl,-O1   -o
.libs/cyggomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/libgomp.dll.a
xgcc: unrecognized option '-pthread'
Creating library file:
.libs/libgomp.dll.a.libs/iter.o:iter.c:(.debug_info+0xc29): undefined reference
to `_gomp_tls_data'
.libs/iter.o:iter.c:(.debug_info+0xcd1): undefined reference to
`_gomp_tls_data'
.libs/iter.o:iter.c:(.debug_info+0xdc8): undefined reference to
`_gomp_tls_data'
.libs/iter.o:iter.c:(.debug_info+0xe92): undefined reference to
`_gomp_tls_data'
.libs/iter_ull.o:iter_ull.c:(.debug_info+0xc55): undefined reference to
`_gomp_tls_data'
.libs/iter_ull.o:iter_ull.c:(.debug_info+0xd12): more undefined references to
`_gomp_tls_data' follow
collect2: ld returned 1 exit status


One slight difference is that I don't get the complaint from ld about "fde
encoding ... prevents .eh_frame_hdr table being created" or the (presumably
consequent) "Nonrepresentable section on output" error.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
          Component|target                      |debug
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-09-15 12:47:47
               date|                            |


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #4 from davek at gcc dot gnu dot org  2009-09-15 12:52 -------
(In reply to comment #2)
> I think it's the same issue for PR41357.
> 

*This* is PR41357; you must mean PR41308. Yes, I think so, I'll mark it as a
dup of this one.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #5 from davek at gcc dot gnu dot org  2009-09-15 12:52 -------
*** Bug 41308 has been marked as a duplicate of this bug. ***


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #6 from davek at gcc dot gnu dot org  2009-09-15 13:29 -------
(In reply to comment #1)
> The cause is that DW_TAG_variable references gomp_tls_data instead of
> ___emutls_v.gomp_tls_data.
> 

  Here's an example:

 <1><f51>: Abbrev Number: 49 (DW_TAG_variable)
    <f52>   DW_AT_name        : (indirect string, offset: 0x4a): gomp_tls_data  
    <f56>   DW_AT_decl_file   : 8       
    <f57>   DW_AT_decl_line   : 361     
    <f59>   DW_AT_type        : <0x96e> 
    <f5d>   DW_AT_external    : 1       
    <f5e>   DW_AT_declaration : 1       

This points to the declaration of gomp_tls_data on line 361 of libgomp.h


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #7 from davek at gcc dot gnu dot org  2009-09-15 13:40 -------
This looks a little tricky.

Knowledge of the "__emutls_v." prefix is entirely private to varasm.c.  The
actual prefixed object itself escapes publicly with that name, but only
varasm.c knows that subsequent references to that variable need to be prefixed
also, and this is not refelected anywhere in the DECL_NAME or
DECL_ASSEMBLER_NAME.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #8 from davek at gcc dot gnu dot org  2009-09-15 14:07 -------
(In reply to comment #6)
> (In reply to comment #1)
> > The cause is that DW_TAG_variable references gomp_tls_data instead of
> > ___emutls_v.gomp_tls_data.
> > 
> 
>   Here's an example:

  No, that's not it, that's not it at all, sorry.  Here's the relevant part of
the debug info from iter.s in the libgomp build dir, with a bit of surrounding
context:

        .byte   0x1
        .ascii "gomp_iter_dynamic_next_locked\0"
        .byte   0x1
        .byte   0x90
        .byte   0x1
        .long   0x7c3
        .long   LFB24
        .long   LFE24
        .secrel32       LLST13
        .long   0xc77
        .uleb128 0x1d
        .secrel32       LASF4
        .byte   0x1
        .byte   0x90
        .long   0xbc2
        .secrel32       LLST14
        .uleb128 0x1e
        .ascii "pend\0"
        .byte   0x1
        .byte   0x90
        .long   0xbc2
        .secrel32       LLST15
        .uleb128 0x24
        .ascii "thr\0"
        .byte   0x1
        .byte   0x92
   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
        .long   0xa79
        .long   _gomp_tls_data
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        .uleb128 0x25
        .ascii "ws\0"
        .byte   0x1
        .byte   0x93
        .long   0x4e7
        .byte   0x1
        .byte   0x52
        .uleb128 0x26
        .secrel32       LASF5
        .byte   0x1
        .byte   0x94
        .long   0xe0
        .byte   0x1
        .byte   0x51
        .uleb128 0x20
        .ascii "end\0"

Here's what objdump -W has to say about that:

 <1><bc8>: Abbrev Number: 28 (DW_TAG_subprogram)
    <bc9>   DW_AT_external    : 1       
    <bca>   DW_AT_name        : gomp_iter_dynamic_next_locked   
    <be8>   DW_AT_decl_file   : 1       
    <be9>   DW_AT_decl_line   : 144     
    <bea>   DW_AT_prototyped  : 1       
    <beb>   DW_AT_type        : <0x7c3> 
    <bef>   DW_AT_low_pc      : 0x250   
    <bf3>   DW_AT_high_pc     : 0x2a7   
    <bf7>   DW_AT_frame_base  : 0x1bc   (location list)
    <bfb>   DW_AT_sibling     : <0xc77> 
 <2><bff>: Abbrev Number: 29 (DW_TAG_formal_parameter)
    <c00>   DW_AT_name        : (indirect string, offset: 0x20): pstart 
    <c04>   DW_AT_decl_file   : 1       
    <c05>   DW_AT_decl_line   : 144     
    <c06>   DW_AT_type        : <0xbc2> 
    <c0a>   DW_AT_location    : 0x200   (location list)
 <2><c0e>: Abbrev Number: 30 (DW_TAG_formal_parameter)
    <c0f>   DW_AT_name        : pend    
    <c14>   DW_AT_decl_file   : 1       
    <c15>   DW_AT_decl_line   : 144     
    <c16>   DW_AT_type        : <0xbc2> 
    <c1a>   DW_AT_location    : 0x214   (location list)
 <2><c1e>: Abbrev Number: 36 (DW_TAG_variable)
    <c1f>   DW_AT_name        : thr     
    <c23>   DW_AT_decl_file   : 1       
    <c24>   DW_AT_decl_line   : 146     
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
    <c25>   DW_AT_type        : <0xa79> 
    <c29>   DW_AT_const_value : 0x0     
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (n.b. unrelocated value)
 <2><c2d>: Abbrev Number: 37 (DW_TAG_variable)
    <c2e>   DW_AT_name        : ws      
    <c31>   DW_AT_decl_file   : 1       
    <c32>   DW_AT_decl_line   : 147     
    <c33>   DW_AT_type        : <0x4e7> 
    <c37>   DW_AT_location    : 1 byte block: 52        (DW_OP_reg2)
 <2><c39>: Abbrev Number: 38 (DW_TAG_variable)
    <c3a>   DW_AT_name        : (indirect string, offset: 0x44): start  
    <c3e>   DW_AT_decl_file   : 1       
    <c3f>   DW_AT_decl_line   : 148     
    <c40>   DW_AT_type        : <0xe0>  
    <c44>   DW_AT_location    : 1 byte block: 51        (DW_OP_reg1)
 <2><c46>: Abbrev Number: 32 (DW_TAG_variable)
    <c47>   DW_AT_name        : end     
    <c4b>   DW_AT_decl_file   : 1       
    <c4c>   DW_AT_decl_line   : 148     
    <c4d>   DW_AT_type        : <0xe0>  
    <c51>   DW_AT_location    : 0x228   (location list)


-- 


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

[Bug debug/41357] libgomp build fail

[jzhang918 at gmail dot com]

------- Comment #9 from jzhang918 at gmail dot com  2009-09-15 14:21 -------
(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #1)
> > > The cause is that DW_TAG_variable references gomp_tls_data instead of
> > > ___emutls_v.gomp_tls_data.
> > > 
> > 
> >   Here's an example:
> 
>   No, that's not it, that's not it at all, sorry.  Here's the relevant part of
> the debug info from iter.s in the libgomp build dir, with a bit of surrounding
> context:
> 
>         .ascii "thr\0"
>         .byte   0x1
>         .byte   0x92
>    vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>         .long   0xa79
>         .long   _gomp_tls_data
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yeah, this is what I found. When var-tracking generates debug_insn, it should
use ___emutls_v.gomp_tls_data as normal insn is expanded.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #10 from davek at gcc dot gnu dot org  2009-09-15 14:24 -------
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > > (In reply to comment #1)
> > > > The cause is that DW_TAG_variable references gomp_tls_data instead of
> > > > ___emutls_v.gomp_tls_data.
> > > > 
> > > 
> > >   Here's an example:
> > 
> >   No, that's not it, that's not it at all, sorry.  Here's the relevant part of
> > the debug info from iter.s in the libgomp build dir, with a bit of surrounding
> > context:
> > 
> >         .ascii "thr\0"
> >         .byte   0x1
> >         .byte   0x92
> >    vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> >         .long   0xa79
> >         .long   _gomp_tls_data
> >    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Yeah, this is what I found. When var-tracking generates debug_insn, it should
> use ___emutls_v.gomp_tls_data as normal insn is expanded.
> 

  I'm just debugging add_location_or_const_value_attribute() which is where the
value gets added.  Not sure how to export knowledge of tls prefix from varasm.c
yet though.  We could punt on trying to attach a const value to the DIE
altogether, although that seems a shame since it's potentially knowable.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #11 from davek at gcc dot gnu dot org  2009-09-15 14:53 -------
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
#1  0x004d25ec in add_location_or_const_value_attribute (die=0x7fcbd660, 
    decl=0x7fe19e40, attr=DW_AT_location) at /gnu/gcc/gcc/gcc/tree.h:182
#2  0x004da1f2 in gen_variable_die (decl=0x7fe19e40, origin=0x0, 
    context_die=0x7fcbbe50) at /gnu/gcc/gcc/gcc/tree.h:182
#3  0x004deda3 in gen_decl_die (decl=0x7fe19e40, origin=0x0, 
    context_die=0x7fcbbe50) at /gnu/gcc/gcc/gcc/tree.h:182
#4  0x004dd3ed in process_scope_var (stmt=0x7fcb2060, decl=0x7fe19e40, 
    origin=0x0, context_die=0x7fcbbe50) at /gnu/gcc/gcc/gcc/tree.h:182
#5  0x004dd470 in decls_for_scope (stmt=0x7fcb2060, context_die=0x7fcbbe50, 
    depth=0) at /gnu/gcc/gcc/gcc/tree.h:182
#6  0x004d91d8 in gen_subprogram_die (decl=0x7fdfb500, context_die=0x7fe03678)
    at /gnu/gcc/gcc/gcc/tree.h:182
#7  0x004dea1c in gen_decl_die (decl=0x7fdfb500, origin=0x0, 
    context_die=0x7fe03678) at /gnu/gcc/gcc/gcc/tree.h:182
#8  0x004dfb56 in dwarf2out_decl (decl=0x7fdfb500)
    at /gnu/gcc/gcc/gcc/tree.h:182
#9  0x00834dbf in rest_of_handle_final () at /gnu/gcc/gcc/gcc/final.c:3131

In the above call stack, the rtx that is passed to add_const_value_attribute()
looks like this:

(gdb) call debug_rtx (rtl)
(symbol_ref:SI ("gomp_tls_data") [flags 0x42] <var_decl 0x7fe190c0
gomp_tls_data
>)

There is code in add_const_value_attribute() to avoid this problem already:

 12789  /* Attach a DW_AT_const_value attribute for a variable or a parameter
which
 12790     does not have a "location" either in memory or in a register.  These
 12791     things can arise in GNU C when a constant is passed as an actual
parameter
 12792     to an inlined function.  They can also arise in C++ where declared
 12793     constants do not necessarily get memory "homes".  */
 12794  
 12795  static void
 12796  add_const_value_attribute (dw_die_ref die, rtx rtl)
 12797  {
 12798    switch (GET_CODE (rtl))
 12799      {
     [ ... ]
 12911      case SYMBOL_REF:
 12912        if (GET_CODE (rtl) == SYMBOL_REF
 12913            && SYMBOL_REF_TLS_MODEL (rtl) != TLS_MODEL_NONE)
 12914          break;
 12915      case LABEL_REF:
 12916        add_AT_addr (die, DW_AT_const_value, rtl);
 12917        VEC_safe_push (rtx, gc, used_rtx_array, rtl);
 12918        break;

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.


-- 


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

[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

[Bug debug/41357] libgomp build fail

[jakub at gcc dot gnu dot org]

------- Comment #13 from jakub at gcc dot gnu dot org  2009-09-15 16:42 -------
tls-local-exec for the VAR_DECL is not expected to me, I'd say it should be
TLS_MODEL_EMULATED for the !targetm.have_tls case.  dwarf2out.c has no way
knowing the SYMBOL_REF needs special treatment, as when it is created,
encode_section_info only puts in the tls model if targetm.have_tls.  So,
probably it will need to do that even for !targetm.have_tls and put
TLS_MODEL_EMULATED into SYMBOL_REF_TLS_MODEL.  I wonder if such SYMBOL_REF ever
occurs in RTL except for DEBUG_INSNs/NOTE_VAR_INSN_LOCATION.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #14 from davek at gcc dot gnu dot org  2009-09-15 17:08 -------
Created an attachment (id=18586)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586&action=view)
reduced testcase


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #15 from davek at gcc dot gnu dot org  2009-09-15 17:16 -------
(In reply to comment #14)
> Created an attachment (id=18586)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586&action=view) [edit]
> reduced testcase
> 

  Ok, this is really interesting.

  The generated debug info only contains the ".long gomp_tls_data" if there are
*two* functions that both begin with 

    struct gomp_thread *thr = gomp_thread ();

Also, if you change the line to read

    struct gomp_thread *thr = gomp_thread () + 1;

it also doesn't happen.

  When I read through iter.c.207r.vartrack, I see lots of references to cselib.

  Is VTA inappropriately CSEing the two value/location expressions together? 
And perhaps losing track of the TLS status in the process?


-- 


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

[Bug debug/41357] libgomp build fail

[jakub at gcc dot gnu dot org]

------- Comment #16 from jakub at gcc dot gnu dot org  2009-09-15 17:19 -------
Please read what I wrote.

vartrack uses cselib as a value numbering implementation, not for anything
else.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #17 from davek at gcc dot gnu dot org  2009-09-15 17:25 -------
(In reply to comment #16)
> Please read what I wrote.

  I did, but I'm a few steps behind, and haven't figured out whether to blame
encode_section_info() for being naive, or to look at where the SYM_REF gets
created as part of vta location note handling and think that it ought to be
doing something more subtle there.

> vartrack uses cselib as a value numbering implementation, not for anything
> else.

  It's interesting that the debug code only tries to emit a const value for the
DIEs in the case where there are two references to the same value number.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #18 from davek at gcc dot gnu dot org  2009-09-15 17:36 -------
Created an attachment (id=18587)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18587&action=view)
patch based on jakub's suggestion

this fixes the testcase, so I may as well take it for a full bootstrap cycle.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |davek at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug debug/41357] libgomp build fail

[hjl dot tools at gmail dot com]

------- Comment #19 from hjl dot tools at gmail dot com  2009-09-15 17:41 -------
Index: varasm.c
===================================================================
--- varasm.c    (revision 151703)
+++ varasm.c    (working copy)
@@ -6420,6 +6420,8 @@ default_encode_section_info (tree decl, rtx rtl, i
   if (targetm.have_tls && TREE_CODE (decl) == VAR_DECL
       && DECL_THREAD_LOCAL_P (decl))
     flags |= DECL_TLS_MODEL (decl) << SYMBOL_FLAG_TLS_SHIFT;
+  else if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
+      flags |= TLS_MODEL_EMULATED << SYMBOL_FLAG_TLS_SHIFT;
   else if (targetm.in_small_data_p (decl))
     flags |= SYMBOL_FLAG_SMALL;
   /* ??? Why is DECL_EXTERNAL ever set for non-PUBLIC names?  Without

Can't you do

if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
{
  if (targetm.have_tls)
  else
}


-- 


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

[Bug debug/41357] libgomp build fail

[jakub at gcc dot gnu dot org]

------- Comment #20 from jakub at gcc dot gnu dot org  2009-09-15 17:45 -------
See PR41353 for possible explanation.  The last patch isn't complete there,
I'll post a fixed one once I do some further .debug_info analysis.  Anyway,
that has nothing to do with this PR, a SYMBOL_REF for a tls symbol can make it
into var location expressions and it is always the responsibility of
dwarf2out.c to either do something with them or throw them away.
Note that ___emutls_v.gomp_tls_data is definitely not what you want to
reference, that's not where the actual value is stored, but instead where just
some auxiliary info is recorded (pointer to the initial value of that variable,
size/alignment info and some internal value where to find the object in a TLS
block.  For real TLS implementation dwarf2out.c emits
DW_OP_GNU_push_tls_address, for emulated it apparently uses in some cases
DW_OP_form_tls_address.
If you make sure SYMBOL_REF_TLS_MODEL is set to SYMBOL_TLS_EMULATED on such
SYMBOL_REFs, then dwarf2out.c will do the right thing.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #21 from davek at gcc dot gnu dot org  2009-09-15 17:51 -------
(In reply to comment #19)
> Index: varasm.c
> ===================================================================
> --- varasm.c    (revision 151703)
> +++ varasm.c    (working copy)
> @@ -6420,6 +6420,8 @@ default_encode_section_info (tree decl, rtx rtl, i
>    if (targetm.have_tls && TREE_CODE (decl) == VAR_DECL
>        && DECL_THREAD_LOCAL_P (decl))
>      flags |= DECL_TLS_MODEL (decl) << SYMBOL_FLAG_TLS_SHIFT;
> +  else if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
> +      flags |= TLS_MODEL_EMULATED << SYMBOL_FLAG_TLS_SHIFT;
>    else if (targetm.in_small_data_p (decl))
>      flags |= SYMBOL_FLAG_SMALL;
>    /* ??? Why is DECL_EXTERNAL ever set for non-PUBLIC names?  Without
> 
> Can't you do
> 
> if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
> {
>   if (targetm.have_tls)
>   else
> }

  Yes, or I can do this:

Index: varasm.c
===================================================================
--- varasm.c    (revision 151703)
+++ varasm.c    (working copy)
@@ -6417,9 +6417,9 @@ default_encode_section_info (tree decl, rtx rtl, i
     flags |= SYMBOL_FLAG_FUNCTION;
   if (targetm.binds_local_p (decl))
     flags |= SYMBOL_FLAG_LOCAL;
-  if (targetm.have_tls && TREE_CODE (decl) == VAR_DECL
-      && DECL_THREAD_LOCAL_P (decl))
-    flags |= DECL_TLS_MODEL (decl) << SYMBOL_FLAG_TLS_SHIFT;
+  if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
+    flags |= (targetm.have_tls ? DECL_TLS_MODEL (decl) : TLS_MODEL_EMULATED)
+               << SYMBOL_FLAG_TLS_SHIFT;
   else if (targetm.in_small_data_p (decl))
     flags |= SYMBOL_FLAG_SMALL;
   /* ??? Why is DECL_EXTERNAL ever set for non-PUBLIC names?  Without

  I'll test this variant.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #22 from davek at gcc dot gnu dot org  2009-09-15 17:57 -------
Created an attachment (id=18588)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18588&action=view)
slightly reworked patch

slightly reworked per hj's suggestion


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18587|0                           |1
        is obsolete|                            |


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #23 from davek at gcc dot gnu dot org  2009-09-16 10:19 -------
Created an attachment (id=18595)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18595&action=view)
simplified fix

After discussion on the -patches list, it seemed sensible to try preserving the
precise value of the tls model that gets selected by the emulation, even if it
is a bit surprising, so this reworked patch simply removes the targetm.have_tls
test altogether.  Now running bootstrap-and-test cycle.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18588|0                           |1
        is obsolete|                            |


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

[Bug debug/41357] libgomp build fail

[jakub at gcc dot gnu dot org]

------- Comment #24 from jakub at gcc dot gnu dot org  2009-09-16 10:37 -------
As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even
their SYMBOL_REFs start using that TLS model.  But, unlike the user vars, these
occur normally in the instruction stream, so I wonder if this patch won't break
things.  Perhaps we shouldn't set SYMBOL_REF_TLS_MODEL if DECL_TLS_MODEL is
TLS_MODEL_EMULATED, otherwise it risks that e.g. backends reject it as invalid
constant.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #25 from davek at gcc dot gnu dot org  2009-09-16 10:51 -------
(In reply to comment #24)
> As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even
> their SYMBOL_REFs start using that TLS model.  But, unlike the user vars, these
> occur normally in the instruction stream, so I wonder if this patch won't break
> things.  Perhaps we shouldn't set SYMBOL_REF_TLS_MODEL if DECL_TLS_MODEL is
> TLS_MODEL_EMULATED, otherwise it risks that e.g. backends reject it as invalid
> constant.

  Yes, I see what you mean.  There are a lot of references to every other kind
of TLS_MODEL_xxx value in the backend files, but no mentions of
TLS_MODEL_EMULATED.  And just to pick one example:
xtensa_legitimize_tls_address() will gcc_unreachable() if it sees that value. 
So I'll give it one more try, adding a check that the decl's model isn't
_EMULATED.


-- 


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

[Bug debug/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #26 from davek at gcc dot gnu dot org  2009-09-16 10:54 -------
Created an attachment (id=18596)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18596&action=view)
YA respin

don't copy tls model into rtl flags for TLS_MODEL_EMULATED, only other values.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18595|0                           |1
        is obsolete|                            |


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

[Bug middle-end/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #27 from davek at gcc dot gnu dot org  2009-09-16 21:10 -------
This is not really specific to debug info after all, and since tls doesn't have
its own category, I think middle-end is the best description of this bug.

Just about to post test results from final respin, only check-target-libffi
left to go.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|debug                       |middle-end


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

[Bug middle-end/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #28 from davek at gcc dot gnu dot org  2009-09-16 21:29 -------
Subject: Bug 41357

Author: davek
Date: Wed Sep 16 21:29:17 2009
New Revision: 151773

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151773
Log:
        PR middle-end/41357
        * varasm.c (default_encode_section_info): Copy TLS model into
        sym_ref flags regardless of backend support for TLS, for all
        model types except TLS_MODEL_EMULATED.


Modified:
    branches/cygwin-improvements/gcc/ChangeLog.cygwin-improvements
    branches/cygwin-improvements/gcc/varasm.c


-- 


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

[Bug middle-end/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #29 from davek at gcc dot gnu dot org  2009-09-22 01:34 -------
Subject: Bug 41357

Author: davek
Date: Tue Sep 22 01:33:53 2009
New Revision: 151959

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151959
Log:
        PR middle-end/41357
        * varasm.c (default_encode_section_info): Copy TLS model into
        sym_ref flags regardless of backend support for TLS, for all
        model types except TLS_MODEL_EMULATED.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/varasm.c


-- 


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

[Bug middle-end/41357] libgomp build fail

[christian dot joensson at gmail dot com]

------- Comment #30 from christian dot joensson at gmail dot com  2009-09-24 11:10 -------
Not sure about the status here... but, on this system:
Windows XP Pro/SP3 cygwin Intel Core2 Duo T9600@2.80GHz system with packages:

binutils             2.19.51-1      2.19.51.20090704
bison                2.3-1          2.3
cloog-ppl            0.15.3-1
cygwin               1.7.0-61      
dejagnu              20021217-2     1.4.2.x
expect               20030128-1     5.26
gcc-ada              3.4.4-999
gcc-core             3.4.4-999
gcc-g++              3.4.4-999
gmp                  4.3.1-3
libcloog-devel       0.15.3-1
libgmp-devel         4.3.1-3
libmpfr-devel        2.4.1-4
libppl               0.10.2-1
make                 3.81-2
mpfr                 2.4.1-4
ppl                  0.10.2-1
ppl-devel            0.10.2-1
tcltk                20080420-1     8.4
w32api               3.13-1         

LAST_UPDATED: Thu Sep 24 09:42:02 UTC 2009 (revision 152114)

configure: --prefix=/usr/local/gnu --enable-threads=posix --enable-libgcj
--enable-libgomp --disable-sjlj-exceptions --with-system-zlib --enable-nls
--enable-static --enable-shared --enable-shared-libgcc --enable-__cxa_atexit
--disable-libmudflap --enable-version-specific-runtime-libs
--without-included-gettext --with-dwarf2 --disable-symvers --enable-libssp
--with-mpc --without-ppl --without-cloog
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++

I still get 

/bin/sh ./libtool --tag CC   --mode=link /usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/
-B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem
/usr/local/gnu/i686-pc-cygwin/include -isystem
/usr/local/gnu/i686-pc-cygwin/sys-include    -Wall -Werror -Wc,-pthread -g -O2 
 -Wl,-O1   -o libgomp.la -version-info 1:0:0  -no-undefined -bindir
"/usr/local/gnu/bin" -rpath /usr/local/gnu/lib/gcc/i686-pc-cygwin/4.5.0
alloc.lo barrier.lo critical.lo env.lo error.lo iter.lo iter_ull.lo loop.lo
loop_ull.lo ordered.lo parallel.lo sections.lo single.lo task.lo team.lo
work.lo lock.lo mutex.lo proc.lo sem.lo bar.lo ptrlock.lo time.lo fortran.lo
affinity.lo  
libtool: link: rm -fr  .libs/libgomp.dll.a
libtool: link: /usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/
-B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem
/usr/local/gnu/i686-pc-cygwin/include -isystem
/usr/local/gnu/i686-pc-cygwin/sys-include    -shared  .libs/alloc.o
.libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o
.libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o
.libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o
.libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o
.libs/time.o .libs/fortran.o .libs/affinity.o    -pthread -Wl,-O1   -o
.libs/cyggomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/libgomp.dll.a
xgcc: unrecognized option '-pthread'
Creating library file:
.libs/libgomp.dll.a.libs/team.o:team.c:(.debug_info+0x1084): undefined
reference to `_gomp_tls_data'
collect2: ld returned 1 exit status

make[4]: *** [libgomp.la] Error 1
make[4]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp'
make[1]: *** [all-target-libgomp] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir'
make: *** [all] Error 2


-- 


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

[Bug middle-end/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #31 from davek at gcc dot gnu dot org  2009-09-28 05:48 -------
(In reply to comment #30)
> I still get 
> 
> /bin/sh ./libtool --tag CC   --mode=link /usr/local/src/trunk/objdir/./gcc/xgcc
> -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/
> -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem
> /usr/local/gnu/i686-pc-cygwin/include -isystem
> /usr/local/gnu/i686-pc-cygwin/sys-include    -Wall -Werror -Wc,-pthread -g -O2 
>  -Wl,-O1   -o libgomp.la -version-info 1:0:0  -no-undefined -bindir
> "/usr/local/gnu/bin" -rpath /usr/local/gnu/lib/gcc/i686-pc-cygwin/4.5.0
> alloc.lo barrier.lo critical.lo env.lo error.lo iter.lo iter_ull.lo loop.lo
> loop_ull.lo ordered.lo parallel.lo sections.lo single.lo task.lo team.lo
> work.lo lock.lo mutex.lo proc.lo sem.lo bar.lo ptrlock.lo time.lo fortran.lo
> affinity.lo  
> libtool: link: rm -fr  .libs/libgomp.dll.a
> libtool: link: /usr/local/src/trunk/objdir/./gcc/xgcc
> -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/
> -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem
> /usr/local/gnu/i686-pc-cygwin/include -isystem
> /usr/local/gnu/i686-pc-cygwin/sys-include    -shared  .libs/alloc.o
> .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o
> .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o
> .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o
> .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o
> .libs/time.o .libs/fortran.o .libs/affinity.o    -pthread -Wl,-O1   -o
> .libs/cyggomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
> .libs/libgomp.dll.a
> xgcc: unrecognized option '-pthread'
> Creating library file:
> .libs/libgomp.dll.a.libs/team.o:team.c:(.debug_info+0x1084): undefined
> reference to `_gomp_tls_data'
> collect2: ld returned 1 exit status
> 
> make[4]: *** [libgomp.la] Error 1

  Yeah, confirmed at r.152230; this bug is not yet fixed.  Note that it's a
different .o file from those mentioned in the original error.  Haven't yet
debugged it to see how it's going wrong.


-- 


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

[Bug middle-end/41357] libgomp build fail

[christian dot joensson at gmail dot com]

------- Comment #32 from christian dot joensson at gmail dot com  2009-09-30 13:47 -------
I'm not sure how (or why) but... I checked out gcc trunk rev. 152325, and the
problems seems to have gone away (at least for now).


-- 


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

[Bug middle-end/41357] libgomp build fail

[davek at gcc dot gnu dot org]

------- Comment #33 from davek at gcc dot gnu dot org  2009-11-09 11:05 -------
This has been working fine for some time now, so closing.  Verified by building
r154011: no debuginfo problems.


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug middle-end/41357] libgomp build fail

[davek at gcc dot gnu dot org]

-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


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