public inbox for
 help / color / mirror / Atom feed
From: "Richard Earnshaw (lists)" <>
To: Jim Wilson <>
Cc: "" <>
Subject: Re: [PATCH, ARM/AArch64] drop aarch32 support for falkor/qdf24xx
Date: Thu, 25 May 2017 09:29:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 24/05/17 17:19, Richard Earnshaw (lists) wrote:
> On 24/05/17 17:03, Jim Wilson wrote:
>> On Wed, May 24, 2017 at 8:17 AM, Richard Earnshaw (lists)
>> <> wrote:
>>> On 24/05/17 15:18, Jim Wilson wrote:
>>>> On Wed, May 24, 2017 at 6:56 AM, Richard Earnshaw (lists)
>>>> <> wrote:
>>>>> OK.  does this need to go in the gcc-8 changes file?
>>>> Falkor hasn't shipped yet.  I'm dropping features that only existed in
>>>> preproduction NDA hardware, so there isn't anything end user visible,
>>>> and hence I don't think that it needs to be in the release notes.
>>>> Jim
>>> Fair enough, so what about a minimal back-port to GCC-7 that just
>>> disables the CPU name for aarch32?
>> Not sure how to do that.  If I remove the entry, then 5
>> files get automatically regenerated.  That leaves us with a few minor
>> inconsistencies in specs handling and multilibs which are harmless but
>> we may as well fix anyways.  The only part of the patch that is
>> optional if the part which moves the qdf24xx_extra_costs array from
>> the arm dir to the aarch64 dir.  So the minimal patch ends up being
>> half the size of the original patch, changing 9 of the original 11
>> files, which isn't very minimal.
>> Another option might be to just remove the documentation and leave the
>> code in, i.e. only apply the doc/invoke.texi patch.  That would be a
>> small and safe patch.
>> Jim
> Certainly we should remove it from the documentation.  That might be the
> best idea.
> I don't really regard the size of the changes to the auto-generated code
> as being relevant - if we put the generated code directly in the build
> directory and treated it like we do the output from gen*.c, then those
> changes would never be even noticed.
> R.

Having pondered this over night, I think the lowest risk thing to do,
provided it applies cleanly to the gcc-7 branch, is just commit the
entire patch on the branch and be done with it.  The risk from removing
this code is pretty minimal and removing it all is the best way of
avoiding things like unexpected compiler warnings breaking the build.
If it doesn't apply cleanly, then just drop the documentation.


  reply	other threads:[~2017-05-25  9:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12  3:52 Jim Wilson
2017-05-24 14:12 ` Richard Earnshaw (lists)
2017-05-24 14:20   ` Jim Wilson
2017-05-24 15:20     ` Richard Earnshaw (lists)
2017-05-24 16:05       ` Jim Wilson
2017-05-24 16:30         ` Richard Earnshaw (lists)
2017-05-25  9:29           ` Richard Earnshaw (lists) [this message]
2017-06-09 20:03             ` Jim Wilson
2017-06-10  9:44               ` Richard Earnshaw (lists)
2017-06-12 10:40               ` James Greenhalgh
2017-06-23 21:46                 ` Jim Wilson

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:

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

  git send-email \ \ \ \ \

* 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).