public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel.sherrill@oarcorp.com>
To: Joseph Myers <joseph@codesourcery.com>,
	Segher Boessenkool <segher@kernel.crashing.org>
Cc: Andrew Jenner <andrew@codesourcery.com>,
	David Edelsohn <dje.gcc@gmail.com>,
	GCC Development <gcc@gcc.gnu.org>,
	Olivier Hainque <hainque@adacore.com>,
	Sandra Loosemore <sandra@codesourcery.com>,
	Arnaud Charlet <charlet@adacore.com>,
	Joel Brobecker <brobecker@adacore.com>
Subject: Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
Date: Mon, 01 May 2017 15:56:00 -0000	[thread overview]
Message-ID: <672bb7fd-e2dd-85a4-ad05-c6cce47b7223@oarcorp.com> (raw)
In-Reply-To: <e219ea36-68a8-c122-f678-d50ae7b08efb@oarcorp.com>



On 5/1/2017 10:47 AM, Joel Sherrill wrote:
>
>
> On 5/1/2017 5:48 AM, Joseph Myers wrote:
>> On Sat, 29 Apr 2017, Segher Boessenkool wrote:
>>
>>> We also still have to agree on the target triples for the new port.
>>> If you have any thoughts on this, I'd love to hear them.
>>
>> It seems fairly obvious that the powerpc-*-eabispe* and
>> powerpc*-*-linux*spe* triples should continue to work while being mapped
>> to the new CPU port.  It's less obvious what triples should be used for
>> SPE versions of other SPE-supporting configurations such as
>> powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*.
>
> powerpc-*-rtemsspe* would be OK.
>
> powerpc-*-eabisimspe* is pretty ugly though.


After I sent this, I saw in another response that powerpcspe*-*-*
was proposed. Is that clearer?

For rtems, we already used versioned triplets. powerpc-rtems4.12
for example. owerpcspe-rtems4.12 seems more correct because spe
is part of the CPU architecture.

Otherwise, would it be powerpc-rtems4.12spe or powerpc-rtemsspe4.12.
Both of those are pretty ugly and confuse the third part.

> It is obvious but if powerpc-*-XXXspe* is the pattern, then the
> spe cases need to be above in all configure switches. I hate to
> mention it but a fair number of odd RTEMS issues turn out to be
> from inadvertent side-effects when cleaning up configure switches.
>
>> Some testcases will be applicable to both ports, some to only one.
>>
>> Maintainers of each port should of course watch the other port for changes
>> that should be carried across, even if we believe, as has been stated in
>> this discussion, that the parts of the code that would be present in both
>> ports are stable and very rarely change.
>>
>
> --joel
>

--joel

  reply	other threads:[~2017-05-01 15:56 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-14  3:08 Obsolete powerpc*-*-*spe* Segher Boessenkool
2017-02-14  6:32 ` Jeff Law
2017-02-14 11:55 ` Sebastian Huber
2017-02-14 14:09   ` David Brown
2017-02-14 14:26     ` Sebastian Huber
2017-02-14 14:49       ` Segher Boessenkool
2017-02-16  5:28         ` Patrick Oppenlander
2017-02-16 17:00           ` Segher Boessenkool
2017-02-16  5:43         ` Patrick Oppenlander
2017-02-14 13:45 ` David Edelsohn
2017-02-15  0:06   ` PowerPC -many Alan Modra
2017-02-15  0:38     ` Segher Boessenkool
2017-02-15  1:04       ` Alan Modra
2017-02-15  6:00         ` Jakub Jelinek
2017-02-15 12:35           ` David Edelsohn
2017-02-15  3:03     ` Peter Bergner
2017-02-14 16:04 ` Obsolete powerpc*-*-*spe* Olivier Hainque
2017-02-16 21:49 ` Sandra Loosemore
2017-02-16 22:19   ` Segher Boessenkool
2017-02-16 23:54     ` Sandra Loosemore
2017-02-17  0:11       ` David Edelsohn
2017-02-17  9:19         ` Richard Biener
2017-02-17  9:38           ` Janne Blomqvist
2017-02-17 14:12           ` Nathan Sidwell
2017-02-20 20:08         ` Olivier Hainque
2017-02-21 16:14           ` David Edelsohn
2017-02-23  9:23             ` Olivier Hainque
2017-02-23  9:36               ` Arnaud Charlet
2017-03-13 18:02             ` Andrew Jenner
2017-03-15 10:01               ` Olivier Hainque
2017-03-15 14:26                 ` Segher Boessenkool
2017-03-15 16:16                   ` Olivier Hainque
2017-03-15 17:13                   ` Sandra Loosemore
2017-03-15 17:36                     ` Segher Boessenkool
2017-03-15 17:45                     ` David Edelsohn
2017-03-15 21:43                   ` Andrew Jenner
2017-03-16 19:25                     ` Segher Boessenkool
2017-03-16 20:38                       ` Andrew Jenner
2017-03-16 21:11                         ` Segher Boessenkool
2017-03-16 21:16                           ` Andrew Jenner
2017-03-17  7:58                             ` Sebastian Huber
2017-03-30 16:41                     ` Maciej W. Rozycki
2017-04-26  9:19               ` PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*) Andrew Jenner
2017-04-28 23:15                 ` Segher Boessenkool
2017-04-29 16:28                   ` Jeff Law
2017-05-01 10:48                   ` Joseph Myers
2017-05-01 11:12                     ` Segher Boessenkool
2017-05-01 11:31                       ` Joseph Myers
2017-05-01 11:45                         ` Segher Boessenkool
2017-05-01 15:47                     ` Joel Sherrill
2017-05-01 15:56                       ` Joel Sherrill [this message]
2017-05-01 16:11                         ` Segher Boessenkool
2017-05-01 16:12                       ` Arnaud Charlet
2017-05-01 16:25                         ` Segher Boessenkool

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=672bb7fd-e2dd-85a4-ad05-c6cce47b7223@oarcorp.com \
    --to=joel.sherrill@oarcorp.com \
    --cc=andrew@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=charlet@adacore.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hainque@adacore.com \
    --cc=joseph@codesourcery.com \
    --cc=sandra@codesourcery.com \
    --cc=segher@kernel.crashing.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).