This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC compiler intrinsics
- To: Andy Hanson <andrew_g_hanson at yahoo dot com>
- Subject: Re: GCC compiler intrinsics
- From: Robert Lipe <robertlipe at usa dot net>
- Date: Thu, 4 May 2000 08:15:19 -0500
- Cc: gcc at gcc dot gnu dot org
- References: <002801bfb5b4$920009c0$0600a8c0@topguppy.ick>
Andy Hanson wrote:
> simply shocked. The fact that memset was unresolved, implied that memset
> isn't a compiler intrinsic. I mean, if strcpy is an intrinsic, why the hell
> isn't memset. (I'm using a semi-old version (egcs-2.91.66), so it might be
> an intrinsic in newer versions.)
memset is potentially an intrinsic in the newer versions. But that
doesn't meant the compiler always can/will inline it so there may still
be calls to the libc version.
> Which got me to thinking, now that I am free from relying on VC 6+, and the
> compiler is open sourced, I can finally add my own compiler intrinsics.
> Things like bsf (bit scan forward), or maybe a simple hash function.
GNU C is an ISO C compiler. So I would hope that non-standard functions
_don't_ get inlined by the compiler. Still, you're free to whack on your
local copy as you see fit.
> Now the big question is where to start. I did a little digging through the
> egcs release, and binutils, and I can't seem to see where intrinsics like
> strcpy get processed by the compiler. I did my traditional web search to
They're hidden in 'builtins.c'.