[RFC Patch]: Implement remainder() as built-in function [PR fortran/24518]

[Kai Henningsen]

On Wed, Oct 25, 2006 at 05:07:54PM -0700, Mike Stump wrote:
> On Oct 25, 2006, at 4:38 PM, Paul Brook wrote:
> >It is also possible to have multibs based on options that do not  
> >effect code generation. e.g. in the CodeSourcery toolchains we add a  
> >uclibc multilib to our linux toolchains
> 
> Ah, I get what you mean now, excellent point for people to consider.   
> Thinking about that some more, internally we have -isysroot and we use  
> it to select SDKs, and those SDKs have things like .../usr/include/ 
> stdio.h in them.  An older system has:
> 
> #define stdout  (&__sF[1])
> 
> and newer systems have:
> 
> #if __DARWIN_UNIX03
> #define stdin   __stdinp
> #define stdout  __stdoutp
> #define stderr  __stderrp
> #else /* !__DARWIN_UNIX03 */
> #define stdin   (&__sF[0])
> #define stdout  (&__sF[1])
> #define stderr  (&__sF[2])
> #endif /* __DARWIN_UNIX03 */
> 
> Whee...  so, no multilib, but different.  A difference that I could  
> code up, but one that a generic autoconf system would tend to get  
> wrong.  I even missed this in thinking about this for my system.  If  
> done naively, I think it would break SDK builds for me.  :-(
> 
> Thanks for explaining...

Hmm.

There's a possible solution for LTO here. Maybe someone can generalize
it to non-LTO.

LTO *is* supposed to be able to inline after generating the object
files, right?

So:

We'll have a sourcefile builtin_inlines.c approximately as follows:

#include <errno.h>
#include <stdio.h>

inline int __builtin_get_errno(void) { return errno; }
inline void __builtin_set_errno(int _e) { errno = _e; }

inline FILE *__builtin_get_stdout(void) { return stdout; }

// ... and so on

For LTO, automatically compile that file and add it to the set of
objects to link-an-optimize.


Slight problem maybe, you'd want to be sure you have all the compilation
options during LTO so this will generate the correct code.


Also let me point out that it *is* possible to point gcc at a completely
different set of includes and libs from the system one; assuming that
one works just like the other may be unwise, so pre-generating multilibs
may not solve the problem ...


There *is* another option. It's not necessarily nice.

The frontend would need to recognize the point in the program where such
a transformation might be possible, query the preprocessor if it has a
#define, use the expansion or else generate the identifier, and then use
that to compile the equivalent of the above source. The expander, then,
would just check for the definition of the builtin, and only use it if
it is present.