Re: [PATCH][fortran] Make cbrt, cexpi and sincos builtins available

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Mon, Jan 01, 2007 at 01:07:28PM +0100, Richard Guenther wrote:
> On 12/15/06, Jerry DeLisle <jvdelisle@verizon.net> wrote:
> >Tobias Burnus wrote:
> >> Let's    *ping*   for Richard.
> >>
> >> with the sincos infrastructure in the middle end (I think all patches
> >> are now in the trunk), this speeds up the Polyhedron fatigue test a lot:
> >> ~28.3s => ~18.3s  (35% faster).
> >>
> >> This can be seen at the page
> >> 
> >http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-fatigue-15.png
> >> of http://www.suse.de/~gcctest/c++bench/polyhedron/
> >> (The patch was applied for one day.)
> >>
> >> Tobias
> >>
> >> Richard Guenther schrieb:
> >>> As $subject says.  The cbrt builtins can be used to expand x**1./3. to
> >>> cbrt, the other two are on-top of the sincos patches.
> >>>
> >>> Bootstrap / regtest running.
> >>>
> >>> Ok if the sincos patch(es) go in?  How can we tell that the target
> >>> supports sincos?  (I guess we would need a configure check for that?)
> >>>
> >
> >It was not clear to me the consequences of the question about needing a
> >configure check.  Has that been addressed?
> 
> No, it has not been addressed.  As far as I see we do not have 
> infrastructure
> in place to have tests on the target system in gcc/ because it wouldn't work
> if we are cross-compiling.  We would need to do a two-stage compile in
> the cross-compiling case as well - first build a cross compiler to be able
> to compile/link target configure tests and then after those tests rebuild.
> 
> So the canonical way of introducing target dependencies in gcc/ is to
> augment the gcc/config/ stuff with target macros/hooks dependent on
> the target system.
> 
> For builtins, the __builtin_* variant is always available even if the target
> does not provide a library implementation (see PR29719 for where this
> causes a problem).
>
> For the bare variant we only
> have a destinction for TARGET_C99_FUNCTIONS - which doesn't help
> in the case of sincos, as that is a (common) extension.  Also
> TARGET_C99_FUNCTIONS is said to be too broad (see PR30181).
> 
> So before going down the route adding TARGET_HAS_SINCOS and
> maybe lots of TARGET_HAS_C99_XYZ - are there better suggestions on
> how to address the problems above?
> 

Richard perhaps I misunderstand your last 3 paragraphs  Are you aware
that if gfortran is built to use a __builtin_* function, then there is
no way to disable this in favor of a library function.  This then means
that the TARGET_* don't apply to gfortran unless the TARGET_* disable
the building of the __builtin_* functions and gfortran is updated to 
honor these macros.

I've also lost track of what needs to be reviewed for the fortran
change due to its dependence on non-fortran changes.  Do you have
a new patch or a pointer to the fortran changes?
-- 
Steve