From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18897 invoked by alias); 1 Oct 2003 10:16:33 -0000 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 Received: (qmail 18890 invoked by uid 48); 1 Oct 2003 10:16:32 -0000 Date: Wed, 01 Oct 2003 10:16:00 -0000 Message-ID: <20031001101632.18889.qmail@sources.redhat.com> From: "rearnsha at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20030706115750.11442.debian-gcc@lists.debian.org> References: <20030706115750.11442.debian-gcc@lists.debian.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/11442] [3.3 regression] [arm] invalid assembler on arm X-Bugzilla-Reason: CC X-SW-Source: 2003-10/txt/msg00051.txt.bz2 List-Id: PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11442 ------- Additional Comments From rearnsha at gcc dot gnu dot org 2003-10-01 10:16 ------- > Is this something ARM specific? I can't find anything in the manual > about it. If it's a general statement, we can also close 12108. Not specifically. It applies to any port which relies on accurate tracking of the size of instructions generated (sh spings to mind here). In the ARM case we have to do this because of the limited range of a pc-relative load, which means that constants have to split into sub-pools that are reachable by a single instruction. 12108 is similar, but subtly different. In that case (as I understand it from a quick scan) the compiler is trying to suppress an ASM statement by the use of a special instruction which will cause the following instruction to not be executed (or only executed under specific conditions). In this case the compiler must know that the asm body will expand into exactly one target instruction -- so it's not the length of the sequence generated, but the number of instructions. It could be argued that conditional suppression of an ASM should never be attempted by the compiler, but I don't know enough about the processor in question to be sure. The documentation for ASM should probably be updated to make it clear that gcc has to estimate the number of bytes that an ASM will generate and that the estimate is based on the number of statements multiplied by the longest instruction in the target. Use of any ASM statement that produces more bytes than that should be considered "unspecified behaviour" (it might work on some platforms all the time, but on others only some of the time).