This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: target_flags


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]