From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24674 invoked by alias); 26 May 2012 20:23:08 -0000 Received: (qmail 24662 invoked by uid 22791); 26 May 2012 20:23:07 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 May 2012 20:22:55 +0000 From: "jwatte at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/53493] [4.7 regression] Compiling with -Os excludes PROGMEM array from generated object file (__attribute__((__progmem__))) Date: Sat, 26 May 2012 20:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jwatte at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Resolution Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg02565.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53493 jwatte at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | --- Comment #5 from jwatte at gmail dot com 2012-05-26 20:22:55 UTC --- "it has to be the same in each translational unit that it is used" That doesn't mean it has to be /deleted/. An argument can be made that deleting it from the compilation unit is not very useful. If I remember correctly, the source of vague linkage was for allowing for the merging of inline template instantiations (rather than explicitly. Anyway, including the forward declaration in the definition translation unit as well as the using translation unit does make it work, so it works around this problem. Whether the behavior is useful or correct, I don't want to enter into an argument about.