This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Fix other/44566
On Sat, 26 Jun 2010, Joern Rennecke wrote:
> Quoting "Joseph S. Myers" <joseph@codesourcery.com>:
>
> > On Sat, 26 Jun 2010, Joern Rennecke wrote:
> > > So at least the flags that potentially change program behaviour must be
> > > global, since they represent the user's choices in the context of the
> > > selected main target.
> >
> > Flags affecting semantics like that should be used to affect the GIMPLE
> > generated rather than global flags being used later in the optimizers.
>
> But still, the place where flag_finite_math_only is manipulated by the sh
> is OVERRIDE_OPTIONS (or targetm.target_option_override if my hookizing
> patch gets approved), so a change to that logic is needed if the SH
> is to be allowed as a secondary target.
The hook would, given my changes, modify an options structure to which a
pointer is passed. Instead of changing the individual hooks, if you don't
want secondary targets changing semantic flags the target-independent code
should save and restore those flags in the relevant structure before/after
calling the hook for those targets (or some equivalent behavior). Indeed
you don't need my changes in order to save and restore some known set of
semantic flags....
> So, unless you want have rtl codes to encode possible presence of NaNs,
> and hack places like cse.c and combine.c to propagate this into different
> kinds of comparison / scc codes, and hack all targets to digest this, we
That's the natural conclusion for proper representation of such things as
the FENV_ACCESS pragma, yes - track the information on individual
operations through both GIMPLE and RTL. Per-function representation is
simply an easier intermediate approach.
--
Joseph S. Myers
joseph@codesourcery.com