This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: target_flags
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: DJ Delorie <dj at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 10 Mar 2003 17:41:50 -0800
- Subject: Re: target_flags
- References: <26248454-5362-11D7-A309-003065A77310@apple.com>
Mike Stump <mrs at apple dot com> writes:
> Yes, it would provide greater flexibility in solving problems like
> mine. I don't demand it yet, as I really need it for our 3.3 tree,
> and I don't think 3.3 should take on this level of change at this
> point. In 3.4, there are enough spare flags again, right now anyway,
> that I can use them directly without the need for the above patch.
I'm pretty sure 3.3 had target_flags_explicit, which is the reason why
there's more room in the 3.4 rs6000 target_flags. You could backport
that patch in your local tree.
> Maybe the change would be less invasive if instead of replacing
> TARGET_SWITCHES, we complemented it with TARGET_SWITCHES2... This
> would remove the need to redo all existing ports. 90% of ports will
> never need the extra functionality...
> This type of change would also make it more palatable for 3.3.
Ugh. Yeah, it's less invasive now, but it's not a good long-term
solution.
> For now, I will just employ the status quo solution that David
> pointed out. I just don't want people to give me grief later, if I
> used that solution in a gcc submission. :-(
Since that approach is already being used in rs6000.c I don't see any
harm in using it for more stuff there. And note that DJ's proposed
patch promotes that hack to a proper feature.
zw