From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58074 invoked by alias); 8 Sep 2015 07:18:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 58064 invoked by uid 89); 8 Sep 2015 07:18:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: mo4-p00-ob.smtp.rzone.de Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de) (81.169.146.217) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 08 Sep 2015 07:18:35 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZE+TiTS5oCK5h4ZKng== X-RZG-CLASS-ID: mo00 Received: from [192.168.2.100] (dslb-084-058-214-085.084.058.pools.vodafone-ip.de [84.58.214.85]) by smtp.strato.de (RZmta 37.12 DYNA|AUTH) with ESMTPSA id w06a6fr887IVS1N (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 8 Sep 2015 09:18:31 +0200 (CEST) Message-ID: <55EE8B53.6040005@gjlay.de> Date: Tue, 08 Sep 2015 08:03:00 -0000 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Senthil Kumar Selvaraj CC: gcc-patches@gcc.gnu.org, chertykov@gmail.com Subject: Re: [Patch, avr] Fix PR65210 References: <20150902075154.GB1047@jaguar.corp.atmel.com> In-Reply-To: <20150902075154.GB1047@jaguar.corp.atmel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00469.txt.bz2 Senthil Kumar Selvaraj schrieb: > This (rather trivial) patch fixes PR65210. The ICE happens because code > wasn't handling io_low attribute where it is supposed to. Hi Senthil, could you line out for what these new attributes are good for? The Compiler just maps the argument to a compile-time const, so the attributes do the same as a cast to a volatile address. Except that the user must know in advance what I/O Region is the right one. Supporting similar RELOCs for io* doesn't make hardly any sense, or are there Plans to add respective RELOCs (and ones for bitfields)? Thanks, Johann