This is the mail archive of the 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: [PING]: Use MPFR for Bessel functions j0, j1 and jn

On 5/9/07, Kaveh R. GHAZI <> wrote:
On Tue, 8 May 2007, Richard Guenther wrote:

> On 5/8/07, Kaveh R. GHAZI <> wrote:
> >
> > PING: Use MPFR for Bessel functions j0, j1 and jn
> >
> >
> >
> > Didn't put it in the patch queue the first time around.
> > :ADDPATCH middle-end:
> I don't like this conditionalizing very much.  I'd rather require us that
> mpfr version once it is available.


This requirement puts me in an impossible position.  If you insist on it
you're effectively blocking all of my recent patches because even when
mpfr-2.3.0 is released, there is opposition to requiring later MPFR
versions to bootstrap GCC.  Surely you're aware of this sentiment among
the community, I tried updating the MPFR version a micro level to 2.2.1
and you were one of the first to object:

Other people felt the same way:

Some people objected to the timing, others object to the upgrade under any
circumstances.  I can see the reasoning behind not requiring an upgrade,
we don't want to make it too hard to bootstrap C.  It seems to be the will
of the majority for now, so that's where we stand.

However in using the MPFR version conditionals, it allows me to clear my
queue of patches, and the new functionality is there to get wider testing.
So it's ready to roll once the mpfr-2.3.0 release is cut and more people
start to use it in conjunction with gcc-4.3.  Note: before we required
mpfr-2.2.0, the fortran frontend made heavy use of conditionalizing like
this, so there is precedent for this when we decide to support older MPFR
versions but take advantage of new ones as they become released:

I very well understand this. Maybe I should elaborate a bit on my concerns about conditionalizing optimization on available tools at compiler build time. I think doing so will put us in the unfortunate situation to need the same host tools a bug reporter was using to reproduce a problem (I remember patches to show mpfr and gmp version used with --version, what happened to them?).

> Though I also don't see that much value in evaluating these functions at
> compile-time ;)
> Richard.

Well you probably don't use bessel functions in your daily routine.
That's not a reason to oppose it.  I've spent a lot of time working with
the MPFR authors to get new features into MPFR 2.3.0 that would be useful
for evaluating the remaining C99 math functions from GCC.  You're not
being respectful of my time or theirs with your dismissal of our efforts.

I'm sorry if my reply sounded like a dismissal, I'm not going to block the patch if another maintainer thinks the version-dependence is ok. Do you have an idea on when mpfr 2.3.0 is about to be released?

If there is a way to bridge our differences I would be willing to make
modifications to my patch to address your concerns while still getting the
stuff installed now.

From a technical standpoint the patch is ok, though...

For example, would it help if I xfailed the testcase until mpfr-2.3.0 is

xfailing the testcases is a good idea.

That kind of change makes sense to me in hindsight.  And that's
the kind of constructive feedback I would seek from a maintainer like

Would you please reconsider and offer some path forward?

I see two paths forward, get another maintainer approve the patch (I'm CCing ian here) or wait at least until mpfr 2.3.0 is released. (Or try again importing mpfr sources into the gcc tree, which would solve all my concerns as well)

Sorry if this isn't exactly what you expect from me ;)


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