From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20191 invoked by alias); 5 Oct 2006 19:29:56 -0000 Received: (qmail 20139 invoked by uid 48); 5 Oct 2006 19:29:47 -0000 Date: Thu, 05 Oct 2006 19:29:00 -0000 Message-ID: <20061005192947.20137.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "stsp at users dot sourceforge dot net" 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 X-SW-Source: 2006-10/txt/msg00432.txt.bz2 List-Id: ------- Comment #25 from stsp at users dot sourceforge dot net 2006-10-05 19:29 ------- > "i"(&var) of course can't work with -fpic, I tried it on an x86_64 today, and it seems to work. If I use -m32, then it doesn't. Why? > it would only work at the expense > of text relocations, but those are not allowed on some architectures and > highly undesirable on the rest of architectures. Is this to always keep the .text section r/o? > In position independent code, > &var typically means you need to load that address from global offset table So, as I understand your answer, the relocation at dynamic-link time is not implemented at all (even on the arches where it is possible)? > into a register, and a register of course can't satisfy "i" constraint. Thanks for the hint. It looks like the things like "a"(&var) do work with -fpic, which should be fine for my needs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200