headers
Peter Weilbacher | 8 Apr 2009 10:47

Re: GCC 4.3.3 now available

On 02/24/09 09:50, Paul Smedley wrote:
> Hi All,
>
> On Tue, 24 Feb 2009 03:07:34 UTC, "Paul Smedley"
> <pauldespam <at> despamsmedley.id.au>  wrote:
>
>> Hi All,
>>
>> On Mon, 23 Feb 2009 23:00:44 UTC, Paul Smedley<paul <at> smedley.id.au>
>> wrote:
>>
>>> Hi KO,
>>>
>>> KO Myung-Hun wrote:
>>>> I think, you'd better modify ScummVM part instead of SDL headers,
>>>> because the cause of build error is in ScummVM not using SDLCALL.
>>>
>>> I think there's more to it than that.
>>>
>>> Take a look at my testcase at http://smedley.info/testcase.c
>>>
>>> This compiles OK with gcc, but fails with g++ with:
>>> testcase.c:8: error: invalid conversion from 'void (*)()' to 'void (*)()'
>>> testcase.c:8: error:   initializing argument 1 of 'int atexit(void (*)())'
>>
>> Compiler bug found and fixed - new release should be out later
>> today...
>
> As promised - new build now available from
> http://download.smedley.info
(Continue reading)

Permalink | Reply | 1 comment |
headers
paul | 9 Apr 2009 00:31
Picon

Re: Re: GCC 4.3.3 now available

Hi Peter,

Quoting "Peter Weilbacher" <newsspam <at> weilbacher.org>:

> On 02/24/09 09:50, Paul Smedley wrote:
>> Hi All,
>>
>> On Tue, 24 Feb 2009 03:07:34 UTC, "Paul Smedley"
>> <pauldespam <at> despamsmedley.id.au>  wrote:
>>
>>> Hi All,
>>>
>>> On Mon, 23 Feb 2009 23:00:44 UTC, Paul Smedley<paul <at> smedley.id.au>
>>> wrote:
>>>
>>>> Hi KO,
>>>>
>>>> KO Myung-Hun wrote:
>>>>> I think, you'd better modify ScummVM part instead of SDL headers,
>>>>> because the cause of build error is in ScummVM not using SDLCALL.
>>>>
>>>> I think there's more to it than that.
>>>>
>>>> Take a look at my testcase at http://smedley.info/testcase.c
>>>>
>>>> This compiles OK with gcc, but fails with g++ with:
>>>> testcase.c:8: error: invalid conversion from 'void (*)()' to 'void (*)()'
>>>> testcase.c:8: error:   initializing argument 1 of 'int atexit(void (*)())'
>>>
>>> Compiler bug found and fixed - new release should be out later
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Smedley | 12 Apr 2009 02:19
Picon

Weird problem - libc or eCS bug?

Hi All,

Whilst working on Python 2.6.2c1 I came across a SIGFPE problem, which 
the libc registers pointed to strtod().

Googling sigfpe and strtod, pointed me to 
http://markmail.org/message/gcjqlo2dquprrt2h which provides a simple 
testcase, which fails for me on eCS 2.0 rc6a, but works on the same 
hardware with a brand new install of eCS 1.2R.

Interestingly, it also works on a boot from CD, or boot to command line 
on eCS 2.0 rc6a.

The testcase code is:
#include <stdlib.h>

int main(void) { strtod("5e-324", NULL);

return (0); }

Code works with libc05 - but the strtod() code changed in libc06 (moved 
to the gdtoa library).  I tried updating the gdtoa library to the latest 
code in case it was a bug in that library, but the testcase still fails.

test.exe - which is the result of the above code, can be downloaded from 
http://smedley.info/test.exe

I got some users on IRC to test - a range of results - some users on ACP 
had it work ok, but some who had applied all latest fixes had it fail. 
unpatched eCS 1.2R is OK, eCS 1.2R with latest fixes is not ok.  All
(Continue reading)

Permalink | Reply | 3 comments |
headers
Knut St. Osmundsen | 12 Apr 2009 02:00
Favicon

Re: Weird problem - libc or eCS bug?


On Apr 12, 2009, at 02:19, Paul Smedley wrote:

> Hi All,
>
> Whilst working on Python 2.6.2c1 I came across a SIGFPE problem,  
> which the libc registers pointed to strtod().
>
> Googling sigfpe and strtod, pointed me to http://markmail.org/message/gcjqlo2dquprrt2h 
>  which provides a simple testcase, which fails for me on eCS 2.0  
> rc6a, but works on the same hardware with a brand new install of eCS  
> 1.2R.
>
> Interestingly, it also works on a boot from CD, or boot to command  
> line on eCS 2.0 rc6a.
>
> The testcase code is:
> #include <stdlib.h>
>
> int main(void) { strtod("5e-324", NULL);
>
> return (0); }
>
> Code works with libc05 - but the strtod() code changed in libc06  
> (moved to the gdtoa library).  I tried updating the gdtoa library to  
> the latest code in case it was a bug in that library, but the  
> testcase still fails.
>
> test.exe - which is the result of the above code, can be downloaded  
> from http://smedley.info/test.exe
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Smedley | 12 Apr 2009 03:00
Picon

Re: Weird problem - libc or eCS bug?

Hi Knut,

Knut St. Osmundsen wrote:
> 
> On Apr 12, 2009, at 02:19, Paul Smedley wrote:
> 
>> Hi All,
>>
>> Whilst working on Python 2.6.2c1 I came across a SIGFPE problem, which 
>> the libc registers pointed to strtod().
>>
>> Googling sigfpe and strtod, pointed me to 
>> http://markmail.org/message/gcjqlo2dquprrt2h which provides a simple 
>> testcase, which fails for me on eCS 2.0 rc6a, but works on the same 
>> hardware with a brand new install of eCS 1.2R.
>>
>> Interestingly, it also works on a boot from CD, or boot to command 
>> line on eCS 2.0 rc6a.
>>
>> The testcase code is:
>> #include <stdlib.h>
>>
>> int main(void) { strtod("5e-324", NULL);
>>
>> return (0); }
>>
>> Code works with libc05 - but the strtod() code changed in libc06 
>> (moved to the gdtoa library).  I tried updating the gdtoa library to 
>> the latest code in case it was a bug in that library, but the testcase 
>> still fails.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Yeo | 12 Apr 2009 04:31

Re: Weird problem - libc or eCS bug?

On Sun, 12 Apr 2009 09:45:43 +0845, Paul Smedley wrote:

>
>gdtoaimp.h mentions:
>/* On a machine with IEEE extended-precision registers, it is
>  * necessary to specify double-precision (53-bit) rounding precision
>  * before invoking strtod or dtoa.  If the machine uses (the equivalent
>  * of) Intel 80x87 arithmetic, the call
>  *	_control87(PC_53, MCW_PC);
>  * does this with many compilers.  Whether this or another call is
>  * appropriate depends on the compiler; for this to work, it may be
>  * necessary to #include "float.h" or another system-dependent header
>  * file.
>  */
>
>I added this _control87 to the testcase and it didn't help - I'll do 
>some experimentation!

Doodle put this into cairo-os2-surface.c

static void inline
DisableFPUException (void)
{
    unsigned short usCW;

    /* Some OS/2 PM API calls modify the FPU Control Word,
     * but forget to restore it.
     *
     * This can result in XCPT_FLOAT_INVALID_OPCODE exceptions,
     * so to be sure, we disable Invalid Opcode FPU exception
(Continue reading)

Permalink | Reply | 501 comments |
headers
Paul Smedley | 12 Apr 2009 04:26
Picon

Re: Weird problem - libc or eCS bug?

Hi Dave,

Dave Yeo wrote:
> On Sun, 12 Apr 2009 09:45:43 +0845, Paul Smedley wrote:
> 
>> gdtoaimp.h mentions:
>> /* On a machine with IEEE extended-precision registers, it is
>>  * necessary to specify double-precision (53-bit) rounding precision
>>  * before invoking strtod or dtoa.  If the machine uses (the equivalent
>>  * of) Intel 80x87 arithmetic, the call
>>  *	_control87(PC_53, MCW_PC);
>>  * does this with many compilers.  Whether this or another call is
>>  * appropriate depends on the compiler; for this to work, it may be
>>  * necessary to #include "float.h" or another system-dependent header
>>  * file.
>>  */
>>
>> I added this _control87 to the testcase and it didn't help - I'll do 
>> some experimentation!
> 
> Doodle put this into cairo-os2-surface.c
> 
> static void inline
> DisableFPUException (void)
> {
>     unsigned short usCW;
> 
>     /* Some OS/2 PM API calls modify the FPU Control Word,
>      * but forget to restore it.
>      *
(Continue reading)

Permalink | Reply | 502 comments |
headers
Paul Smedley | 12 Apr 2009 04:29
Picon

Re: Weird problem - libc or eCS bug?

Hi Knut,

Knut St. Osmundsen wrote:
> 
> On Apr 12, 2009, at 02:19, Paul Smedley wrote:
> Start it in a debugger and look at the FPU registers, you will probably 
> find that when it crashes the FPU control word (CW) is different. It 
> might actually be easier to just print it, come to think of it:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main()
> {
>     unsigned short cw = 0xffff;
> 
>     __asm__ __volatile__ ("fstcw %0" : "=m" (cw));
>     printf("cw=%#x\n", cw);
>     fflush(stdout);
> 
>     strtod("5e-324", NULL);
>     return 0;
> }
[U:\DEV\python-2.6.2c1]test2
cw=0x362

Killed by SIGFPE
pid=0x11b7 ppid=0x00a1 tid=0x0001 slot=0x011f pri=0x0200 mc=0x0001
U:\DEV\PYTHON-2.6.2C1\TEST2.EXE
LIBC063 0:0005f600
(Continue reading)

Permalink | Reply | 0 comments |
headers
KO Myung-Hun | 12 Apr 2009 06:06

Re: Weird problem - libc or eCS bug?

Hi/2.

How about '_control87(MCW_EM, MCW_EM);' ?

It mask off all the exception bits.

And if you use debugger or write exception handler, you can know the 
exception type of SIGFPE such as XCPT_FLOAT_UNDERFLOW.

Paul Smedley wrote:
> Hi Dave,
>
> Dave Yeo wrote:
>> On Sun, 12 Apr 2009 09:45:43 +0845, Paul Smedley wrote:
>>
>>> gdtoaimp.h mentions:
>>> /* On a machine with IEEE extended-precision registers, it is
>>>  * necessary to specify double-precision (53-bit) rounding precision
>>>  * before invoking strtod or dtoa.  If the machine uses (the equivalent
>>>  * of) Intel 80x87 arithmetic, the call
>>>  *    _control87(PC_53, MCW_PC);
>>>  * does this with many compilers.  Whether this or another call is
>>>  * appropriate depends on the compiler; for this to work, it may be
>>>  * necessary to #include "float.h" or another system-dependent header
>>>  * file.
>>>  */
>>>
>>> I added this _control87 to the testcase and it didn't help - I'll do 
>>> some experimentation!
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Smedley | 12 Apr 2009 07:41
Picon

Re: Re: Weird problem - libc or eCS bug?

Hi KO,

KO Myung-Hun wrote:
> How about '_control87(MCW_EM, MCW_EM);' ?
> 
> It mask off all the exception bits.
Thanks - this one helped!

Cheers,

Paul.
Permalink | Reply | 0 comments |

Gmane