https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to doug mcilroy from comment #9)
> If I can play with the assembler to accomplish the desired result, why can't
> gcc? I notice that gcc is smart enough already to produce uninitialized
> space for
> char a[10000000] = "\0";
> int main(){ return 0; }
> It even does so for a string of 1000 \0's. But not for one x.
Please reread above. You can accomplish the (only sometimes) desirable result
only if you change both the assembler and linker script (and the latter for
each single such variable). GCC emits assembler, in which it can't be solved.
> It's lamentable that a common feature--partially initialized arrays--can
> lead to stratospheric compile time.
I don't see anything catastrophic on Linux.
$ cat pr93278.c
char a[4000000000] = "x";
int main(){ return 0; }
$ time gcc -O2 -o pr93278{,.c} -mcmodel=medium
real 0m12.409s
user 0m6.973s
sys 0m5.414s
$ readelf -Wa pr93278 | grep ee6b
[23] .ldata PROGBITS 0000000000406020 003020 ee6b2800 00
WAl 0 0 32
[24] .comment PROGBITS 0000000000000000 ee6b5820 000058 01
MS 0 0 1
[25] .gnu.build.attributes NOTE 00000000eeab8820 ee6b5878 000558
00 0 0 4
[26] .symtab SYMTAB 0000000000000000 ee6b5dd0 000678 18
27 51 8
[27] .strtab STRTAB 0000000000000000 ee6b6448 000285 00
0 0 1
[28] .shstrtab STRTAB 0000000000000000 ee6b66cd 000116 00
0 0 1
LOAD 0x003020 0x0000000000406020 0x0000000000406020 0xee6b2800
0xee6b2800 RW 0x1000
64: 0000000000406020 0xee6b2800 OBJECT GLOBAL DEFAULT 23 a
