NO

Author Topic: V6.00 compiler bug, arm processor, double parameter  (Read 5897 times)

ml

  • Guest
V6.00 compiler bug, arm processor, double parameter
« on: October 22, 2009, 11:33:59 AM »
A reproducible compiler bug occurs when compiling the following sample code with the ARM processor option.

Code: [Select]
int sub(double x)
{
int a;
a = x;
return a;
}

double d;
double *pd;

int WinMain(void)
{
int i;

d = 5;
pd = &d;
i = sub(*pd);
return i;
}

The program terminates with an 'access violation' when the function 'sub' is called.

The problem occurs when the double pointer 'pd' is dereferenced (see the attached screen shot of the disassembly).
In particular register r0 is overwritten before the second part of the double variable is copied to register r1.
Removing the optimization does not help.

Version 5 is not affected.

Meanwhile I have a more precise description:
The problem occurs in the ARM code generator, when a double variable is passed by value and this variable is not hold in registers.
Then register r0 is used to hold the address of the variable. Register r0 is overwritten by the first part of the variable value. When the second part of the variable is copied to r1, register r0 holds no more the expected address and an access violation occurs.

« Last Edit: October 26, 2009, 04:25:51 PM by ml »

Mavis Enderby

  • Guest
Re: V6.00 compiler bug, arm processor, double parameter
« Reply #1 on: December 30, 2009, 01:12:04 PM »
For information, this also stops the GPS sample program from compiling correctly(http://www.smorgasbordet.com/pellesc/zip/gps.zip). The fault lies in the call:           
 
_snwprintf(wchBuf, NELEMS(wchBuf), L"%+f", Position.dblLongitude);

The GPS sample code compiles correctly with Pelles C version 5.00.8.

iancasey

  • Guest
Re: V6.00 compiler bug, arm processor, double parameter
« Reply #2 on: January 26, 2010, 10:23:31 PM »
I am getting the same problem with in WinCE:
_stprintf(strtmp, _T("% .15G"),d);

I went back to PellesC 5.00.8  and all is well again


but this line in Win32 - Unicode PellesC v5 or 6:
swprintf(strtmp, _T("% .15G"),d);
gives me these errors
error #2140: Type error in argument 2 to 'swprintf'; found 'wchar_t *', expected 'unsigned int'.
error #2140: Type error in argument 3 to 'swprintf'; found 'double', expected 'const wchar_t *'.

Ian
« Last Edit: January 26, 2010, 10:52:38 PM by iancasey »

JohnF

  • Guest
Re: V6.00 compiler bug, arm processor, double parameter
« Reply #3 on: January 27, 2010, 10:35:09 PM »
Have you looked up swprintf in the PellesC help file?

John

iancasey

  • Guest
Re: V6.00 compiler bug, arm processor, double parameter
« Reply #4 on: February 12, 2010, 01:01:30 AM »
John,
Sorry it took a while to reply.
My 1st comment was just to confirm I had the same problem as this thread using PellesC v6.0.

2nd comment,
yep, I read the help file.

I was wondering why WinCe compiles and Win32-Unicode doesn't and which was correct.

swprintf(strtmp, _T("% .15G"),d);

That line compiles for WinCe code but not with Win32 unicode.

my command line for Win32 unicode that gives me the error:
pocc -W1 -Ot -Gd -Go -Ze -Zx -MT -Tx86-coff -D_WIN32_WINNT=0x0501  -DUNICODE -D_UNICODE filename.c

and command line for WinCe:
pocc -W1 -Ot -Gd -Go -Ze -Zx -MT -Tarm-coff -D_WINCE -D_WIN32_WCE=0x400 -DARM -D_ARM_ -DUNICODE -D_UNICODE filename.c

I wrote Ansi2Unicode program to translate ansi code to unicode, replaces ansi keywords to their unicode counterparts and adds _T("string") around strings
For 90% of my programs I write them as I would for a desktop but with a WinCe sized gui then add 1-2 lines to my BCX code to translate and add extra .h files and compile for WinCe or Win32-Unicode. No need for an emulator.

Right now I am using PellesC v 5.00.8 with the v6.0 includes and libs and as far as I see my programs are now running correctly in WinCe.

Ian


JohnF

  • Guest
Re: V6.00 compiler bug, arm processor, double parameter
« Reply #5 on: February 12, 2010, 08:43:02 AM »
I don't know about WinCe but the help file I have says that the second parameter passed to swprintf is - 'No more than max wide characters are written'.

Syntax:
int swprintf(wchar_t * restrict dst, size_t max, const wchar_t * restrict format, ...);

You are not using it like that.

John