Bug 66477 - __asm__ __volatile__ and &&Llabel constructs disappear
Summary: __asm__ __volatile__ and &&Llabel constructs disappear
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc   
(Show other bugs)
Version: 7.1
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-06-11 02:17 UTC by Jens Troeger
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-06-12 03:30:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
.c and .s file (991 bytes, application/octet-stream)
2002-06-11 02:19 UTC, Jens Troeger
no flags Details

Description Jens Troeger 2002-06-11 02:17:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.9-31custom i686)

Description of problem:
assembly put into __asm__ __volatile__ are gone in both,
.s and .o files. further, address arithmetic using &&Llabel
is therefore wrong when used in conjuction with inline
assembly. also, the code is moved around in a wrong way. see example source

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
compile the following main function

int main(int argc, char* argv[]) {
        int len = &&Lend - &&Lstart;
        return 0;
        __asm__ __volatile__ ("nop; nop");


  gcc -S -g3 -O0 test.c

and you will see the following asm

        .stabn 68,0,2,.LM1-main
        pushl   %ebp
        movl    %esp, %ebp
        subl    $4, %esp
        .stabn 68,0,4,.LM2-main
        movl    $.L3, %eax
        subl    $.L4, %eax
        movl    %eax, -4(%ebp)
        .stabn 68,0,5,.LM3-main
        movl    $0, %eax
        .stabn 68,0,11,.LM4-main

please note .L3 and .L4 at the wrong place with missing NOP instructions

Actual Results:  see the assembly code

Expected Results:  expected is that there are two NOP instructions between
.L3 and .L4 and that those labels are after the RET

Additional info:

rpm -q gcc gives gcc-2.96-85. all the related packages
are installed as well.

Comment 1 Jens Troeger 2002-06-11 02:19:10 UTC
Created attachment 60444 [details]
.c and .s file

Comment 2 Jens Troeger 2002-06-11 02:20:49 UTC
the above code works with 2.95.3 rpms installed, as well as it works with gcc
2.95 under SuSE and Solaris

Comment 3 Jakub Jelinek 2002-06-11 09:42:52 UTC
Your expectations are incorrect. The asm statement is unreachable, so the compiler
is free to optimize it away. It doesn't matter if it is volatile or not.

Comment 4 Jens Troeger 2002-06-12 00:28:08 UTC
the code might be unreachable from the control flow point of view, but it
is referenced through the labels, thus it should not be removed. it is not
ok for a compiler to "optimize away" data.

Comment 5 Jens Troeger 2002-06-12 00:29:18 UTC
the code might be unreachable from the control flow point of view, but it
is referenced through the labels, thus it should not be removed. it is not
ok for a compiler to "optimize away" data.

Comment 6 Jens Troeger 2002-06-12 01:06:27 UTC
and if you check out the gcc docs


it says there:

  "You can prevent an asm instruction from being deleted, moved
  significantly, or combined, by writing the keyword volatile after
  the asm"


Comment 7 Jakub Jelinek 2002-06-12 09:27:16 UTC
But you are not using gcc 2.95, are you?
2.96-RH info gcc writes e.g.:
   An `asm' instruction without any operands or clobbers (and "old
style" `asm') will not be deleted or moved significantly, regardless,
unless it is unreachable, the same wasy as if you had written a
`volatile' keyword.
and 3.1 info gcc is even more clear:
   The `volatile' keyword indicates that the instruction has important
side-effects.  GCC will not delete a volatile `asm' if it is reachable.
(The instruction can still be deleted if GCC can prove that
control-flow will never reach the location of the instruction.)  In
addition, GCC will not reschedule instructions across a volatile `asm'

Your asm is not reachable, although you take the address of the labels, you never
jump to it (if you e.g. void *f = &&Lstart; goto *f; somewhere in reachable
code the asm will not be optimized away).
Your code is equal to writing if (0) { asm volatile ("nop; nop"); } which is
optimized away too.

Comment 8 Jens Troeger 2002-06-12 23:46:12 UTC
well i dont really agree, but anyway... here is a workaround:

static bool phony = false;
int main(int argc, char* argv[]) {
        if (phony) goto Lstart;

        int len = &&Lend - &&Lstart;
        return 0; 
        __asm__ __volatile__ ("nop; nop");

that prevents the code from being dead and, thus, from being deleted.
not very elegant (which workaround is elegant anyway?!) but it seems
to work. 

(i use those constructs quite often, and not only with __asm__ in it; its
to generate code that i can copy around and execute at runtime)

Note You need to log in before you can comment on or make changes to this bug.