On Wednesday 11 July 2007 08.39, Florian Klaempfl wrote:
>
> That's a point though I thought we could safe this extra check because I
> didn't expect that a lot of people are still using PII :)
>
A PII with 256MB ram is my main development machine. Do you see why
MSEide+MSEgui is so fast? ;-)
From
Micha Nelissen schrieb:
> Yury Sidorov wrote:
>>> CPU supports it. But CPU support doesn't mean OS support. And to check
>>> if the OS supports SSE you've to execute an sse instruction and handle
>>> the exception.
>>
>> Florian, to prevent SIGILL on non SSE CPUs we can first check CPUID
>> and exe
Yury Sidorov wrote:
CPU supports it. But CPU support doesn't mean OS support. And to check
if the OS supports SSE you've to execute an sse instruction and handle
the exception.
Florian, to prevent SIGILL on non SSE CPUs we can first check CPUID and
execute sse instruction only if CPUID reports
Sergei Gorelkin schrieb:
> Wednesday, July 11, 2007, 12:06:51 AM, Florian wrote:
>
> FK> Vinzent Hoefler schrieb:
>>> On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote:
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
> Maybe other way to detect SSE support exists...
CPUID?
>>>
On Tuesday 10 July 2007 17.04, Jonas Maebe wrote:
> You can also disable gdb catching SIGILL from the start of the
> program using "handle SIGILL nostop noprint" (in case gdb for win32
> is broken in this respect), but then you should re-enable it later on
> (unless you don't want the debugger to b
Here's a partial work-around: First, check if CPUID says there's SSE hardware
support. If and only if it says "yes", then check for OS support by executing
an SSE instruction. This will fix support for systems that don't have SSE
support in hardware; and it also works for systems with full SS
Hi Jonas,
Was 7644 (force utf-8 encoding on darwin) merged to 2.1.5?
If not, could you do it?
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Wednesday, July 11, 2007, 12:06:51 AM, Florian wrote:
FK> Vinzent Hoefler schrieb:
>> On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote:
>>> On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
Maybe other way to detect SSE support exists...
>>> CPUID?
>>
>> To be more precise, the way reco
From: "Florian Klaempfl" <[EMAIL PROTECTED]>
Martin Schreiber schrieb:
On Tuesday 10 July 2007 14.53, [EMAIL PROTECTED] wrote:
And what should I do in MSEide? Disable SIGILL reporting by gdb?
How does Lazarus handle the problem?
It does not handle it. If you handle it in MSEIDE, please let us
Vinzent Hoefler schrieb:
> On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote:
>> On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
>>> Maybe other way to detect SSE support exists...
>> CPUID?
>
> To be more precise, the way recommended by Intel:
>
> "To make this check, execute the CPUID ins
Martin Schreiber schrieb:
> On Tuesday 10 July 2007 14.53, [EMAIL PROTECTED] wrote:
>>> And what should I do in MSEide? Disable SIGILL reporting by gdb?
>>> How does Lazarus handle the problem?
>> It does not handle it. If you handle it in MSEIDE, please let us know how
>> you did it.
>>
> The IDE
On 10 Jul 2007, at 17:42, Martin Schreiber wrote:
On Tuesday 10 July 2007 17.04, Jonas Maebe wrote:
It seems that either your specific gdb is broken, or that gdb for
win32 is broken in this regard. By default, gdb's setting for SIGILL
should be:
(gdb) info handle SIGILL
SignalStop
On Tuesday 10 July 2007 17.04, Jonas Maebe wrote:
> It seems that either your specific gdb is broken, or that gdb for
> win32 is broken in this regard. By default, gdb's setting for SIGILL
> should be:
>
> (gdb) info handle SIGILL
> SignalStop Print Pass to program Description
> SIGI
On 10 Jul 2007, at 16:39, Martin Schreiber wrote:
Program received signal SIGILL, Illegal instruction.
0x00402091 in SYSTEM_FPC_CPUCODEINIT ()
(gdb) c
Continuing.
Program exited with code 0200.
(gdb)
"
And now what to do?
It seems that either your specific gdb is broken, or that gdb for
wi
On Tuesday 10 July 2007 14.34, Jonas Maebe wrote:
> The rtl checks on startup whether or not your cpu supports SSE. It
> does so by executing an SSE instruction, catching the "illegal
> instruction" exception if it occurs and if so, setting a boolean to
> false.
>
> So just type "continue" in gdb t
On 10 Jul 2007, at 15:39, Martin Schreiber wrote:
On Tuesday 10 July 2007 15.13, Jonas Maebe wrote:
On 10 Jul 2007, at 15:11, Martin Schreiber wrote:
Question to the FPC developers:
Is there really no other method to check for SSE support?
According to the comments of Florian in the code, t
On Tuesday 10 July 2007 15.13, Jonas Maebe wrote:
> On 10 Jul 2007, at 15:11, Martin Schreiber wrote:
> > Question to the FPC developers:
> > Is there really no other method to check for SSE support?
>
> According to the comments of Florian in the code, there is no other
> way which works everywher
From: "Bernd Mueller" <[EMAIL PROTECTED]>
Yury Sidorov wrote:
I compiled binutils myself and yes, the problem is present.
It does not happen when doing make cycle on real arm-linux box.
I will fix this issue.
thank you very much.
Fixed in r8008.
Yury.
__
Yury Sidorov wrote:
I compiled binutils myself and yes, the problem is present.
It does not happen when doing make cycle on real arm-linux box.
I will fix this issue.
thank you very much.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.fr
From: "Bernd Mueller" <[EMAIL PROTECTED]>
Yury Sidorov wrote:
From: "Bernd Mueller" <[EMAIL PROTECTED]>
this compiles without errors. But I would like to get a
hardfloat enabled RTL again.
What host OS do you use?
I am using Windows 98SE for cross compiling.
Where arm-linux cross binutil
On 10 Jul 2007, at 15:11, Martin Schreiber wrote:
Question to the FPC developers:
Is there really no other method to check for SSE support?
According to the comments of Florian in the code, there is no other
way which works everywhere.
Jonas
__
On Tuesday 10 July 2007 14.53, [EMAIL PROTECTED] wrote:
> > And what should I do in MSEide? Disable SIGILL reporting by gdb?
> > How does Lazarus handle the problem?
>
> It does not handle it. If you handle it in MSEIDE, please let us know how
> you did it.
>
The IDE must check where the SIGILL is
Yury Sidorov wrote:
From: "Bernd Mueller" <[EMAIL PROTECTED]>
this compiles without errors. But I would like to get a hardfloat
enabled RTL again.
What host OS do you use?
I am using Windows 98SE for cross compiling.
Where arm-linux cross binutils for win32 can be downloaded?
I lost the s
On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote:
> On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
> > Maybe other way to detect SSE support exists...
>
> CPUID?
To be more precise, the way recommended by Intel:
"To make this check, execute the CPUID instruction with an argument of 1
in
- Original Message -
From: Martin Schreiber <[EMAIL PROTECTED]>
Date: Tuesday, July 10, 2007 2:44 pm
Subject: Re: [fpc-devel] win32 debugging broken in fixes_2_2?
> On Tuesday 10 July 2007 14.34, Jonas Maebe wrote:
> > The rtl checks on startup whether or not your cpu supports SSE. It
>
From: "Bernd Mueller" <[EMAIL PROTECTED]>
this compiles without errors. But I would like to get a hardfloat
enabled RTL again.
What host OS do you use?
I am using Windows 98SE for cross compiling.
Where arm-linux cross binutils for win32 can be downloaded?
Yury.
_
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote:
> Maybe other way to detect SSE support exists...
CPUID?
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
this compiles without errors. But I would like to get a hardfloat
enabled RTL again.
What host OS do you use?
I am using Windows 98SE for cross compiling.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepa
On Tuesday 10 July 2007 14.34, Jonas Maebe wrote:
> The rtl checks on startup whether or not your cpu supports SSE. It
> does so by executing an SSE instruction, catching the "illegal
> instruction" exception if it occurs and if so, setting a boolean to
> false.
>
> So just type "continue" in gdb t
From: "Martin Schreiber" <[EMAIL PROTECTED]>
Hi,
Every program compiled with fixes_2_2 rev. 8006 crashes
in gdb:
"
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute cop
From: "Bernd Mueller" <[EMAIL PROTECTED]>
Marco van de Voort wrote:
So far, I used following make call:
make CPU_TAGET=arm OS_TARGET=linux PP=ppcrossarm
OPT="-Tlinux -CX -Sg"
Try to force hardware FPU mode by using -CfFPA switch.
no, it does not help. I get exactly the same error. Perhaps
so
On 10 Jul 2007, at 14:38, Martin Schreiber wrote:
Every program compiled with fixes_2_2 rev. 8006 crashes
in gdb:
Program received signal SIGILL, Illegal instruction.
0x00402091 in SYSTEM_FPC_CPUCODEINIT ()
(gdb) bt
#0 0x00402091 in SYSTEM_FPC_CPUCODEINIT ()
#1 0x0040a504 in SYSTEM_init ()
#2
- Original Message -
From: Martin Schreiber <[EMAIL PROTECTED]>
Date: Tuesday, July 10, 2007 2:38 pm
Subject: [fpc-devel] win32 debugging broken in fixes_2_2?
> Hi,
> Every program compiled with fixes_2_2 rev. 8006 crashes
> in gdb:
> "
> GNU gdb 6.6
> Copyright (C) 2006 Free Software Fo
Hi,
Every program compiled with fixes_2_2 rev. 8006 crashes
in gdb:
"
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show c
On Thursday 05 July 2007 10.18, Jonas Maebe wrote:
> On 05 Jul 2007, at 10:15, Florian Klaempfl wrote:
> > For build related crashes it is accepted if it can be reproduced by a
> > few simple steps like get this source, compile with that command,
> > touch
> > that file, rebuild.
>
> Indeed. At lea
Marco van de Voort wrote:
So far, I used following make call:
make CPU_TAGET=arm OS_TARGET=linux PP=ppcrossarm OPT="-Tlinux -CX -Sg"
Try to force hardware FPU mode by using -CfFPA switch.
no, it does not help. I get exactly the same error. Perhaps something
changed in the build process for the
> >> So far, I used following make call:
> >>
> >> make CPU_TAGET=arm OS_TARGET=linux PP=ppcrossarm OPT="-Tlinux -CX -Sg"
> >
> > Try to force hardware FPU mode by using -CfFPA switch.
>
> no, it does not help. I get exactly the same error. Perhaps something
> changed in the build process for th
Yury Sidorov wrote:
From: "Bernd Mueller" <[EMAIL PROTECTED]>
Hello,
can anyone please tell me, how to compile the RTL for ARM-Linux since
revision 8006?
I tried to verify the bug fix 8967 (thank you Yury Sidorov) on my
system, but I am not able to compile the RTL anymore.
Adding the -Sg sw
From: "Bernd Mueller" <[EMAIL PROTECTED]>
Hello,
can anyone please tell me, how to compile the RTL for ARM-Linux
since revision 8006?
I tried to verify the bug fix 8967 (thank you Yury Sidorov) on my
system, but I am not able to compile the RTL anymore.
Adding the -Sg switch seems to be requ
Hello,
can anyone please tell me, how to compile the RTL for ARM-Linux since
revision 8006?
I tried to verify the bug fix 8967 (thank you Yury Sidorov) on my
system, but I am not able to compile the RTL anymore.
Adding the -Sg switch seems to be required to compile softfpu, but I get
now:
40 matches
Mail list logo
