public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Phil Blundell <pb@pbcl.net>
To: Andre McCurdy <armccurdy@gmail.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCHv2][RFC] arch-armv7ve.inc: respect armv7a override as well
Date: Fri, 08 Jan 2016 20:13:04 +0000	[thread overview]
Message-ID: <1452283984.1933.15.camel@pbcl.net> (raw)
In-Reply-To: <CAJ86T=WNGGp=L358DSu2+VXM4eEdOz9FRcDBkGueUap80RjGBw@mail.gmail.com>

On Fri, 2016-01-08 at 08:24 -0800, Andre McCurdy wrote:
> Maybe adding a generic "armv7" over-ride which can be enabled by all
> armv7 variants is a better option?

Maybe, but the time to consider that would be when we discover a
concrete place that it'd be useful. 

To be honest, having seen the existing overrides that you sent patches
for, there are very few cases where an override on _armv7a or any other
specific variant seems unambiguously like the right thing.  For example,
looking at the tree I happen to have lying around here:

- it seems that the valgrind ones have already been established as
spurious;

- the libav FULL_OPTIMIZATION thing also seems fairly spurious. 

- the overrides in gcc-configure-common are basically just trying to
translate TARGET_ARCH back into the appropriate -march flag for gcc, and
it seems faintly silly to require a separate override for every possible
arch setting.  It might be better for the tuning files to define a
specific variable with the -march string in, define CFLAGS in terms of
that, and then just teach gcc's configury to do --with-arch=${GCC_ARCH}
if it's defined.

- the ones in xf86-video-omapfb_git.bb seem to be using armv7a as a
proxy for "this is a particular omap chip" in order to trigger some or
other hack.  Since omapfb is fairly chip-specific anyway this is
probably ok, but it most likely doesn't want perpetuating.

Then there are things like the armv4/armv5 overrides in mailx which are
apparently workarounds for a bug in some or other version of gcc.  The
common thread through most of these seems to be that thumb1 support just
doesn't work very well in gcc and, given that thumb1 is something of a
minority interest nowadays, it's tempting to say that we should not even
try to support it any longer.  But if we did want to keep it around then
defining a specific "thumb1" override that would be set by all thumb1
arches seems like it would be the right short term fix.  In the long
term, clearly, the best plan would be for the folks who still care about
thumb1 to fix gcc.

So, overall, it rather seems to me that we should be trying to get rid
of the majority of these _armvNN overrides, rather than letting them
proliferate into armv7ve and whatever.

p.




      parent reply	other threads:[~2016-01-08 20:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 12:36 [PATCH][RFC] arch-armv7ve.inc: respcet armv7a override as well Martin Jansa
2016-01-08 12:44 ` [PATCHv2][RFC] arch-armv7ve.inc: respect " Martin Jansa
2016-01-08 16:24   ` Andre McCurdy
2016-01-08 17:00     ` Martin Jansa
2016-01-08 18:24       ` Andre McCurdy
2016-01-08 20:44         ` Phil Blundell
2016-01-11 19:10         ` Khem Raj
2016-01-11 19:52           ` Phil Blundell
2016-01-11 20:03             ` Khem Raj
2016-01-11 19:53           ` Andre McCurdy
2016-01-08 20:13     ` Phil Blundell [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=1452283984.1933.15.camel@pbcl.net \
    --to=pb@pbcl.net \
    --cc=armccurdy@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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