From: Mike Stump <mikestump@comcast.net>
To: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
Cc: Jeff Law <law@redhat.com>,
James Greenhalgh <james.greenhalgh@arm.com>,
gcc-patches@gcc.gnu.org, ramana.radhakrishnan@arm.com
Subject: Re: [Patch testsuite] Skip gcc.dg/ifcvt-4.c for targets on which it may not work
Date: Thu, 24 Dec 2015 19:40:00 -0000 [thread overview]
Message-ID: <8483FAD3-6102-4FEA-B8F3-FA095686B360@comcast.net> (raw)
In-Reply-To: <56793306.8030505@arm.com>
On Dec 22, 2015, at 3:24 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
>
>> In theory what I want to be able to do is build all the listed targets
>> and run a single test on them so that we can build these skip/xfail
>> lists much easier.
>>
>> I've done it a few times by hand and it seems like it's something we
>> ought to be able to do much more easily.
> The bigger problem here is that branch costs are a property of a
> specific CPU, not the target architecture. So deciding whether or not
> we should skip this test (and perhaps others like it) is impossible
> given that we can't know what the default CPU for the compiler is (and
> even if we did know, maintaining such a list would be almost impossible).
As I see it, I don’t see any prohibition that c2e-gcc --target not list the information you seek. Nor do I see any prohibition that dejagnu not run the compiler with the that flag, nor that it read it and understand how gcc was configured. Neither do I see a prohibition that dejagnu not run a target piece of code to dynamically determine on what type of cpu (or/system) the code is running on. So, any desire not to do this, I think is a decision for the port maintainer alone. If they want to do this, they can, it they want to not do this, that’s their prerogative. Further, a port is free to have built-in preprocessor symbols that describe the targeted cpu and/or architecture.
One can even imagine that gcc provides feature test macros that can be used to make tests more portable.
As for what’s best, that’s for port maintainers and backend maintainers to decide. :-)
prev parent reply other threads:[~2015-12-24 19:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-18 9:55 James Greenhalgh
2015-12-21 19:38 ` Jeff Law
2015-12-22 11:25 ` Richard Earnshaw (lists)
2015-12-22 19:12 ` Jeff Law
2015-12-24 19:40 ` Mike Stump [this message]
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=8483FAD3-6102-4FEA-B8F3-FA095686B360@comcast.net \
--to=mikestump@comcast.net \
--cc=Richard.Earnshaw@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=james.greenhalgh@arm.com \
--cc=law@redhat.com \
--cc=ramana.radhakrishnan@arm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).