[Bug go/60406] recover.go: test13reflect2 test failure

["ian at airs dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406

--- Comment #26 from Ian Lance Taylor <ian at airs dot com> ---
(In reply to Dominik Vogt from comment #23)
> 
> 1) We need to call __builtin_extract_return_address(retaddr) in
> __go_set_defer_retaddr() too.  (On s390 (31 bit) this is necessary to remove
> the most significant bit of the address which indicates the addressing mode.)
> 
> I.e.
> 
> --snip--
> -    g->defer->__retaddr = retaddr;
> +    g->defer->__retaddr = __builtin_extract_return_addr (retaddr);
> --snip--

Will do.


> 2) The new patch does not compile for me:
> 
> --
> In file included from ../../../libgo/runtime/go-check-interface.c:8:0:
> ../../../libgo/runtime/go-panic.h:43:13: error: conflicting types for
> ‘__go_makefunc_can_recover’
>  extern void __go_makefunc_can_recover (void *retaddr);
>              ^
> In file included from ../../../libgo/runtime/go-check-interface.c:7:0:
> ../../../libgo/runtime/runtime.h:845:9: note: previous declaration of
> ‘__go_makefunc_can_recover’ was here
>  void    __go_makefunc_can_recover (const void *);
>          ^
> --
> 
> In runtime.h, __go_makefunc_can_recover still has a "const" argument:
> 
> --snip--
> -void    __go_makefunc_can_recover (const void *);
> +void    __go_makefunc_can_recover (void *);
> --snip--

I think that must be a local change in your tree.  In my tree runtime.h does
not declare __go_makefunc_can_recover.


> 3) Couldn't this be written more efficiently by passing a flag?
> 
> +  /* If we are called from __go_makefunc_can_recover, then we need to
> +     look one level higher.  */
> +  if (locs[0].function.len > 0
> +      && __builtin_strcmp ((const char *) locs[0].function.str,
> +			   "__go_makefunc_can_recover") == 0)
> 
> E.g.
> 
>   _Bool __go_can_recover (void *retaddr, _Bool
> called_by_makefunc_can_recover)
>   {
>     ...
>     if (called_by_makefunc_can_recover)
>       { do something }
>     else
>       { do something else }
>     ...
>   }

Yes, but I would rather do that later if it seems useful.  It seems silly to
change the compiler to always pass an extra argument that will always be false.
 Introducing a new function called by both __go_can_recover and
__go_makefunc_can_recover changes the stack layout depending on the compiler's
inlining choices, so must be treated with care.  And it's worth remembering
that this case never ever happens outside of tests.  It only happens when
somebody constructs a function using reflect.MakeFunc and then defers a call to
that function.  That is a bizarre way to code and I am confident that
absolutely no real Go code does it.  Making that case slightly less efficient
is not important.


> 4) With the suggested changes from 1 and 2 above:
> 
> s390x (64 bit):
> 
> * PASS: test/recover.go
> * the test from #4 in my earlier posting works as expected
> * my private defer/recover/panic testsuite works as expected
> 
> s390 (31 bit):
> 
> * PASS: test/recover.go
> * the test from #4 in my earlier posting works as expected
> * my private defer/recover/panic testsuite works as expected

Thanks for testing.


> 5) I find the assumption in the loop at the end of __go_can_recover() that
> if a caller's name begins with "__go_" that means the panic can be
> recovered, a bit hairy.  Even if it is with the current libgo, an unrelated
> change elsewhere could break this logic.

I agree that it's imperfect.  However, it's fairly difficult to construct a
case that causes the wrong thing to happen.  No Go function can ever start with
__go.  Very little code in libgo calls a function written in Go; it's easy to
find such code because it must call __go_set_closure (the defer thunks are a
special case that are known to have no closure).  So it can only happen if
somebody writes a Go function that calls recover, and then passes it to C code,
and that C code names a function starting with "__go_" and then calls the Go
function.  And this has to happen from a deferred function called while there
is a panic in progress.  The result will be that the function called by the C
code will incorrectly recover the panic.
>From gcc-bugs-return-463563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 13:51:04 2014
Return-Path: <gcc-bugs-return-463563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29377 invoked by alias); 8 Oct 2014 13:51:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29351 invoked by uid 48); 8 Oct 2014 13:51:00 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63485] New: [5 Regression] ICE: canonical types differ for identical types A<const wchar_t [3]>::type and const char_type [3]
Date: Wed, 08 Oct 2014 13:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63485-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00584.txt.bz2
Content-length: 4634

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485

            Bug ID: 63485
           Summary: [5 Regression] ICE: canonical types differ for
                    identical types A<const wchar_t [3]>::type and const
                    char_type [3]
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org

Running the Boost testsuite shows:

markus@x4 /tmp % cat date_time_format_parser.ii
template <typename C> struct A
{
  typedef C type;
};
template <class> class B
{
};
template <class Range> void as_literal (Range &);
template <typename> struct C
{
  typedef wchar_t char_type;
  const char_type on_full_year_placeholder[3];
  void
  on_extended_iso_date ()
  {
    B<A<wchar_t const[3]>::type> a;
    as_literal (on_full_year_placeholder);
  }
};
template <typename> struct date_time_format_parser_callback : C<wchar_t>
{
};
template <typename BaseT> struct D
{
  typedef typename BaseT::char_type char_type;
  char_type
  parse (const char_type *, const char_type *,
         typename BaseT::callback_type p3)
  {
    p3.on_extended_iso_date ();
  }
};
struct F
{
  typedef date_time_format_parser_callback<wchar_t> callback_type;
  typedef wchar_t char_type;
};
template <typename CharT, typename ParserT, typename CallbackT>
void
parse_format (CharT *p1, ParserT p2, CallbackT p3)
{
  CharT p = p2.parse (&p, p1, p3);
}
template <typename CharT>
void
parse_date_time_format (const CharT *, const CharT *p2,
                        date_time_format_parser_callback<CharT> &p3)
{
  D<F> b;
  parse_format (p2, b, p3);
}
template void
parse_date_time_format (const wchar_t *, const wchar_t *,
                        date_time_format_parser_callback<wchar_t> &);



markus@x4 /tmp % g++ -c -w -O0 date_time_format_parser.ii
date_time_format_parser.ii: In instantiation of ‘void C<
<template-parameter-1-1> >::on_extended_iso_date() [with
<template-parameter-1-1> = wchar_t]’:
date_time_format_parser.ii:30:5:   required from ‘D<BaseT>::char_type
D<BaseT>::parse(const char_type*, const char_type*, typename
BaseT::callback_type) [with BaseT = F; D<BaseT>::char_type = wchar_t; typename
BaseT::callback_type = date_time_format_parser_callback<wchar_t>]’
date_time_format_parser.ii:42:33:   required from ‘void parse_format(CharT*,
ParserT, CallbackT) [with CharT = const wchar_t; ParserT = D<F>; CallbackT =
date_time_format_parser_callback<wchar_t>]’
date_time_format_parser.ii:50:16:   required from ‘void
parse_date_time_format(const CharT*, const CharT*,
date_time_format_parser_callback<CharT>&) [with CharT = wchar_t]’
date_time_format_parser.ii:54:68:   required from here
date_time_format_parser.ii:17:16: internal compiler error: canonical types
differ for identical types A<const wchar_t [3]>::type and const char_type [3]
{aka A<const wchar_t [3]>::type}
     as_literal (on_full_year_placeholder);
                ^
0x6b6ebe comptypes(tree_node*, tree_node*, int)
        ../../gcc/gcc/cp/typeck.c:1407
0x6b4ffd structural_comptypes
        ../../gcc/gcc/cp/typeck.c:1341
0x6b6e77 comptypes(tree_node*, tree_node*, int)
        ../../gcc/gcc/cp/typeck.c:1399
0x6d1c51 ocp_convert(tree_node*, tree_node*, int, int, int)
        ../../gcc/gcc/cp/cvt.c:686
0x57baf8 convert_like_real
        ../../gcc/gcc/cp/call.c:6471
0x57832c build_over_call
        ../../gcc/gcc/cp/call.c:7209
0x587911 build_new_function_call(tree_node*, vec<tree_node*, va_gc,
vl_embed>**, bool, int)
        ../../gcc/gcc/cp/call.c:4072
0x7060b4 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool,
bool, int)
        ../../gcc/gcc/cp/semantics.c:2366
0x5fb7c6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
        ../../gcc/gcc/cp/pt.c:15095
0x5db9d6 tsubst_expr
        ../../gcc/gcc/cp/pt.c:14272
0x5dbb1f tsubst_expr
        ../../gcc/gcc/cp/pt.c:13683
0x5db34b tsubst_expr
        ../../gcc/gcc/cp/pt.c:13669
0x5dc7e0 tsubst_expr
        ../../gcc/gcc/cp/pt.c:13855
0x5d9a7d instantiate_decl(tree_node*, int, bool)
        ../../gcc/gcc/cp/pt.c:20231
0x620192 instantiate_pending_templates(int)
        ../../gcc/gcc/cp/pt.c:20347
0x65d4d4 cp_write_global_declarations()
        ../../gcc/gcc/cp/decl2.c:4367
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-463565-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 13:58:58 2014
Return-Path: <gcc-bugs-return-463565-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9270 invoked by alias); 8 Oct 2014 13:58:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9234 invoked by uid 55); 8 Oct 2014 13:58:54 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63483] Scheduler performs Invalid move of aliased memory reference
Date: Wed, 08 Oct 2014 13:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ubizjak at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63483-4-JvLJIJRU3C@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00586.txt.bz2
Content-length: 5115

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 8 Oct 2014, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
> 
> --- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
> (In reply to Richard Biener from comment #5)
> > The bug is clearly in
> > 
> > "
> > > Btw, if the mem is MEM_READONLY_P how can it be part of
> > > a {un}aligned_store sequence?
> > 
> > This flag is copied from the original memory operand of the store by
> > alpha_set_memflags to all memory operands in the expanded sequence."
> > 
> > and thus should be fixed there.  What is the "original" memory reference
> > here?  It seems for the read-modify-write you should use the target MEM
> > but somehow a source MEM gets used?  Or rather you should not use either
> > MEMs flags for _all_ MEMs in the sequence but properly distinguish between
> > MEMs generated for the load of the source and MEMs generated for the store
> > to the destination.
> 
> No, this is wrong conclusion. I have new insight into this problem.
> 
> Please consider following test:
> 
> --cut here--
> static char *a;
> static int *b;
> 
> void foo (void)
> {
>   a[1] = 1;
>   b[2] = 1;
> }
> 
> int bar (void)
> {
>   return a && b;
> }
> --cut here--
> 
> (e.g. changing "static char *b" to "static int *b". This way, the problematic
> insn is generated as "native" read:
> 
> (insn 15 14 16 2 (set (reg/f:DI 78)
>         (mem/u/f/c:DI (lo_sum:DI (reg:DI 79)
>                 (symbol_ref:DI ("b") [flags 0x6]  <var_decl 0x2b1d67f5e090 b>))
> [2 b+0 S8 A64])) rmw1.c:7 -1
>      (nil))
> 
> and this is again moved over
> 
> (insn 13 12 14 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72)
>                     (const_int 1 [0x1]))
>                 (const_int -8 [0xfffffffffffffff8])) [0  S8 A64])
>         (reg:DI 77)) rmw1.c:6 -1
>      (nil))
> 
> (note that there is no "/u" suffix on the *store* of "a".)
> 
> With this testcase, we have following sequence before sched1 pass:
> 
>     5: r73:DI=high(`a')
>     6: r72:DI=[r73:DI+low(`a')]
>       REG_DEAD r73:DI
>     7: r74:QI=0x1
>     8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
>     9: r75:DI=r72:DI+0x1
>    10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
>    11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
>       REG_DEAD r75:DI
>       REG_DEAD r74:QI
>       REG_EQUAL 0x1<<r75:DI<<0x3
>    12: r77:DI=r77:DI|r76:DI
>       REG_DEAD r76:DI
>    13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
>       REG_DEAD r77:DI
>       REG_DEAD r72:DI
>    14: r79:DI=high(`b')
>    15: r78:DI=[r79:DI+low(`b')]
>       REG_DEAD r79:DI
>    16: r80:SI=0x1
>    17: [r78:DI+0x8]=r80:SI
>       REG_DEAD r80:SI
>       REG_DEAD r78:DI
> 
> and sched1 moves (insn 15) all the way up, past (insn 13):
> 
>     5: r73:DI=high(`a')
>    14: r79:DI=high(`b')
>     7: r74:QI=0x1
>     6: r72:DI=[r73:DI+low(`a')]
>       REG_DEAD r73:DI
>    16: r80:SI=0x1
>    15: r78:DI=[r79:DI+low(`b')]
>       REG_DEAD r79:DI
>     9: r75:DI=r72:DI+0x1
>     8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
>    11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
>       REG_DEAD r75:DI
>       REG_DEAD r74:QI
>       REG_EQUAL 0x1<<r75:DI<<0x3
>    10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
>    12: r77:DI=r77:DI|r76:DI
>       REG_DEAD r76:DI
>    13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
>       REG_DEAD r77:DI
>       REG_DEAD r72:DI
>    17: [r78:DI+0x8]=r80:SI
>       REG_DEAD r80:SI
>       REG_DEAD r78:DI
>    20: NOTE_INSN_DELETED
> 
> (this particular sequence won't end in a failure, but the insn shouldn't be
> moved past possibly aliasing (insn 13) anyway.
> 
> Patched compiler results in:
> 
>     5: r73:DI=high(`a')
>     7: r74:QI=0x1
>    14: r79:DI=high(`b')
>     6: r72:DI=[r73:DI+low(`a')]
>       REG_DEAD r73:DI
>    16: r80:SI=0x1
>     9: r75:DI=r72:DI+0x1
>     8: r76:DI=[r72:DI+0x1&0xfffffffffffffff8]
>    11: r77:DI=zero_extend(r74:QI)<<r75:DI<<0x3
>       REG_DEAD r75:DI
>       REG_DEAD r74:QI
>       REG_EQUAL 0x1<<r75:DI<<0x3
>    10: r76:DI=!0xff<<r75:DI<<0x3&r76:DI
>    12: r77:DI=r77:DI|r76:DI
>       REG_DEAD r76:DI
>    13: [r72:DI+0x1&0xfffffffffffffff8]=r77:DI
>       REG_DEAD r77:DI
>       REG_DEAD r72:DI
>    15: r78:DI=[r79:DI+low(`b')]
>       REG_DEAD r79:DI
>    17: [r78:DI+0x8]=r80:SI
>       REG_DEAD r80:SI
>       REG_DEAD r78:DI
> 
> As shown, the code further down in true_dependence_1 function blocks the move,
> since the read is detected as aliased with the preceding store involving AND
> alignment.
> 
> There is nothing that can be done in target-dependant code, since the "native"
> read from "b" gets marked as "unchanging" by the generic middle-end code.

Where is that done?  It looks bogus to me.

> Please reconsider the "component" setting. There is nothing that can be fixed
> in target-dependent code.

I'm not sure - copying MEM flags to all MEMs from a single source seems
possibly wrong.
>From gcc-bugs-return-463564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 13:58:15 2014
Return-Path: <gcc-bugs-return-463564-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8466 invoked by alias); 8 Oct 2014 13:58:14 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8435 invoked by uid 48); 8 Oct 2014 13:58:10 -0000
From: "mira.suk at centrum dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63486] New: Magic Statics lock guard does not include registration into atexit handler
Date: Wed, 08 Oct 2014 13:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mira.suk at centrum dot cz
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63486-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00585.txt.bz2
Content-length: 13969

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63486

            Bug ID: 63486
           Summary: Magic Statics lock guard does not include registration
                    into atexit handler
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mira.suk at centrum dot cz

void test()
{                                                                              
  static std::string x;
}

If I'm reading assembly right _cxa_atexit handler is not called inside lock
which could result in static variable being destructed multiple times.

Is compiled into following with -g3

   |0x401312 <test()>       push   %rbp                                        
                                                                        │
   │0x401313 <test()+1>     mov    %rsp,%rbp                                   
                                                                        │
   │0x401316 <test()+4>     push   %r12                                        
                                                                        │
   │0x401318 <test()+6>     push   %rbx                                        
                                                                        │
   |0x401319 <test()+7>     lea    0x202e10(%rip),%rax        # 0x604130
<_ZGVZ4testvE1x>                                                              
│
   │0x401320 <test()+14>    movzbl (%rax),%eax                                 
                                                                        │
   │0x401323 <test()+17>    test   %al,%al                                     
                                                                        │
   │0x401325 <test()+19>    jne    0x401398 <test()+134>                       
                                                                               
        │
   │0x401327 <test()+21>    lea    0x202e02(%rip),%rdi        # 0x604130
<_ZGVZ4testvE1x>                                                               
               │
   │0x40132e <test()+28>    callq  0x400c40 <__cxa_guard_acquire@plt>          
                                                                               
        │
   │0x401333 <test()+33>    test   %eax,%eax                                   
                                                                               
        │
   │0x401335 <test()+35>    setne  %al                                         
                                                                               
        │
   │0x401338 <test()+38>    test   %al,%al                                     
                                                                               
        │
   │0x40133a <test()+40>    je     0x401398 <test()+134>                       
                                                                               
        │
   │0x40133c <test()+42>    mov    $0x0,%r12d                                  
                                                                               
        │
   │0x401342 <test()+48>    lea    0x202dff(%rip),%rdi        # 0x604148
<_ZZ4testvE1x>                                                                 
               │
   │0x401349 <test()+55>    callq  0x400c20 <_ZNSsC1Ev@plt>                    
                                                                               
        │
   │0x40134e <test()+60>    lea    0x202ddb(%rip),%rdi        # 0x604130
<_ZGVZ4testvE1x>                                                               
               │
   │0x401355 <test()+67>    callq  0x400cb0 <__cxa_guard_release@plt>          
                                                                               
        │
   │0x40135a <test()+72>    lea    0x202d87(%rip),%rdx        # 0x6040e8       
                                                                               
        │
   │0x401361 <test()+79>    lea    0x202de0(%rip),%rsi        # 0x604148
<_ZZ4testvE1x>                                                                 
               │
   │0x401368 <test()+86>    mov    0x202c81(%rip),%rax        # 0x603ff0       
                                                                               
        │
   │0x40136f <test()+93>    mov    %rax,%rdi                                   
                                                                               
        │
   │0x401372 <test()+96>    callq  0x400ef1 <__cxa_atexit(void (*)(void*),
void*, void*)>                                                                 
             │
   │0x401377 <test()+101>   jmp    0x401398 <test()+134>                       
                                                                               
        │
   │0x401379 <test()+103>   mov    %rax,%rbx                                   
                                                                               
        │
   │0x40137c <test()+106>   test   %r12b,%r12b                                 
                                                                               
        │
   │0x40137f <test()+109>   jne    0x40138d <test()+123>                       
                                                                               
        │
   │0x401381 <test()+111>   lea    0x202da8(%rip),%rdi        # 0x604130
<_ZGVZ4testvE1x>                                                               
               │
   │0x401388 <test()+118>   callq  0x400d10 <__cxa_guard_abort@plt>            
                                                                               
        │
   │0x40138d <test()+123>   mov    %rbx,%rax                                   
                                                                               
        │
   │0x401390 <test()+126>   mov    %rax,%rdi                                   
                                                                               
        │
   │0x401393 <test()+129>   callq  0x400d70 <_Unwind_Resume@plt>               
                                                                               
        │
   │0x401398 <test()+134>   pop    %rbx                                        
                                                                               
        │
   │0x401399 <test()+135>   pop    %r12                                        
                                                                               
        │
   │0x40139b <test()+137>   pop    %rbp                                        
                                                                               
        │
>From gcc-bugs-return-463566-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 14:03:49 2014
Return-Path: <gcc-bugs-return-463566-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16921 invoked by alias); 8 Oct 2014 14:03:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16882 invoked by uid 55); 8 Oct 2014 14:03:46 -0000
From: "ian at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/60406] recover.go: test13reflect2 test failure
Date: Wed, 08 Oct 2014 14:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ian at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60406-4-bfj85PJtQh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60406-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60406-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00587.txt.bz2
Content-length: 641

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`406

--- Comment #27 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Wed Oct  8 14:03:13 2014
New Revision: 216003

URL: https://gcc.gnu.org/viewcvs?rev!6003&root=gcc&view=rev
Log:
    PR go/60406
runtime: Check callers in can_recover if return address    doesn't match.

Also use __builtin_extract_return_address and tighten up the
checks in FFI code.

Fixes PR 60406.

Modified:
    trunk/libgo/go/reflect/makefunc_ffi_c.c
    trunk/libgo/runtime/go-defer.c
    trunk/libgo/runtime/go-panic.h
    trunk/libgo/runtime/go-recover.c
    trunk/libgo/runtime/panic.c