From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13368 invoked by alias); 27 Aug 2002 17:26:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 13349 invoked by uid 71); 27 Aug 2002 17:26:01 -0000 Resent-Date: 27 Aug 2002 17:26:01 -0000 Resent-Message-ID: <20020827172601.13348.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, piotr.wyderski@hoga.pl Received: (qmail 13260 invoked by uid 61); 27 Aug 2002 17:25:04 -0000 Message-Id: <20020827172504.13259.qmail@sources.redhat.com> Date: Tue, 27 Aug 2002 13:36:00 -0000 From: piotr.wyderski@hoga.pl Reply-To: piotr.wyderski@hoga.pl To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: middle-end/7736: gcc destroys stack layout when a local label is used X-SW-Source: 2002-08/txt/msg00571.txt.bz2 List-Id: >Number: 7736 >Category: middle-end >Synopsis: gcc destroys stack layout when a local label is used >Confidential: no >Severity: critical >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Tue Aug 27 10:26:01 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Piotr Wyderski >Release: 3.0, 3.0.1, 3.0.4 (supposably all versions) >Organization: >Environment: IA-32 Celeron, Red Hat Linux 7.2. >Description: When a local label is used in a function, gcc generates broken code. The simplest example is: void test(void) { ({ __label__ x; x: goto x; }); } gcc -S -O2 1.c, which produces: .file "1.c" .text .align 16 .globl test .type test,@function test: pushl %ebp movl %esp, %ebp subl $8, %esp .L2: jmp .L2 .Lfe1: .size test,.Lfe1-test .ident "GCC: (GNU) 3.0.4" The error is because of "subl $8,%esp". This is NOT an alignment issue, because sometimes (when a function is slightly larger) it produces things like: push edx push edx // very small function body here, which _doesn't_ use edx nor ecx. pop ecx pop eax ret There's no such an error when a global (i.e. normal) label is used instead, code is generated properly. I've tested that on many ways and I am completely sure this wrong behaviour is because of local labels. When the function code is quite large, it causes a crash of the application, thus this bug is critical. >How-To-Repeat: Use a local label in a (small) function and read assembly output. >Fix: >Release-Note: >Audit-Trail: >Unformatted: