From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25306 invoked by alias); 7 Feb 2005 13:40:35 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 25160 invoked by uid 48); 7 Feb 2005 13:40:30 -0000 Date: Mon, 07 Feb 2005 22:03:00 -0000 From: "peter at p12n dot org" To: gcc-bugs@gcc.gnu.org Message-ID: <20050207134028.19805.peter@p12n.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug middle-end/19805] New: sub-optimal initialisation of array on the stack X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg00422.txt.bz2 List-Id: gcc version 4.0.0 20050110 (experimental) - from Debian 'gcc-snapshot' package. [Thread model: posix. I doubt configure flags are important here.] gcc produces quite poor code when initialising a stack char[] to an empty string. This is at any optimisation level, including -Os. extern void foo(char *); void bar(void) { char x[65536] = ""; foo(x); } (foo() prevents x[] from being optimised away.) This generates a 64 kB chunk of nulls in .rodata, then proceeds to copy in the first byte of this region, ignore the other 65535 bytes, and call memset. Similar story if I initialise to a non-empty string - an inline memcpy followed by a memset, and still a huge unneeded block of zeroes. Simple workaround: initialise the array to {} instead of "". The generated code in that case looks much better - just a memset, no .rodata at all. There's still the question of why not inline the memset, since the array is known to be nicely aligned. (My real code didn't need 65536 bytes of stack - that was just 'reductio ad absurdum' to demonstrate that gcc doesn't get any smarter as the useless chunk of .rodata gets larger.) -- Summary: sub-optimal initialisation of array on the stack Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter at p12n dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19805