From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13598 invoked by alias); 28 Oct 2002 04:48:09 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 13377 invoked from network); 28 Oct 2002 04:48:05 -0000 Received: from unknown (HELO txsmtp02.texas.rr.com) (24.93.36.230) by sources.redhat.com with SMTP; 28 Oct 2002 04:48:05 -0000 Received: from hotmail.com (cs242742-170.austin.rr.com [24.27.42.170]) by txsmtp02.texas.rr.com (8.12.5/8.12.2) with ESMTP id g9S4lESr013471 for ; Sun, 27 Oct 2002 23:47:14 -0500 (EST) Message-ID: <3DBCC177.FDE9B088@hotmail.com> Date: Sun, 27 Oct 2002 20:48:00 -0000 From: Jeremy Linton X-Accept-Language: en MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: arm-elf inline assembly problem (gcc bug?) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00337.txt.bz2 I am running a self built gcc 3.0.3 from a few months ago. Its been working fine until last a week or so when I wrote the following code. //reads a single byte from the IO port set by PioSetAddress unsigned char PioReadChar(void) { PioController->WO_OutputDisable=0xFF; //set the data pins for input PioController->WO_InputFilterEnable=0xFF; int ret; //each PIO toggle takes ~90ns __asm__("mov r5,#0x400\n\t" "mov r6,#0x1000\n\t" "str r5,[%3]\n\t" "str r6,[%1]\n\t" "ldr %0,[%2]\n\t" //reading the byte a few times is a cheap way to figure out my delay "ldr %0,[%2]\n\t" //since I know exactly how long (in real time) the ldr is taking... "ldr %0,[%2]\n\t" "ldr %0,[%2]\n\t" "ldr %0,[%2]\n\t" "str r6,[%3]\n\t" //damn!!?? gcc 3.0.3 sometimes reuses a register for both %0 and %3! "str r5,[%1]\n\t" "str r5,[%1]\n\t"//stick in the min change time of 135ns "str r5,[%1]\n\t" : "=r" (ret) : "r" (&PioController->WO_ClearOutputData),"r" (&PioController->RO_PinDataStatus) , "r" (&PioController->WO_SetOutputData) : "r5", "r6" ); return ret; } which sometimes is giving me output which looks like (it varies depending on the -O). 0x1017e0 <_Z11PioReadCharv+52>: str r5, [r3] 0x1017e4 <_Z11PioReadCharv+56>: str r6, [r0] 0x1017e8 <_Z11PioReadCharv+60>: ldr r0, [r2] <--- Note the R0 reuse 0x1017ec <_Z11PioReadCharv+64>: ldr r0, [r2] 0x1017f0 <_Z11PioReadCharv+68>: ldr r0, [r2] 0x1017f4 <_Z11PioReadCharv+72>: ldr r0, [r2] 0x1017f8 <_Z11PioReadCharv+76>: ldr r0, [r2] 0x1017fc <_Z11PioReadCharv+80>: str r6, [r3] 0x101800 <_Z11PioReadCharv+84>: str r5, [r0] <--- core dump, r0 has the value loaded not the original r0 value 0x101804 <_Z11PioReadCharv+88>: str r5, [r0] 0x101808 <_Z11PioReadCharv+92>: str r5, [r0] I've been compiling it like. arm-elf-gcc -DUNIX -g -c -O -Wall -fno-exceptions -fno-rtti Ethernet.cpp Anyone have any suggestions? Has this problem been fixed in a newer gcc? I don't want to go through the pain of upgrading if it there haven't been any bugs like this fixed. I would explicitly control the register assignments, but I'm not sure how to do it with the arm. BTW: remove the ".NOSPAM" for a functional address. Thank you for you time, Jeremy Linton