[Bug c/40115] New: -O2 and higher causes wrong label address calculation

[Bug c/40115] New: -O2 and higher causes wrong label address calculation

[sergstesh at yahoo dot com]

The following program:
"
cat -n main.c
     1  #include <stdio.h>
     2
     3
     4  int main()
     5    {
     6    __label__ lab3;
     7    __label__ lab4;
     8
     9    int i = 0;
    10
    11    i++;
    12    lab1: fprintf(stderr, "i=%d\n", i);
    13
    14    i++;
    15    lab2: fprintf(stderr, "i=%d\n", i);
    16
    17    i++;
    18    lab3: fprintf(stderr, "i=%d\n", i);
    19
    20    i++;
    21    lab4: fprintf(stderr, "i=%d\n", i);
    22
    23    fprintf(stderr, "&&lab1=%08x\n", (unsigned)&&lab1);
    24    fprintf(stderr, "&&lab2=%08x\n", (unsigned)&&lab2);
    25    fprintf(stderr, "&&lab3=%08x\n", (unsigned)&&lab3);
    26    fprintf(stderr, "&&lab4=%08x\n", (unsigned)&&lab4);
    27
    28    return 0;
    29    }
"

after being compiled as

/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O1 -Wall -Wextra
main.c -o main_-O1

produces:

"
 ./main_-O1
i=1
i=2
i=3
i=4
&&lab1=08048435
&&lab2=08048452
&&lab3=0804846f
&&lab4=0804848c
"

which is correct in a sense all the labels have different addresses.

When compiled as

/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O2 -Wall -Wextra
main.c -c -o main_-O2.o

it produces

"
 ./main_-O2
i=1
i=2
i=3
i=4
&&lab1=08048430
&&lab2=08048430
&&lab3=08048430
&&lab4=08048430
",

which is wrong in the sense all the addresses are the same.

Please note that labels have intentionally been put against 'fprintf'
statements which are _not_ eliminated by optimization ('objdump' easily proves
this).

I have read pages ## 246 .. 248 in

http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf

, they don't mention optimizations (or did I miss it ?).

The problem also exists with gcc-3.4.6.


-- 
           Summary: -O2 and higher causes wrong label address calculation
           Product: gcc
           Version: 4.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sergstesh at yahoo dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115

[Bug c/40115] -O2 and higher causes wrong label address calculation

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-12 14:55 -------
No labels are not designed that way.  They are designed only for jumping and
when they are taken the address of, there should only be used for jumping and
nothing else.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115

[Bug c/40115] -O2 and higher causes wrong label address calculation

[sergstesh at yahoo dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]



------- Comment #2 from sergstesh at yahoo dot com  2009-05-12 15:43 -------
No, the documentation explicitly says

( http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf , page 247 .. 248):

"
5.3 Labels as Values
...
   To use these values, you need to be able to jump to one. This is done with
the computed
goto statement1 , goto *exp ;. For example,
       goto *ptr;
Any expression of type void * is allowed.
  One way of using these constants is in initializing a static array that will
serve as a jump
table:
       static void *array[] = { &&foo, &&bar, &&hack };
  Then you can select a label with indexing, like this:
       goto *array[i];
Note that this does not check whether the subscript is in bounds—array
indexing in C never
does that.
  Such an array of label values serves a purpose much like that of the switch
statement.
The switch statement is cleaner, so use that rather than an array unless the
problem does
not fit a switch statement very well.
   Another use of label values is in an interpreter for threaded code. The
labels within the
interpreter function can be stored in the threaded code for super-fast
dispatching.
   You may not use this mechanism to jump to code in a different function. If
you do that,
totally unpredictable things will happen. The best way to avoid this is to
store the label
address only in automatic variables and never pass it as an argument.
   An alternate way to write the above example is
       static const int array[] = { &&foo - &&foo, &&bar - &&foo,
                                    &&hack - &&foo };
       goto *(&&foo + array[i]);
",

i.e. the documentation explicitly allows to rely upon labels as values.

I actually checked putting label addresses into an array - the same problem. I
didn't publish the code here - didn't want to over-complicate the test case.


-- 

sergstesh at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115

[Bug c/40115] -O2 and higher causes wrong label address calculation

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2009-05-12 15:58 -------
The intention of address of labels is only for use of flow control and nothing
else.  So taking the address of a label and using it to find the current PC is
not a valid use of this extension.  This extension was not designed to be very
generic it was designed only for flow control usage with the computed goto.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115