Re: basic-improvements merge status

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka wrote:-
> 
> > > 
> > > 	Yes, it appears to be due to the builtins.def changes by Jan which
> > > assumes that all of those functions natively are available on every
> > > target.  One cannot make that assumption.  Testing for the existence of
> > > those functions on the target is not easy.
> > 
> > I noticed that already and there is patch waiting for that.  So hope it
> > will get reviewed soon.
> > I am not quite sure how to deal with this (whether we can autoconfigure
> > on whether runtime does have them or not).  At the moment I do the
> > transformation only when -std=c99 or gnu99 is specified when the
> > transformation is valid as the standard requires these functions.
> 
> But those switches are statements about what features the compiler
> should accept, and compiler semantics.  They say nothing about the
> library conformance of the target to C99, IMO.
The patch is more about adding infrastructure to specify about builtin
whether compiler can produce it implicitly than about the actual
decision.  I expected the thread open when I sent the patch, so perhaps
it happent now.
I see that doing this transformation is different from the other
decision we make based on language switch and would be happy about the
better alternative.

It is clear that in C99 environment this transformation is valid.
To my surprise it is important one.  In C90 compliant program there is
no other way to write such code and even after that people are still
using it, so the tranformation matches about houndred times in SPEC2000
and even more times in real world 3d programs, like Mesa, Crystal Space
and similar often in internal loops.
I would definitly like to see this enabled by default on Linux, that is
not the case if we conditionalize it by C99.

Honza
> 
> Neil.