Interesting thing

Dave Korn davek-ml@ntlworld.com
Sat Jun 16 04:59:00 GMT 2001


----- Original Message -----
From: "Tony Bryant" <brd@paradise.net.nz>
Sent: Saturday, June 16, 2001 9:44 AM


> Try compiling the following c++ program:
>
> // start here
           [SNIP]
> now run:
> gcc -g -O2 -c t.cc
> objdump -s -d t.o
>
> and you get:

  On powerpc-wrs-vxworks, you get

00000000 <broken__Fv>:
   0:   94 21 ff f0     stwu    r1,-16(r1)
   4:   39 20 82 40     li      r9,-32192
   8:   88 09 00 00     lbz     r0,0(r9)
   c:   39 60 82 41     li      r11,-32191
  10:   54 0a 06 3c     rlwinm  r10,r0,0,24,30
  14:   99 49 00 00     stb     r10,0(r9)
  18:   38 00 00 00     li      r0,0
  1c:   98 0b 00 00     stb     r0,0(r11)
  20:   38 21 00 10     addi    r1,r1,16
  24:   4e 80 00 20     blr

which is correct.

> Disassembly of section .text:
>
> 00000000 <broken__Fv>:
>    0: 55                   push   %ebp
>    1: a0 40 82 ff ff       mov    0xffff8240,%al
>    6: 25 fe 00 00 00       and    $0xfe,%eax
>    b: a2 40 82 ff ff       mov    %al,0xffff8240
>   10: a0 40 82 ff ff       mov    0xffff8240,%al
>   15: c6 05 41 82 ff ff 00  movb   $0x0,0xffff8241
>   1c: 89 e5                mov    %esp,%ebp
>   1e: a0 41 82 ff ff       mov    0xffff8241,%al
>   23: 5d                   pop    %ebp
>   24: c3                   ret
>
> Why are the instructions at 0x10 & 0x1e included?
> Is there any way around this apart from dropping the volatile?
> Have I misinterpreted the meaning of volatile?

  Nope, that's clearly broken, and I can see how disasterous that could be
if you're addressing one of those I/O chip registers that clears on a read,
for example.  So your gcc must be broken.  What version are you using?  I
get

Disassembly of section .text:

00000000 <_broken__Fv>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   a0 40 82 ff ff          mov    0xffff8240,%al
   8:   24 fe                   and    $0xfe,%al
   a:   a2 40 82 ff ff          mov    %al,0xffff8240
   f:   c6 05 41 82 ff ff 00    movb   $0x0,0xffff8241
  16:   89 ec                   mov    %ebp,%esp
  18:   5d                      pop    %ebp
  19:   c3                      ret
  1a:   90                      nop
  1b:   90                      nop

from gcc 2.95.3 i686-pc-cygwin32.  I get the same thing with all variations
of using gcc or g++ to compile, and with the filename t.cc or t.c, except
that when compiling t.c with gcc, the compiler emits non-inline versions of
the x and y functions as well. (Both of which are also correct).

> BTW This does a similar thing on the sh target as well:

> Interesting enough, it works fine if the file is a C program (i.e. you've
> called it t.c or similar.

  Very strange indeed.  Certainly looks like a bug from where I'm standing.

                  DaveK



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com



More information about the crossgcc mailing list