This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ada, build] host/target configuration
- From: Olivier Hainque <hainque at adacore dot com>
- To: Arnaud Charlet <charlet at adacore dot com>
- Cc: Olivier Hainque <hainque at adacore dot com>, Paolo Bonzini <bonzini at gnu dot org>, Thomas Schwinge <thomas at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>, ebotcazou at adacore dot com, obry at adacore dot com, dj at redhat dot com, neroden at gcc dot gnu dot org, aoliva at redhat dot com, Ralf dot Wildenhues at gmx dot de
- Date: Fri, 31 May 2013 15:41:25 +0200
- Subject: Re: [ada, build] host/target configuration
- References: <yddli7p95zm dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE> <87txlnlg0z dot fsf at kepler dot schwinge dot homeip dot net> <87zjvejc02 dot fsf at kepler dot schwinge dot homeip dot net> <51A60EF2 dot 5000605 at gnu dot org> <20130530134425 dot GA15756 at adacore dot com> <E42B5EE6-E7F0-4AC3-AAB0-7E7E0D050A01 at adacore dot com>
On May 30, 2013, at 23:08 , Olivier Hainque <hainque@adacore.com> wrote:
> The idea of the "target->target_alias" change in gcc-interface/Makefile.in
> for Ada was to let us still distinguish for the purpose of the Ada RTSes in
> particular.
>
> This happens to be significant in a limited amount of cases only.
A very limited number of cases actually.
* e500v? canonicalized as powerpc (in our tree), which is a
non-issue because the pairs are all identical.
* leon vs sparc-leon maybe, I'm not so sure but this should be
straightforward to adjust in any case
* vxworksmils canonicalized into vxworksae
A safe and simple approach to this issue would be to
- revert to our former computations, based on target and
not target_alias. Revert the subsequent adjustments as
well.
- Remove the pointless and confusing references to e500,
adjusting comments to indicate that e500 is canonicalized
into powerpc
- Use target_alias explicitly just at the points where
we know that we need to depart from the canonical name
The proposed idea of using the configure computed names instead of doing our
own computations is interesting. It's sort of orthogonal and seems potentially
disruptive as well, so I'd defer to a later moment.