From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5912 invoked by alias); 1 May 2014 10:52:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5899 invoked by uid 89); 1 May 2014 10:52:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 May 2014 10:52:17 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s41AqERu000628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 May 2014 06:52:14 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s41AqBT7032212; Thu, 1 May 2014 06:52:12 -0400 Message-ID: <5362275B.2080108@redhat.com> Date: Thu, 01 May 2014 10:52:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Blaikie CC: Andrew Pinski , gdb-patches , Eric Christopher , Doug Evans Subject: Re: [patch] explicitly specify -std=gnu89 for gdb.cp/inline-break.exp References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00001.txt.bz2 On 04/13/2014 08:08 AM, David Blaikie wrote: > On Fri, Apr 11, 2014 at 7:59 PM, Andrew Pinski wrote: >> On Fri, Apr 11, 2014 at 4:58 PM, David Blaikie wrote: >>> This test is intending to use gnu style inline rather than the >>> standard c99 inline semantics. Clang defaults to c99 and the test >>> breaks for this (and other - there's an inlining debug info quality >>> bug here too - I'll file a bug and kfail the remaining failures in a >>> separate patch) reason. >> >> Or better yet, use the gnu_inline attribute on those functions. > > Ah, good plan - patch attached for that fix instead. > > Though at this point, I'd consider removing the GNUC conditional - for > this test to be meaningful the compiler must support gnu inlining > semantics. Are there compilers that support those semantics but don't > support GCC attribute syntax and the gnu_inline attribute in > particular? A web search indicates IBM's xlc supports it: http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.cbclx01%2Ffn_attrib_gnu_inline.htm (and always_inline too.) And I know ARM's compiler supports it too. If there's such a compiler, we can readjust. The patch is OK. > Removing the conditional would cause any compiler that doesn't support > the attributes to just fail to compile, marking the test as untested > rather than producing failures. That'd be fine, I think. In fact, it might even make the test work under xlc... (no idea of people actually test that). That change is pre-approved (but please do make it a separate change). Although the test as is requires gnu semantics, we're really after making sure that setting breakpoints in inline functions work. We should probably test all off gnu inline semantics, c99 semantics, and also c++ semantics too. -- Pedro Alves