This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
optimization/7715: inlining of function with inline assembler causes duplicate assembler lables
- From: linux_dr at yahoo dot com
- To: gcc-gnats at gcc dot gnu dot org
- Date: 24 Aug 2002 23:16:12 -0000
- Subject: optimization/7715: inlining of function with inline assembler causes duplicate assembler lables
- Reply-to: linux_dr at yahoo dot com
>Number: 7715
>Category: optimization
>Synopsis: inlining of function with inline assembler causes duplicate assembler lables
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: rejects-legal
>Submitter-Id: net
>Arrival-Date: Sat Aug 24 18:06:03 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Loren Osborn <linux_dr@yahoo.com>
>Release: gcc 3.1.1
>Organization:
>Environment:
Linux Mandrake 8.1
>Description:
I found a similar bug to PR233, and was disappointed to
see that PR233 was closed, appearantly just because the
URL to the test case became a broken link.
I think I have found a manifistaion of the same bug,
although it doesn't involve unrolling loops. It involves
inlining of functions with inline-assembler lables in it...
I have included a minimal test case
As far as I am aware, the code itself (while not
technically vailid ANSI C, because ANSI C doesn't
explicitly allow inline assembler) should be valid in
gcc.
>How-To-Repeat:
gcc -O3 -c -o InlineLableBug.o InlineLableBug.c
>Fix:
gcc should probably prepend (or append) a string to each assembler label that is unique to each instantiation of that function.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="InlineLableBug.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="InlineLableBug.c"