This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR middle-end/30250: Evaluate lgamma/gamma@compile-time using MPFR
On Wed, 9 May 2007, Joseph S. Myers wrote:
> On Wed, 9 May 2007, Andrew Pinski wrote:
>
> > On 5/9/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> > >
> > > I agree, we need to get rid of all langhooks for LTO. Looking at the
> > > C99 standard
> > > I fail to see that a thing like signgam is set for lgamma (looking at
> > > 7.12.8.3) - it's
> > > in the linux manpage I have, but it doesn't seem to be in the
> > > standard. Can anyone
> > > confirm this part is part of C99?
> >
> > And it is not part of C99, only POSIX/Single UNIX. See
> > http://std.dkuug.dk/JTC1/SC22/WG14/www/C99RationaleV5.10.pdf which
> > talks about this feature and C99 standard.
Yes, I also see here that signgam is part of x/open, not c99:
http://www.opengroup.org/onlinepubs/009695399/functions/lgamma.html
> Not being part of C99 also means it would be incorrect to set this
> variable for -std=c99 - the user could have their own variable with that
> name - so it can only be set for -std=gnu99.
IMHO, setting it for gnu89 would be okay too. Historically, we allow
extension behavior in gnu modes. Though checking what the target libc
does would be the best solution IMHO.
> Abstractly, I think you want a built-in signgam which is a variable
> rather than a function (and is DEF_EXT_LIB_BUILTIN whereas lgamma is
> DEF_C99_BUILTIN) and only set the variable if both built-ins are
> enabled, but I don't know if built-ins being variables rather than
> functions will work at all at present.
Agreed, but only abstractly. There's no infrastructure for builtin
variables so I don't want to invent it just for this. :-)
I'll rework it using Andrew's suggestion for libgcc and see if that's not
too gross.
Thanks for all the feedback,
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu