[PATCH] Add word-sized conversion functions to libgcc2

Roger Sayle roger@eyesopen.com
Thu May 18 14:42:00 GMT 2006


On Thu, 18 May 2006, Richard Sandiford wrote:
> Your question appears to be whether libgcc2.c should have the smarts to
> work out on its own how to implement fixunsdfdi, or whether it relies on
> external information (provided in my patch by libgcc.mk).  I tend to
> prefer the latter because shell scripts are more expressive than the C
> preprocessor.  If we put the logic in libgcc2.c itself, then I think
> every function defined by libgcc2.c would have something similar the
> #ifdef blocks in your patch:
>
>     #ifdef L_fixunsdfdi2
>       #define TEMPLATE_fixunsdfDD2
>       #define DDSIZE 64
>     #endif
>
> This would have to be repeated for {fix,fixuns,float,floatun}x{sf,df,tf,xf};
> i.e. 16 combinations, and that's only a subset of the functions that
> libgcc2.c provides.  Getting help from an external shell script allows
> us to use things like "for" loops to do the mechanical stuff.

Re: C macros vs. shell scripts.  I'm personally a fan of the libgfortran
approach that instantiates the implementations "a priori", instead of
complicating the Makefile/build system.  You're right that shell
scripts are more expressive than C macros, but a maintainer mode
generator script/program can be even more expressive still.

There are approximately 256 entry points in libgcc, so such a system
is manageable, and allows the dependencies/logic to be clearly expressed
in the resulting Makefile.  After all it is the complexity of the current
libgcc.mk build system which is the underlying cause of this problem.

It's also the case that GCC's __attribute__(mode) dramatically simplifies
this process, which wasn't available when libgcc was first designed and
implemented.

p.s. Many thanks to Richard for tackling this thorny issue.

Roger
--



More information about the Gcc-patches mailing list