From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100487 invoked by alias); 6 Mar 2015 16:47:51 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 100426 invoked by uid 48); 6 Mar 2015 16:47:48 -0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10 Date: Fri, 06 Mar 2015 16:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: 2015-03/txt/msg00732.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D64883 --- Comment #34 from Iain Sandoe --- (In reply to Dominique d'Humieres from comment #33) > Changed the summary to x86_64-apple-darwin10 (this probably affects > powerpc-apple-darwin9 also). correct; there is one additional needed for ppc-darwin9 and x86-darwin{9,10} I have a suitable patch, and as discussed on irc with Jonathan had intended= to apply that version; unfortunately between investigating ipa-icf issues and being out of the office in the US, haven't had a chance so far (thanks to Jonathan for applying the interim one). .. will apply an incremental change for earlier darwin as "obvious" at the first available opportunity (unless anyone has an objection) =E2=80=A6 (abo= ut to re-sync trunk and test). >>From gcc-bugs-return-479589-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 06 16:57:31 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 113583 invoked by alias); 6 Mar 2015 16:57:31 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 113524 invoked by uid 48); 6 Mar 2015 16:57:27 -0000 From: "boger at us dot ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/64999] s390x libgo test failure in TestMemoryProfiler Date: Fri, 06 Mar 2015 16:57: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: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: boger at us dot ibm.com X-Bugzilla-Status: UNCONFIRMED 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: In-Reply-To: References: 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: 2015-03/txt/msg00733.txt.bz2 Content-length: 907 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #36 from boger at us dot ibm.com --- I'd like to take a step back and clarify what the functions in question, runtime_callers, runtime.Caller, and runtime.Callers should be returning: the pc values for the call instruction, or the pc values from the instruction following the call? The golang documentation for runtime.Callers says it is the pc for the instruction after the call so I will assume that is what we want for that one. For runtime.Caller I believe it is supposed to return the call instruction itself but I'm not 100% sure on that. Since runtime.Callers calls runtime_callers, I assume runtime_callers should be providing the instruction after the call. That means all callers of runtime_callers should be decrementing pc values to the previous instruction if the call instruction is what they want. Does this sound right?