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