|
From: | Paolo Bonzini |
Subject: | Re: [PATCH 3/4] Avoid a stupid 'const object should have initializer' warning |
Date: | Fri, 30 Apr 2010 10:30:28 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.4 |
On 04/28/2010 12:00 AM, Bruno Haible wrote:
Andreas Gruenbacher wrote:diff --git a/lib/getdate.y b/lib/getdate.y index 445865b..dcfe3cc 100644 --- a/lib/getdate.y +++ b/lib/getdate.y @@ -152,7 +152,7 @@ typedef struct #if HAVE_COMPOUND_LITERALS # define RELATIVE_TIME_0 ((relative_time) { 0, 0, 0, 0, 0, 0, 0 }) #else -static relative_time const RELATIVE_TIME_0; +static relative_time const RELATIVE_TIME_0 = { 0, 0, 0, 0, 0, 0, 0 }; #endif /* Information passed to and from the parser. */This patch makes the code less efficient: An allocation of n bytes in the 'data' segment causes n bytes to be read from disk. An allocation of n bytes in the 'bss' segment does not.
Recent and not-so-recent GCC (the behavior was introduced in 3.3) put a zero initializer in bss. The difference between "int f;" and "int f = 0;" is only whether the resulting symbol is "common" or not:
$ cat f.c int f; int g = 0; int h = 1; $ gcc f.c -o - -S .file "f.c" .comm f,4,4 .globl g .bss .align 4 .type g, @object .size g, 4 g: .zero 4 .globl h .data .align 4 .type h, @object .size h, 4 h: .long 1... which doesn't even matter for static objects so the "= 0" doesn't even change the generated assembly:
$ cat g.c static int f; static int i = 0; int x(){return i+f;} /* avoid GCC optimizing out the variables */ int y(int j){return i=f=j;} $ gcc g.c -o - -S .file "f.c" [snip] .local i .comm i,4,4 .local f .comm f,4,4 Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |