Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: David Blaikie <dblaikie@gmail.com>
Cc: Andrew Pinski <pinskia@gmail.com>,
	       gdb-patches <gdb-patches@sourceware.org>,
	       Eric Christopher <echristo@gmail.com>,
	Doug Evans <dje@google.com>
Subject: Re: [patch] explicitly specify -std=gnu89 for gdb.cp/inline-break.exp
Date: Thu, 01 May 2014 10:52:00 -0000	[thread overview]
Message-ID: <5362275B.2080108@redhat.com> (raw)
In-Reply-To: <CAENS6EsjGe7e6M987QPFjabnJWAGMd45XvhzDgTTthK_FojN_g@mail.gmail.com>

On 04/13/2014 08:08 AM, David Blaikie wrote:
> On Fri, Apr 11, 2014 at 7:59 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>> On Fri, Apr 11, 2014 at 4:58 PM, David Blaikie <dblaikie@gmail.com> 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


  reply	other threads:[~2014-05-01 10:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-11 23:58 David Blaikie
2014-04-12  0:18 ` Doug Evans
2014-04-12  0:40   ` David Blaikie
2014-04-12  2:59 ` Andrew Pinski
2014-04-13  7:08   ` David Blaikie
2014-05-01 10:52     ` Pedro Alves [this message]
2014-05-30 11:25       ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5362275B.2080108@redhat.com \
    --to=palves@redhat.com \
    --cc=dblaikie@gmail.com \
    --cc=dje@google.com \
    --cc=echristo@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pinskia@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox