This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH/RFC] Fix PR19402, __builtin_powi[lf]
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 1 Feb 2005 13:43:31 +0100 (CET)
- Subject: Re: [PATCH/RFC] Fix PR19402, __builtin_powi[lf]
On Mon, 31 Jan 2005, Richard Henderson wrote:
> On Mon, Jan 31, 2005 at 02:12:51PM +0100, Richard Guenther wrote:
> > Any suggestions on how to do it "right" wrt libgcc? I'm sure
> > I got the #ifdefery wrong there and maybe the machine modes.
> > And for sure I don't like the name.
> A better name might be __powi<mode>2. You must edit libgcc-std.ver.
> You'll also have to use the optabs infrastructure to get the proper
> function called from the expander, since there's no longer a 1-1
> correspondence. E.g. TYPE_MODE (double) == TYPE_MODE (long double)
> on quite a lot of platforms.
I'm now doing that - but I wonder how to correctly initialize
the optab for functions with signature FLOAT foo(FLOAT, INT),
as when I initialize the optab with init_floating_libfuncs()
(as we have __powi for all floating modes), I'll get an ICE
in emit_library_call_value_1, at calls.c:3355
because there we check that the second arg is of mode DF, but
the second arg is of course an INT mode. Ugh.
Is there already infrastructure for emitting a call to the
optab with MODE foo(MODE, INT)? I'm currently just using
expand_binop( ... , OPTAB_LIB).
Thanks for any suggestions,
Richard Guenther <richard dot guenther at uni-tuebingen dot de>