Hide Forgot
Description of problem: I would like to inline memcpy, strncpy, etc, and they exist in bits/string3.h but no combination of options, DEFINEs or anything else seems to make this happen. Version-Release number of selected component (if applicable): gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) How reproducible: Always Steps to Reproduce: 1. Try simple #include <string.h>, main() { strcpy(x,y } 2. Compile with -S to dump assembly (or check with nm, objdump) 3. Do this with -O3, -O4, various inline options and #defines Actual results: There is always an undefined call to the glibc routine in the object and the call is visible inthe source. Expected results: -O3 or maybe something greater, or optimize for time would replace the call to strcpy with the inlined version. Additional info: This seems to affect both x86_64 and i686 versions. Some version of the str... or mem... functions should be replaced with rep/repz/repnz movsb - and I've tried most. For a specific example: #include <string.h> char x() { char x[20], y[]="hello world"; strcpy(x,y); return x[0]; } gcc -O4 stringtest.c -S -o stringtest.S .file "stringtest.c" .text .p2align 4,,15 .globl x .type x, @function x: pushl %ebp movl %esp, %ebp subl $56, %esp leal -20(%ebp), %eax movl %eax, 4(%esp) leal -40(%ebp), %eax movl $1819043176, -20(%ebp) movl $1870078063, -16(%ebp) movl $6581362, -12(%ebp) movl %eax, (%esp) call strcpy <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< movzbl -40(%ebp), %eax leave ret .size x, .-x .ident "GCC: (GNU) 4.5.1 20100924 (Red Hat 4.5.1-4)" .section .note.GNU-stack,"",@progbits
Why do you think expanding it inline is beneficial? GCC often expands memcpy inline, or even strcpy when it can figure out the string length (e.g. if you use const char *y="hello world"; above instead of char y[] which definitely isn't a good idea). For unknown lengths, though, out of line strcpy can do much better than an inline version, especially with recent glibcs where there are several strcpy implementations, choosen at runtime according to cpuid.
Why do you think an example that merely illustrates the problem is representative of what I'm really trying to do? I have something with lots of variable sized strings and buffers and they are sometimes large, sometimes not and this is designed for an embedded application so it will be really hard for it to change architecture at runtime. Not having glibc linked might help too since I may end up statically linking it. I have few if any calls, but the strings are the largest exception. And it might be enclosed in something like a semaphore or might have other special handling that I want to see and have immutable whatever ends up handling the function. I may ultimately inline or not, but it should be my design decision. If most of the lengths are small on average I probably will want to inline. The compiler doesn't have a --psychic-predict option so I need to tell it. I avoid the call and stack overhead as well as the register shuffling. And it should be irrelevant - I want to inline for whatever reason, there are bits that seem to allow for inlining, but there is no combination of settings that will cause it to actually happen. If it cannot inline by design, then consider this a bug report about the junkyard /usr/include stuff that is all stupid since it can't ever work, so why leave it there. If it can inline, tell me how. If it should be able to inline, but can't for other reasons, then it is a real bug as I've reported it. If this is a WONTFIX, please label it as such, not NOTABUG. If I'm turning on options that inline, there are inlining versions in the headers, and the rest, and it doesn't inline, then it is a bug. Or indicate some other appropriate resolution or maybe fix it. Or update the documentation to clearly state that it will never inline string functions no matter what other bits of the text say about optimization where it indicates these would be inlined. If pressing a button on a GUI program didn't do anything but should, it wouldn't be "NOTABUG" with a terse note "why do you want to push the button anyway? You don't really need it". I am pressing the equivalent of an "inline" button but not getting inlines.
Thank you for your bug report. We are sorry, but the Fedora Project is no longer releasing bug fixes or any other updates for this version of Fedora. This bug will be set to CLOSED:WONTFIX to reflect this, but please reopen it if the problem persists after upgrading to the latest version of Fedora, which is available from: http://fedoraproject.org/get-fedora -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers