From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: Richard Henderson <rth@redhat.com>,
Anatoly Sokolov <aesok@post.ru>,
gcc-patches@gcc.gnu.org, ebotcazou@libertysurf.fr
Subject: Re: Completing toplevel libgcc move (Was: Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P)
Date: Thu, 26 May 2011 13:24:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1105261209220.22481@digraph.polyomino.org.uk> (raw)
In-Reply-To: <yddpqn5n2lt.fsf_-_@manam.CeBiTec.Uni-Bielefeld.DE>
On Thu, 26 May 2011, Rainer Orth wrote:
> But doesn't this mean that e.g. MD_UNWIND_SUPPORT can only be moved to
> libgcc/config for all targets together? How can you poison the macro
> when a single target using it is left behind in gcc/config?
Nothing about the libgcc_tm.h implementation stops you moving a macro
(that is not, in fact, used on the host) for only some targets if you
don't poison it. But I do think moving it for all targets together, and
poisoning it, is much better.
> To actually test such a move, one had to setup complete
> cross-environments for every affected target, which is way beyond what I
> have the time and inclination to do. This would mean that even targets
> where the toplevel libgcc move could be completed and the maintainers
> are motivated to do so are stalled until all other related ones are
> done. Doesn't seem highly desirable to me.
Well, no, you post the patch (I'd guess all thirty or so target-only
macros could be moved in a few hours, but moving them in smaller groups
might be easier), test on the targets you can readily test on (building
just cc1 and xgcc for the others), invite target maintainers (CC:ed) to
test for other targets and seek approval to commit in maybe a week in the
absence of problem reports from target maintainers.
I think completing the move for a particular macro is more meaningful, and
has a better way to ensure the move doesn't regress, than completing it
for a particular target.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2011-05-26 12:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-27 18:43 [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P Anatoly Sokolov
2011-04-28 16:18 ` Richard Henderson
2011-05-03 19:07 ` Rainer Orth
2011-05-03 19:18 ` Joseph S. Myers
2011-05-04 11:54 ` Rainer Orth
2011-05-04 12:02 ` Joseph S. Myers
2011-05-26 11:49 ` Completing toplevel libgcc move (Was: Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P) Rainer Orth
2011-05-26 13:24 ` Joseph S. Myers [this message]
2011-05-26 13:31 ` Completing toplevel libgcc move Rainer Orth
2011-05-04 17:44 ` Re[2]: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P Anatoly Sokolov
2011-05-04 17:44 ` Rainer Orth
2011-05-05 9:15 ` Rainer Orth
2011-05-13 7:02 ` Re[2]: " Anatoly Sokolov
2011-05-19 13:00 ` Rainer Orth
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=Pine.LNX.4.64.1105261209220.22481@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=aesok@post.ru \
--cc=ebotcazou@libertysurf.fr \
--cc=gcc-patches@gcc.gnu.org \
--cc=ro@CeBiTec.Uni-Bielefeld.DE \
--cc=rth@redhat.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).