From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15183 invoked by alias); 19 Feb 2013 17:59:05 -0000 Received: (qmail 14810 invoked by uid 48); 19 Feb 2013 17:58:37 -0000 From: "gjl at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/56263] [avr] Provide strict address-space checking Date: Tue, 19 Feb 2013 17:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: gjl at gcc dot gnu.org X-Bugzilla-Status: SUSPENDED X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: gjl at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: 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: 2013-02/txt/msg01968.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263 --- Comment #4 from Georg-Johann Lay 2013-02-19 17:58:36 UTC --- (In reply to comment #3) > (In reply to comment #2) > >> This cannot work because ISO/IEC TR18037 forces these literals into generic >> space. >> > > ISO/IEC TR18037 > 5.1.2 Address-space type qualifiers: > > If the type of an object is qualified by an address space name, the > object is allocated in the specified address space; otherwise, the object is > allocated in the generic address space. > > I just re-read the standard. > I could not find any reason not permitted to place the data in __flash address > space in that case: > > const char __flash* const __flash names[] = {"flash_str1", "flash_str2"}; The initializer at the righ side has type "const char *const[]" thus names[] is located in flash because names[] is qualified __flash. However, the Embedded C does not say anything about the literals like "flash_str1" of type "const char*". Therefore, vanilla C applies which says that these literals go into generic space. > IAR compilers it does, and that hinders gcc do the same? > I think it's an easy misunderstanding, preventing common sense ... It's a shortcoming in the Embedded C paper and I agree with you that more elaborate Embedded C paper would be more convenient here. There are two ways out of this: 1) Extend the Embedded C paper and propose an addendum to the ISO WG14. 2) Implement this extension no matter whether Embedded C comes with this extension. Find someone who implements this extension, supports it and makes sure there are no conflicts with the vanilla Embedded C. Notice that with the extension, in the following example "init" would be located in flash but "assign" would still be located in RAM. void f_init (void) { const __flash char *str = "init"; } void f_assign (void) { const __flash char *str; str = "assign"; }