[EMAIL PROTECTED] schrieb:
Hi.
Today I worked on VarArrays. Here is 64-bit friendly VariantArray patch.
Testing program is attached too. Implementation was tested on i386 and
AMD64 linux with valgrind.
The patch is contains more changes. Are they tested too? What's their
purpose?
[EMAIL PROTECTED] schrieb:
But I think that solving this cosmetic error will save many developers
hours during valgrind code checking.
.. and slows down things a lot I fear.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Walker, David schrieb:
Please use fpc-pascal for user questions.
The problem we've encountered is with packed array of boolean. The
compiler seems to pack booleans 1 per byte, whereas our old
compiler packed them one per bit, into the smallest size possible.
[...]
So, am I overlooking
[EMAIL PROTECTED] schrieb:
Finally a little question. I'am here new, do not know context and my
english is bad. But why rtl/win/sysutils.pp can depend on windows and
rtl/unix/sysutils.pp cannot depend on libc?
Because when depending on libc it's virtually impossible to build an
executable
[EMAIL PROTECTED] schrieb:
This program runed in valgrind brings on error:
program val;
var
n, e: Integer;
begin
System.Val('', n, e);
end.
==18377== Conditional jump or move depends on uninitialised value(s)
==18377==at 0x804EDC5:
SYSTEM_INITVAL$SHORTSTRING$BOOLEAN$BYTE$$LONGINT
Anton Kavalenka schrieb:
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title404 Not Found/title
/headbody
h1Not Found/h1
pThe requested URL /my_view_page.php was not found on this server./p
hr
addressApache/2.2.4 (Ubuntu) DAV/2 SVN/1.4.4 PHP/5.2.3-1ubuntu6.3
Server at
[EMAIL PROTECTED] schrieb:
Enables inserting variants arrays into variant.
Do you have a test which shows how this works? Is this delphi
compatible? Are you sure that it is enough just to allow it?
Index: rtl/inc/variants.pp
Martin Schreiber schrieb:
Hi,
Please merge the fix for Mantis 10825 (Memory error in
fpc_WideStr_Concat_multi) to fixes_2_2.
Merged.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Felipe Monteiro de Carvalho schrieb:
Hello,
I am writing scanners using plex, and I found a problem with the
current lexlib. It has a function called yywrap which will close the
input and the output, and there is no way to prevent that. I would
like to parse the same file several times, and
Vitaliy Trifonov schrieb:
I have written the updated version of the interface for ncurses library,
earlier not i had been sent raw state version
http://mantis.freepascal.org/view.php?id=10820.
Now I want to send you the updated version in which has corrected bugs,
have added a patch for a
Felipe Monteiro de Carvalho schrieb:
Indeed. Like this?
Applied slightly modified in 10498, let's see what happens ;)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Bernd Mueller schrieb:
Bernd Mueller wrote:
You chose ldrd r0, [sp] to force the SIGILL on ARMv4. According to the
docs the load address has to be double word (8 byte) aligned,
otherwise a Bus Error/Misaligned data access Error on ARMv5 would
occur. Is it save to use sp in your way?
ok,
Bernd Mueller schrieb:
Florian Klaempfl wrote:
CPUs supporting CLZ might not support PLD. Can you test if using ldrd
works?
yes, ldrd works.
Ok, my question was not very good ;) I meant, can we use ldrd, i.e. does
ldrd cause a sigill exception on ARMv4
Bernd Mueller schrieb:
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Florian Klaempfl wrote:
CPUs supporting CLZ might not support PLD. Can you test if using ldrd
works?
yes, ldrd works.
Ok, my question was not very good ;) I meant, can we use ldrd, i.e. does
ldrd cause a sigill
Bernd Mueller schrieb:
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Hello,
the ARMv5 runtime detection in rtl/arm/arm.inc fails, because the used
pld instruction does not raise SIGILL on ARM architectures ARMv4 and
below. If you would use an instruction which raises a SIGILL, it would
Bernd Mueller schrieb:
Hello,
the ARMv5 runtime detection in rtl/arm/arm.inc fails, because the used
pld instruction does not raise SIGILL on ARM architectures ARMv4 and
below. If you would use an instruction which raises a SIGILL, it would
still fail, because SignalToRunerror in
Daniël Mantione schrieb:
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Instead unaligned will simulate an unaligned load with two loads
and some rotation etc. On the ARM, where every mnemonic can rotate
Martin Schreiber schrieb:
On Sunday 02 March 2008 15.31:04 Daniël Mantione wrote:
Then the only possible way to use resourcestrings independent from the
system encoding is to compile all resource units with -Fcutf8 and to
write every assignment as widestringvar:=
Martin Schreiber schrieb:
On Sunday 02 March 2008 18.48:01 Daniël Mantione wrote:
Op Sun, 2 Mar 2008, schreef Florian Klaempfl:
What did I wrong?
I'am not sure how this could be made working just a remark: -Fcutf8
influences _only_ the interpretation of string constants when converting
them
Vinzent Hoefler schrieb:
On Wednesday 27 February 2008 11:16, Micha Nelissen wrote:
Vinzent Hoefler wrote:
On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
You can avoid cryptic language constructs in the main source code.
Or you can avoid cryptic languages altogether. :D
You mean
Daniël Mantione schrieb:
Op Tue, 26 Feb 2008, schreef Vincent Snijders:
Bernd Mueller schreef:
Hello,
the attached patch avoids misaligned data access (bus errors), during
font rendering (with the graph unit) on Arm-Linux devices.
Instead of testing for arm cpu, you could use
Ales Katona schrieb:
Paul Ishenin wrote / napísal(a):
And we need:
1. abstraction layer to use gdb or native debugger or any other debugger
2. program interface which can satisfy fpc ide, mse ide, and lazaraus ide
I agree 100% on this, unless gdb people don't accept patches at all I
GDB is
Jonas Maebe schrieb:
On 22 Feb 2008, at 09:32, Florian Klaempfl wrote:
GDB is written in C, even worse it is written in a 80th hackish style
using tons of macros. Most advanced pascal programmers can read it but
writing or even debugging is another matter.
It is not /that/ hard to debug
Helmut Hartl schrieb:
Are there any resources beside the source ?
Did you look already at:
http://svn2.freepascal.org/svn/lazarus/trunk/debugger/windebug/
?
It's a start for a fpc written debugger for lazarus by Marc Weustinek.
___
fpc-devel maillist
Michael Schnell schrieb:
We don't need wait to synchronize caches. It will be done by hardware.
Right. but waiting performed by the hardware does not take less long
than waiting performed by software :-) .
And i think synchronize cache with ram don't eat hundreads clock cycles.
In all
Did you have a look at the fmtbcd unit of fpc? I've no idea if it is
conformant with IEEE 854-1987 though.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
DarekM schrieb:
Martin Friebe pisze:
You will need to test it, but the following may also work
procedure tFlQueue.push(const tm : tNodeQueue);
var
newTemp,
lastTail,
newTail : integer;
begin
newTemp := temp;
while newTemp = fsize begin
// if it is true, every thread is going to
DarekM schrieb:
Florian Klaempfl pisze:
An if is unimportant, more important is the number of locked operations,
especially on multi core systems they might eat hundreds of clock cycles.
There are atomic operations, the should not eat much more than ordinal
INC or ADD,
If course
Jonas Maebe schrieb:
I have no idea, since I never considered adding support for ppc without
an fpu.
It shouldn't be that hard if one has a test system.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Graeme Geldenhuys schrieb:
Hi,
The following website isn't working anymore... Could somebody please
email me a copy of PocketCMD or have an alternative link I can
download if from.
http://www.symbolictools.de/public/pocketconsole/applications/PocketCMD/index.htm
Problem is that it works
Bogusław Brandys schrieb:
Just to note.
Kaspersky found Trojan-Spy.Win32.Agent.sc inside postw32.exe ? I think
it is clean file but can you confirm that ?
I checked with virustotal online,
eSafe 7.0.15.02008.01.10 suspicious Trojan/Worm
Webwasher-Gateway 6.6.2 2008.01.11
Michael Schnell schrieb:
Well, a (german) lazarus book is in the works, by CL. Work has
actually started.
Sounds good.
http://www.cul.de/lazarus.html
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Michael Schnell schrieb:
Fabio Dell'Aria wrote:
Why is so hard deide to add package support?
I suppose Lazarus would heavily use package support, as with same you
As I said before, I doubt this because it would require that all
packages are compiled separetly for every combination of fpc
Michael Schnell schrieb:
This is possible, but it simply doubles the size of the installer.
The FPC Installer ? Same could compile the RTL etc as library and/or as
a package on request (or the user project make process could do this
once it's required).
Then I don't get why people
Michael Schnell schrieb:
Then I don't get why people refuse that lazarus is recompiled and see
dyn. loaded packages as _the_ solution to this problem :)
Because the make process is just automatic and a not existing package
that needs to be created just adds compile time (once) but does not
Marco van de Voort schrieb:
Then I don't get why people refuse that lazarus is recompiled and see
dyn. loaded packages as _the_ solution to this problem :)
Is there another solution that makes it possible to compile and test a
(future) visual component before installing it and with a
Fabio Dell'Aria schrieb:
Ok but whitout the full package support many companies will never uses
Freepascal because is common think split big application in modules or
simply sell extra application plugins.
What do you think about?
The simple answer is: companies really interested in
Luiz Americo Pereira Camara schrieb:
Daniël Mantione wrote:
Op Wed, 26 Dec 2007, schreef Fabio Dell'Aria:
Why is so hard deide to add package support?
Iss only a new feature, if one do not need it can simply do not use it!
It would require to ship the rtl as dynamic library, which is
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
It would not be possible to ship the compiler and rtl as is today and
let the user/programmer decide if his project will use packages?
Or necessarily, if the change is done, the only option
in release building and maintainance.
Is also possible add it as undocumented feature (as generics in 2.2)
in the next 2.4 version and finish its implementation and testing in
the 2.6 version.
2007/12/26, Florian Klaempfl [EMAIL PROTECTED]:
Fabio Dell'Aria schrieb:
Why is not possible add
Fabio Dell'Aria schrieb:
Why is not possible add the package support as is on Delphi (using
Rtl.bpl, Vcl.bpl ...)?
Time?
Only if my project is compiled with packajes I must use all base
packages, otherwise I can continue to compile my project as today just
do Freepascal.
2007/12/26,
Martin Schreiber schrieb:
On Sunday 23 December 2007 22.12:01 Michael Van Canneyt wrote:
Now I have several possibilities:
1. I can accept Michaels verdict and surrender to use my programming
method and rewrite the affected MSEgui pieces and introduce an
incompatibility with current MSEgui
Martin Schreiber schrieb:
Hi,
Michael Van Canneyt marked my bugreport 10465 with won't fix, I would like
to discuss the issue in a broader forum.
With fixes_2_2 rev. 9006 FPC does not stream published component properties
where the component has CsSubComponent set if the property
Andrey Gusev schrieb:
Apparently, i must accept as my duty only differential diagnostic
between your and my code.
Yes, less or more :) That's the price for using OSS, see also the link
below.
I think, on stage of publishing (cutted) DM1.pas in #10457 report my
duties was ended.
The rest has
Henrick Hellström schrieb:
2. I couldn't find information about the calling convention under Win64
on the documentation page. Does FPC support the unified MSVC++ calling
convention for Win64 that is very similar to Register+stack frames?
Yes.
Does
it, like MSVC++, *only* support that
Sergei Gorelkin schrieb:
Florian Klaempfl wrote:
Help me, why do we need dfa :)?
I am not sure that we need the particular DFA from optdfa.pas, but
something to reduce conservativeness of escape analysis is definitely
needed. Otherwise, temps that are needed for just one particular case
Jonas Maebe schrieb:
On 16 Dec 2007, at 10:12, Florian Klaempfl wrote:
Sergei Gorelkin schrieb:
I am not sure that we need the particular DFA from optdfa.pas, but
something to reduce conservativeness of escape analysis is definitely
needed. Otherwise, temps that are needed for just one
Sergei Gorelkin schrieb:
Sergei Gorelkin wrote:
Florian Klaempfl wrote:
Ok, so I guess we can change this. Anybody volunteer to implement it :)?
Well, if there is no hard time schedule imposed on this, I can try.
I've started all this, after all :)
I had investigated the issue
Vinzent Hoefler schrieb:
On Thursday 13 December 2007 19:55, Mattias Gaertner wrote:
Has someone already created a unit for light weight threads?
Something like: Create a group of 4 threads named 0,1,2,3 and execute
a procedure/method?
for i := 0 to 3 do
Handle[i] :=
Mattias Gaertner schrieb:
On Fri, 14 Dec 2007 10:29:59 +0100
Michael Schnell [EMAIL PROTECTED] wrote:
Mattias Gaertner wrote:
Has someone already created a unit for light weight threads?
What do you mean by light weight threads ? How can it get lighter
than TThread, that offers close
Felipe Monteiro de Carvalho schrieb:
Hello,
I am doing some tests and trying to find out what exactly happens with
string constants. Suppose this source code:
var
AString: ansistring;
begin
AString := 'A acentuação é necessária no Português';
end;
The source is encoded in utf-8,
Mattias Gaertner schrieb:
See the OpenMP specs for more possible tuning parameters.
The pool can be extended by some of these abilities later, but for now
I only need a simple pool to demonstrate/test FPC with parallel
algorithms.
Such a thread pool can get rather tricky: first, you need some
Thorsten Engler schrieb:
Are you sure with the strings?
Yes. Any function that returns a string is supplied with one more
argument than it was declared. After calling the function, register
eax (which is used to contain the non-parameter result) is not used.
Here is a simple example:
I'am
Mattias Gärtner schrieb:
Zitat von Michael Schnell [EMAIL PROTECTED]:
Think about the alternative: It is much harder to implement the same
parallel loop with TThread. So OpenMP makes parallel loops much easier
to implement. For me this is the 'Delphi' way: Makes things easy and
readable.
Vinzent Hoefler schrieb:
On Tuesday 11 December 2007 10:04, Michael Schnell wrote:
Andrew Haines wrote:
Hi,
Is it possible to make this work:
if X 3 or 10 then ...
of course it would be shorthand for: if (X3) or (X10) then
The or operator is stronger than the operator by
DarekM schrieb:
Hi
I've notice two improvement
1. equation in SSE
# Var Zr located in register mreg0md
# Var Zi located in register mreg1md
# Var Ti located in register mreg3md
# Var Tr located in register mreg2md
# [39] Tr := Zr * Zr;
movsd%xmm0,%xmm4
mulsd%xmm0,%xmm4
Sergei Gorelkin schrieb:
Jonas Maebe wrote:
The next logical step would be returning all automated types in
parameters, which would get rid of quite a pack of implicit
finalization code.
And thoroughly break Delphi compatibility at the same time :)
Especially for assembler routines this
Sergei Gorelkin schrieb:
Florian Klaempfl wrote:
Are you sure with the strings?
Yes. Any function that returns a string is supplied with one more
argument than it was declared. After calling the function, register eax
(which is used to contain the non-parameter result) is not used.
Here
Marc Weustink schrieb:
Florian Klaempfl wrote:
Felipe Monteiro de Carvalho schrieb:
On Dec 2, 2007 1:04 AM, Marc Weustink [EMAIL PROTECTED] wrote:
From the logs I understand that there is a real managed utf8string
type (other than utf8string = type string).
No, currently utf8string = type
Marc Weustink schrieb:
Florian Klaempfl wrote:
Marc Weustink schrieb:
Florian Klaempfl wrote:
Felipe Monteiro de Carvalho schrieb:
On Dec 2, 2007 1:04 AM, Marc Weustink [EMAIL PROTECTED] wrote:
From the logs I understand that there is a real managed utf8string
type (other than utf8string
Felipe Monteiro de Carvalho schrieb:
On Dec 2, 2007 12:27 PM, Florian Klaempfl [EMAIL PROTECTED] wrote:
No. The rtl assumes that ansistrings always use the encoding used by the
system.
And what if utf-8 is the system encoding? Which is the case on many unixes.
Then ansistrings are utf-8
Jonas Maebe schrieb:
Florian Klaempfl wrote on zo, 02 dec 2007:
Felipe Monteiro de Carvalho schrieb:
Well, unix people don't seem to care about completing the cwstring unit
:)
At least this unix person didn't know those routines were mandatory,
otherwise I would have added them a long
Felipe Monteiro de Carvalho schrieb:
Hello,
Today I took a look at what would be necessary to implement
controlling the output of the widestring manager, and implementing
this looks rather trivial.
The only thing we need is a switch, to control if widestrings should
be converted to the
Martin Schreiber schrieb:
http://www.freepascal.org/mantis/view.php?id=6036
It doesn't look like that is going to be fixed any time soon. It was
reported in 2005-06-14 and still hasn't even been acknowledged!
I've no clue how it is supposed to work :)
:-)
Reference counted widestrings is
Micha Nelissen schrieb:
Florian Klaempfl wrote:
OTOH2, using no build unit but compiling with make -j is faster on multi
core systems.
if (Micha==0)
multi_threaded_fpc=0;
else
multi_threaded_fpc++;
___
fpc-devel maillist - fpc
Marco van de Voort schrieb:
Florian Klaempfl schrieb:
OTOH, this might be solved indeed in the future by splitting the rtl.
OTOH2, using no build unit but compiling with make -j is faster on multi
core systems.
Is it? Do you have numbers?
I tested once on Paul Davidson's quad core sparc
Florian Klaempfl schrieb:
Micha Nelissen schrieb:
Florian Klaempfl wrote:
Micha Nelissen schrieb:
Well, the best optimization is not needing to do something at all ;-).
So you see a way to do make cycle in one compiler call ;)?
Obviously not the three cycles, but maybe one cycle could
Micha Nelissen schrieb:
Florian Klaempfl wrote:
8 seconds instead of 1min20 is better, don't you think?
Oh great, please tell me how you accelerated make and process start
times.
Well, the best optimization is not needing to do something at all ;-).
So you see a way to do make cycle
Martin Schreiber schrieb:
On Friday 30 November 2007 11.23, Graeme Geldenhuys wrote:
Delphi 7 is 10 times faster than FPC 2.2.
8 seconds instead of 1min20 is better, don't you think?
I'll bite. :-)
What can I compile to do a speed comparison? How do I compile MSEgui
under Delphi 7?
Graeme Geldenhuys schrieb:
On 30/11/2007, Florian Klaempfl [EMAIL PROTECTED] wrote:
and the interface
method resolution clauses would be useful too.
What this?
I think he means when a class implements a inferfaces and somewhere in
the class hierarchy, there already exists a method
Martin Schreiber schrieb:
On Friday 30 November 2007 09.59, Florian Klaempfl wrote:
Martin Schreiber schrieb:
http://www.freepascal.org/mantis/view.php?id=6036
It doesn't look like that is going to be fixed any time soon. It was
reported in 2005-06-14 and still hasn't even been acknowledged
Alvise Nicoletti schrieb:
Hi... I need to cross-compile an application in a 64 bit environment,
(fully working with lazarus 0.9.23 and FPC 2.2.1), for 32 bits archs.
I tryed to follow this guide:
http://wiki.lazarus.freepascal.org/Cross_compiling
But I have the following errors:
Peter Vreman schrieb:
Hello,
I have spent some time to profile the compiler using callgrind, and was
able to improve its speed by about 20%. Attached are the changes that I
made to the sources.
I gave the patch a quick try and the speed stays the same for compiling the
compiler sources.
Graeme Geldenhuys schrieb:
For those that don't follow the Lazarus mailing list.
It was brought to our attention by a ex-Borland employee (Steve
Trefethen), that FPC contains some stolen code from Delphi. Especially
Delphi 4 5.
I wrote an answer.
L schrieb:
Freepascal, C, etc. 'Compile using packages' does not make the plugin system
language independent and portable too. I'm not sure if for example delphi
packages would ever dynamically load into an fpc executable.
You can't even use packages across different versions of the same
Leonardo M. Ramé schrieb:
Reading a post in public.mseide-msegui.talk, the mseide discussion
list, I found this:
Florian has committed the beginning of dynamic packages support.
With Dynamic Packages you mean a platform independent way of
implementing something similar to
.Dlls (or
Michael Van Canneyt schrieb:
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
Leonardo M. Ramé schrieb:
Reading a post in public.mseide-msegui.talk, the mseide discussion
list, I found this:
Florian has committed the beginning of dynamic packages support.
With Dynamic Packages you mean
Daniël Mantione schrieb:
Op Sat, 3 Nov 2007, schreef Michael Van Canneyt:
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
Leonardo M. Ramé schrieb:
Reading a post in public.mseide-msegui.talk, the mseide discussion
list, I found this:
Florian has committed the beginning of dynamic
Michael Van Canneyt schrieb:
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
Leonardo M. Ramé schrieb:
Reading a post in public.mseide-msegui.talk, the mseide discussion
list, I found this:
Florian has committed
Marco van de Voort schrieb:
- major blow up of installer size
I fail to see this ?
Because we've to deliever also the fpl's?
If it really is that of a problem, you only deliver them using a optional
package.
Who will maintain this?
___
fpc-devel
Michael Van Canneyt schrieb:
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
On Sat, 3 Nov 2007, Florian Klaempfl wrote:
Leonardo M. Ramé schrieb:
Reading a post in public.mseide
Marco van de Voort schrieb:
Marco van de Voort schrieb:
- major blow up of installer size
I fail to see this ?
Because we've to deliever also the fpl's?
If it really is that of a problem, you only deliver them using a optional
package.
Who will maintain this?
The person that will
Marco van de Voort schrieb:
[ Charset ISO-8859-1 unsupported, converting... ]
Because we've to deliever also the fpl's?
If it really is that of a problem, you only deliver them using a optional
package.
Who will maintain this?
The person that will otherwise have to explain to newbies how to
Florian Klaempfl schrieb:
Marco van de Voort schrieb:
[ Charset ISO-8859-1 unsupported, converting... ]
Because we've to deliever also the fpl's?
If it really is that of a problem, you only deliver them using a optional
package.
Who will maintain this?
The person that will otherwise have
Marco van de Voort schrieb:
Florian Klaempfl schrieb:
Ok, I'll ask next time this person to spent the weekend to fix windows
installer scripts and assign to it the still open web download page,
installer and install package bugs.
I was never for the download system in the first place remember
ik schrieb:
Hello
I'm attaching here diff files for errorhe.msg and errorheu.msg files.
I think that some of the translation are prior to 2.2.0 (I haven't
translated for a while).
Thx, applied.
___
fpc-devel maillist -
Felipe Monteiro de Carvalho schrieb:
On 11/1/07, Florian Klaempfl [EMAIL PROTECTED] wrote:
No.
Edit compiler/msg/errore.msg
make msg
Good =) That would have been a bit clumsy.
May I already add the information about this option to trunk or should
we wait before it's fully working?
Add
Felipe Monteiro de Carvalho schrieb:
Hello,
I was taking a look at how to add new target options to the compiled
help screen (the one that appears when you just type fpc).
Am I correct to assume that one must edit the compiler/msgtxt.inc
file, add the new lines and then correct all the
Yury Sidorov schrieb:
From: Felipe Monteiro de Carvalho [EMAIL PROTECTED]
On 11/1/07, Marco van de Voort [EMAIL PROTECTED] wrote:
It seems that when you branch, in the instruction you can encode if the
instructionset of the target is thumb or not.
So, currently fpc set's all branches to use
Olivier Coursiere schrieb:
Applied.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Olivier Coursiere schrieb:
Thanks, commited in 8994.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Mattias Gaertner schrieb:
Is it possible to use TTranslateStrings = type TStrings?
I ask because, the compiler allows it, but stops later with only this
message:
lcl/interfaces/gtk2/interfaces.pas(1,1) Fatal: Compilation aborted
Question:
Is it allowed to use
NewClass = type SomeClass;
Mattias Gaertner schrieb:
On Sun, 21 Oct 2007 08:36:24 +0200 (CEST)
Daniël Mantione [EMAIL PROTECTED] wrote:
Op Sun, 21 Oct 2007, schreef Michael Van Canneyt:
.ppu file format is something so general and
commonly used by (Free) Pascal programmers that
it should become part of our RTL.
Mattias Gaertner schrieb:
On Sun, 21 Oct 2007 14:22:30 +0200 (CEST)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
[...]
Well, the ppu file is divided in blocks; Each block has a type
and a size. If you don't know a block, you can 'skip' it.
(If memory serves me right, of course)
If the
L schrieb:
I wrote:
In KOL, Kladov also returns a zero with his Str2Int function if string is
bad.
You may be thinking.. but what if the string really is a zero and we want to
know that it is?
Well then we can do this:
if (s = '0') or (StrToInt(s) 0) then writeln('S is an integer');
if
Micha Nelissen schrieb:
Peter Vreman wrote:
There is a good reason for that the unreachable code is a warning: The
compiler _changes_ your
code by removing the if-branch. When it is a hint the compiler only
has recognized a pattern, but
it does not modify anything.
It changes it, but
Jonas Maebe schrieb:
On 14 Oct 2007, at 22:06, Daniël Mantione wrote:
I can follow your reasoning why you want the dead code, but on the other
hand the warning is there with good reason.
Maybe it would better be a hint.
With the same reasoning you could make every warning a hint.
Joao Morais schrieb:
Daniël Mantione wrote:
The warning is fixable: Remove the superfluous check.
All,
a new contribution to this theme. What about this warning:
{$mode objfpc}
uses sysutils;
function testresult: boolean;
begin
raise exception.create('foo');
end;
begin
Michael Schnell schrieb:
Jonas Maebe wrote:
On 02 Oct 2007, at 21:52, Daniël Mantione wrote:
Of course not, because the sizes of the floating point types is
defined by the IEEE 754 standard. On x86_64, you will have exactly the
same types as on i386: single (32-bit), double (64-bit) and
Michael Schnell schrieb:
In some Win64 beta MS disabled even the use of the FPU. Because this
went too far, MS marked the use of the FPU as deprecated.
OK, for a Beta this might be OK (and done supposedly due to the OS
failing to manage the FPU registers correctly), but the final product
601 - 700 of 1078 matches
Mail list logo
