https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70039
Bug ID: 70039 Summary: Data placed into rodata that could be encoded as immediates Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andrew.burgess at embecosm dot com Target Milestone: --- Created attachment 37840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37840&action=edit An example of this behaviour Compiling the attached file with gcc from SVN 1-Mar-2016 on x86-64 GNU/Linux: gcc -O2 -Wall -Wextra -o fill.s -S fill.i Here's some of the source: void fill_from_array (char * d) { static const char a[] = { 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', }; memcpy (d, a, 20); } void fill_from_string (char * d) { static const char a[] = "abcdefghijklmnopqrstuvwxyz"; memcpy (d, a, 20); } in the generated assembler of fill_from_string the data is written to the destination pointer (d) as constants, like this: movabsq $7523094288207667809, %rax movl $1953722993, 16(%rdi) movq %rax, (%rdi) movabsq $8101815670912281193, %rax movq %rax, 8(%rdi) However, in the fill_from_array case the array data is held in the .rodata section, loaded, and then stored to the destination. My expectation would have been that the code generated in each case would have been identical.