Re: [PATCH] Fix __builtin_printf/all long double builtins

[Mike Stump <mrs at apple dot com>]

On Dec 20, 2005, at 10:53 AM, Andrew Pinski wrote:
> This patch fixes up the builtins for the long double math functions
> and some other builtins (which can take a long double) to be named as
> "function_name$LDBL128".
>
> I could not decide if I should put the functions darwin_patch_builtin
> and rs6000_darwin_long_double_builtins should be put into config/ 
> darwin.c
> or somewhere else.
>
> OK? Bootstrapped and tested on powerpc-darwin with no regressions.

A few points.

First, the mapping should not happen on -m64 compiles (when  
TARGET_64BIT is true).

As Geoff said:

You also need to be sure to test macos_version_min.  If you're  
compiling to target < 10.3.9, then you need to make sure to use the  
original version of at least printf and the other variadic functions.

An example from rs6000/darwin.h:

/* Old versions of Mac OS/Darwin don't have C99 functions available.  */
#undef TARGET_C99_FUNCTIONS
#define TARGET_C99_FUNCTIONS                                    \
  (TARGET_64BIT                                                 \
   || (darwin_macosx_version_min                                \
       && strverscmp (darwin_macosx_version_min, "10.3") >= 0))

so, roughly something like when:

  !TARGET_64BIT
   && (darwin_macosx_version_min
        && strverscmp (darwin_macosx_version_min, "10.3.9") >= 0)

is true, we want to do the mapping for the printf style functions.   
For the rest (the math functions), when

  !TARGET_64BIT

is true, we do the mappings.

You can test with:

@item -mmacosx-version-min=@var{version}
The earliest version of MacOS X that this executable will run on
is @var{version}.  Typical values of @var{version} include @code{10.1},
@code{10.2}, and @code{10.3.9}.

and compare the code gen for sin and printf when compile with C using  
the normal system headers.

I'd expect Geoff will be able to say if I got it right.  Personally,  
I'd test, and double check against what C compiled code does.  There  
is one difference, that I'd expect, the system headers draw the cut  
off at < 10.4, not < 10.3.9.  I think this is ok and is just a  
limitation of how much data we put into a #define for the headers  
from the compiler.

Otherwise, looks good to me.