From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26973 invoked by alias); 10 Jul 2006 16:27:47 -0000 Received: (qmail 26963 invoked by uid 22791); 10 Jul 2006 16:27:46 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.12) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Jul 2006 16:27:43 +0000 Received: from stewie.corp.google.com (stewie.corp.google.com [172.24.0.49]) by smtp-out.google.com with ESMTP id k6AGRX7p009710; Mon, 10 Jul 2006 09:27:33 -0700 Received: from smtp.google.com (angband.corp.google.com [192.168.15.227]) by stewie.corp.google.com with ESMTP id k6AGROWT019703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jul 2006 09:27:25 -0700 Received: from localhost.localdomain.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) (authenticated bits=0) by smtp.google.com (8.13.7/8.13.6) with ESMTP id k6AGRNu5021352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Jul 2006 09:27:24 -0700 To: Simon Kagstrom Cc: gcc-help@gcc.gnu.org Subject: Re: -fno-delayed-branch and the bne-instruction on MIPS References: <87d5cihrbz.wl%simon.kagstrom@bth.se> <877j2mhrxu.wl%simon.kagstrom@bth.se> From: Ian Lance Taylor Date: Mon, 10 Jul 2006 16:27:00 -0000 In-Reply-To: <877j2mhrxu.wl%simon.kagstrom@bth.se> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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 X-SW-Source: 2006-07/txt/msg00120.txt.bz2 Simon Kagstrom writes: > Unfortunately there was no difference with -Wa,-O0. It does however > look like the use of Linux-style syscalls break the > -fno-delayed-branch behavior. I have code like > > #define _syscall1(type,name,atype,a) \ > type name(atype a) \ > { \ > register unsigned long __a0 asm("$4") = (unsigned long) a; \ > register unsigned long __v0 asm("$2"); \ > \ > __asm__ volatile ( \ > ".set\tnoreorder\n\t" \ > "li\t$2, %2\t\t\t# " #name "\n\t" \ > "syscall\n\t" \ > ".set\treorder" \ > : "=&r" (__v0) \ > : "r" (__a0), "i" (__NR_##name) \ > ); \ > \ > return (type) __v0; \ > } > #define __NR_exit 0 > static inline _syscall1(void,exit , int, code ); > > and with the call of exit(...), the delay slots are filled with > instructions. If I just define a plain function and call that, > -fno-delayed-branch seems to behave correctly. I see. This is not a bug in the compiler. The ".set reorder" directive tells the assembler that it should reorder instructions into branch delay slots when possible. The compiler just copies the ".set reorder" directly from the asm statement. Both the compiler and the assembler are acting as expected. You should rewrite your asm statement to not use .set reorder. Do this instead: .set push .set noreorder ... .set pop > Anyway, I've submitted a bug report at > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28325 I've closed out this bug report. Ian