From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-463520-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 26712 invoked by alias); 8 Oct 2014 08:12:26 -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
Received: (qmail 26674 invoked by uid 48); 8 Oct 2014 08:12:23 -0000
From: "vogt at linux dot vnet.ibm.com" <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 08:12: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: vogt at linux dot vnet.ibm.com
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-FG2NzTyq45@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/msg00541.txt.bz2

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

--- Comment #22 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
>> Hm, so the patch penalises platforms that cannot deal with the
>> 16 byte window?

> Yes, but, recall that on your system almost all tests pass using the
> code that is in the tree today, before your patch.

But they really only succeed "by accident".  The call for any platform might
introduce control flow into the thunk and trigger the problem in any of the
test cases.

> The spec says "Suppose a function G defers a function D that calls
> recover and a panic occurs in a function on the same goroutine in
> which G is executing."  The order is 1) G defers D; 2) a panic occurs.
> ...

I'd still not understand it that way, but from other documentation the
intention is "clear".  Maybe another bullet could be added to the list
below:

  "The return value of recover is nil if ...

    ...
    * defer was called when the panic already existed"