Works fine in Debug mode, not in Release mode. Why?

[jw1.yang]

Dear all. I'm currently developing an application for smartphone using Carbide 1.3 with S60 3rd fp2.
Recently found out that my application crashes when compiled with GCCE release mode(UREL), while it works perfectly when compiled with GCCE debug mode(UDEB), or when running by emulator(WINSCW).

The problem lied in that some of the variables were not properly assigned of correct values.

It seems to be caused by the bug in the GCCE compiler, to see the following C code and assembly.

unsigned int aa,bb;
aa=1;
unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;
pbb=(unsigned short*)&bb;

*pbb++=*paa++;
*pbb=*paa;
fprintf(fp,"%d",bb);
Of course, the result should be that '1' is copied from aa to bb.
However, when compiled with GCCE release mode, some odd value was assigned to bb, instead of 1.

Following is the disassembly for the C code above.
0x78744620 mov r3,#0x1
0x78744624 str r3,[r11,#-72]
0x78744628 ldrh r3,[r11,#-72]
0x7874462c cpy r5,r0
0x78744630 ldr r1,[pc,#48]
0x78744634 strh r3,[r11,#-76]
0x78744638 ldrh r3,[r11,#-70]
0x7874463c ldr r2,[r11,#-76]
0x78744640 strh r3,[r11,#-74]

The problem is that, just before the last instruction, in 0x7874463c(red colored), the value of bb is already loaded into R2, even before the final process of copying upper two bytes of aa into bb takes place in the last instruction, 0x78744640(blue colored)

This results in wrong value of bb is passed to fprintf.(Strictly speaking, uppers two bytes of 4byte-bb is uninitialized)


What is more weird, if you add some seemingly irrelevant code above, it begins to work fine. For example,

volatile unsigned int aa,bb;
aa=1;
volatile unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;

or

unsigned int aa,bb;
aa=1;
fprintf(fp,"%d",bb);
unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;


Here are my questions;
Is this a known issue? What can I do then? Upgrade GCCE? How?(I'm not quite sure about the version of my GCCE, since it was automatically installed along with carbide, but I guess it's GCC 3.4.3)

Thanks

[jw1.yang]

Dear all. I'm currently developing an application for smartphone using Carbide 1.3 with S60 3rd fp2.
Recently found out that my application crashes when compiled with GCCE release mode(UREL), while it works perfectly when compiled with GCCE debug mode(UDEB), or when running by emulator(WINSCW).

The problem lied in that some of the variables were not properly assigned of correct values.

It seems to be caused by the bug in the GCCE compiler, to see the following C code and assembly.

unsigned int aa,bb;
aa=1;
unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;
pbb=(unsigned short*)&bb;

*pbb++=*paa++;
*pbb=*paa;
fprintf(fp,"%d",bb);
Of course, the result should be that '1' is copied from aa to bb.
However, when compiled with GCCE release mode, some odd value was assigned to bb, instead of 1.

Following is the disassembly for the C code above.
0x78744620 mov r3,#0x1
0x78744624 str r3,[r11,#-72]
0x78744628 ldrh r3,[r11,#-72]
0x7874462c cpy r5,r0
0x78744630 ldr r1,[pc,#48]
0x78744634 strh r3,[r11,#-76]
0x78744638 ldrh r3,[r11,#-70]
0x7874463c ldr r2,[r11,#-76]
0x78744640 strh r3,[r11,#-74]

The problem is that, just before the last instruction, in 0x7874463c(red colored), the value of bb is already loaded into R2, even before the final process of copying upper two bytes of aa into bb takes place in the last instruction, 0x78744640(blue colored)

This results in wrong value of bb is passed to fprintf.(Strictly speaking, uppers two bytes of 4byte-bb is uninitialized)


What is more weird, if you add some seemingly irrelevant code above, it begins to work fine. For example,

volatile unsigned int aa,bb;
aa=1;
volatile unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;

or

unsigned int aa,bb;
aa=1;
fprintf(fp,"%d",bb);
unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;


Here are my questions;
Is this a known issue? What can I do then? Upgrade GCCE? How?(I'm not quite sure about the version of my GCCE, since it was automatically installed along with carbide, but I guess it's GCC 3.4.3)

Thanks

[jw1.yang]

Dear all. I'm currently developing an application for smartphone using Carbide 1.3 with S60 3rd fp2.
Recently found out that my application crashes when compiled with GCCE release mode(UREL), while it works perfectly when compiled with GCCE debug mode(UDEB), or when running by emulator(WINSCW).

The problem lied in that some of the variables were not properly assigned of correct values.

It seems to be caused by the bug in the GCCE compiler, to see the following C code and assembly.

unsigned int aa,bb;
aa=1;
unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;
pbb=(unsigned short*)&bb;

*pbb++=*paa++;
*pbb=*paa;
fprintf(fp,"%d",bb);
Of course, the result should be that '1' is copied from aa to bb.
However, when compiled with GCCE release mode, some odd value was assigned to bb, instead of 1.

Following is the disassembly for the C code above.
0x78744620 mov r3,#0x1
0x78744624 str r3,[r11,#-72]
0x78744628 ldrh r3,[r11,#-72]
0x7874462c cpy r5,r0
0x78744630 ldr r1,[pc,#48]
0x78744634 strh r3,[r11,#-76]
0x78744638 ldrh r3,[r11,#-70]
0x7874463c ldr r2,[r11,#-76]
0x78744640 strh r3,[r11,#-74]

The problem is that, just before the last instruction, in 0x7874463c(red colored), the value of bb is already loaded into R2, even before the final process of copying upper two bytes of aa into bb takes place in the last instruction, 0x78744640(blue colored)

This results in wrong value of bb is passed to fprintf.(Strictly speaking, uppers two bytes of 4byte-bb is uninitialized)


What is more weird, if you add some seemingly irrelevant code above, it begins to work fine. For example,

volatile unsigned int aa,bb;
aa=1;
volatile unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;

or

unsigned int aa,bb;
aa=1;
fprintf(fp,"%d",bb);
unsigned short* paa,*pbb;
paa=(unsigned short*)&aa;


Here are my questions;
Is this a known issue? What can I do then? Upgrade GCCE? How?(I'm not quite sure about the version of my GCCE, since it was automatically installed along with carbide, but I guess it's GCC 3.4.3)

Thanks

[wizard_hu_]

You already have this post in http://discussion.forum.nokia.com/fo...d.php?t=147848
Yes, I also see that there are no replies, however you have to accept it:
- for coding in Symbian C++ it is not necessary to know ARM assembly
- for coding in Symbian C++ it is not necessary to participate in development of GCC
- the construct you are experimenting with is at least a rare one.
Are you using any optimization switches?

[ltomuta]

The GNU compiler is provided by CodeSourcery, LLC and its release notes state:

...
==========
4. Support
==========

CodeSourcery does not provide free support for these packages.

CodeSourcery does provide paid support (including installation
assistance, defect correction, etc.) for these packages and for the
GNU Toolchain in general. Please send mail to info@codesourcery.com
if you are interested in purchasing support for the GNU Toolchain.

...

[jgiffen]

I too have been experiencing "release build only" problems, and in my efforts came across an answer to your problem:
See "Casting does not work as expected when optimization is turned on." in
A list of common GCCE NON BUGS.

Release mode turns on optimization, which relies on the types of aliased objects to be correct; if they're not correct, you get undefined behavior like you're experiencing. In your case the problem is using an 'unsigned short *' containing the address of an 'unsigned int'.

Try:

...
unsigned int *paa = &aa, *pbb = &bb; 
...

That should allow the compiler to optimize while keeping everything correct. Hope this helps