From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26382 invoked by alias); 13 Aug 2010 20:11:45 -0000 Received: (qmail 26252 invoked by uid 48); 13 Aug 2010 20:11:31 -0000 Date: Fri, 13 Aug 2010 20:11:00 -0000 Message-ID: <20100813201131.26251.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/25140] aliases, including weakref, break alias analysis In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "bigotp at acm dot org" 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: 2010-08/txt/msg01134.txt.bz2 ------- Comment #11 from bigotp at acm dot org 2010-08-13 20:11 ------- (In reply to comment #9) > (In reply to comment #8) > > Hm, I only can see references to "symbol" not to either function or variable > > declaration in the documentation. Can you cite the part that makes you think > > it restricts the use to functions? > > It's documented in the section on function attributes, but not listed in the > section on variable attributes. Compare 'deprecated' or 'weak', which are > listed in both places. Is there any intention to restrict use of weakref to functions? It seems to be exactly what I want to use to allow a translation unit to reference a memory-mapped register by its vendor-defined name, while not making that name a global symbol that impacts other translation units, nor providing the actual register address until the final link phase: static volatile uint16_t P1IN __attribute((weakref("__P1IN"))); uint16_t c3 () { return P1IN; } with __P1IN = 0x0020; in a linker script. Other approaches seem to require that I have a definition for __P1IN available at the time the object file is generated, which means I'd have a potential for conflict if a different object file happened to include a header that gave the register a different address; or that I use: volatile uint16_t P1IN __attribute((weak)); uint16_t c3 () { return P1IN; } which clutters the namespace. Heck, I'll submit a patch to gcc/doc/extend.texi that explicitly allows use of weakref on variables if that'd help. -- bigotp at acm dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bigotp at acm dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140