Martin Frb via fpc-devel schrieb am Mo.,
6. Mai 2024, 14:11:
> Maybe of interest?
>
> The include file {$i ascdef.inc} is used from unit Windows with
> {$calling stdcall}
> in effect.
>
> Most functions in it therefore don't have "stdcall". But some do. Is
> that known/wanted/...?
>
> Similar in
Martin Frb via fpc-devel schrieb am Fr.,
3. Mai 2024, 12:13:
> In case it goes ahead, I am trying to thing of what would be needed
> Can anyone think of any feature for Pascal properties that is not
> covered by the below?
>
A property can be marked "default". Currently only array
Am 29.04.2024 um 08:42 schrieb J. Gareth Moreton via fpc-devel:
Aah, partially answered. It's not supported in 3.2.2, but there is
better support for it in the trunk.
You had me worried there for a moment that someone regenerated the
makefiles with an older version of fpcmake... ^^'
J. Gareth Moreton via fpc-devel schrieb am
Sa., 27. Apr. 2024, 10:00:
> You've piqued my interest. I currently only have the ability to develop
> on aarch64-linux (Raspberry Pi 400), but I'm curious to know if I can get a
> version of Windows to run on it, even if the performance will be very
Bart via fpc-devel schrieb am Do., 25.
Apr. 2024, 11:48:
>
> > Then declare a Copy management operator in the record. Unlike an
> assignment operator these *must* be part of the record, thus the same rules
> are applied for the same type everywhere unlike for operator overloads. See
> also
Bart via fpc-devel schrieb am Mi., 24.
Apr. 2024, 11:59:
> Overloading the := (assignment) operator for equal types is forbidden.
> Out of curiosity I would like to know why that is?
>
If there exists a built-in operator then overloading that operator is
forbidden to avoid confusion when what
Am 29.01.2024 um 21:56 schrieb Michael Van Canneyt via fpc-devel:
I didn't say I cannot think of a legitimate use. I said it does not make
sense to me, as in
"I don't understand what people try to accomplish with this modifier".
Unfortunately I still don't understand after your explanation
Am 29.01.2024 um 21:18 schrieb Michael Van Canneyt via fpc-devel:
On Mon, 29 Jan 2024, Sven Barth via fpc-devel wrote:
Am 28.01.2024 um 12:14 schrieb Michael Van Canneyt via fpc-devel:
2)
Is there, or has there once been?
(found in the synedit highlighter)
final
final comes after
Am 28.01.2024 um 12:14 schrieb Michael Van Canneyt via fpc-devel:
2)
Is there, or has there once been?
(found in the synedit highlighter)
final
final comes after virtual/dynamic. Its supposed to stop you from
overriding
a method. Which is a bit strange because then you should not
Am 24.01.2024 um 23:29 schrieb Martin Frb via fpc-devel:
https://www.freepascal.org/docs-html/ref/refsu3.html
Is this list complete/correct?
1)
It lists bitpacked, but
program foo; var bitpacked: integer; begin end;
gives an error.
I thought modifiers can be used as var names?
Martin Frb via fpc-devel schrieb am Fr.,
29. Dez. 2023, 20:38:
> fpc 3.2.3
> The below prog prints 3 times: 11, -1 (signed values)
>
> https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1
>
> Free Pascal also supports the ByteBool, WordBool, LongBool and QWordBool
>
Am 29.11.2023 um 09:36 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
I hate to point fingers, but there's a 0-byte file named "HEAD" in the
repository, which causes git to throw a tantrum sometimes - it was
introduced in the following commit:
commit
drichards--- via fpc-devel schrieb am Sa.,
11. Nov. 2023, 08:22:
> I am getting an incorrect type error at line 889 column 33 in
> compiler/options.pas. This is the , following the parameter More to the
> function Copy. More is defined as a String. I do not understand why the
> function
Michael Van Canneyt via fpc-devel schrieb
am Do., 20. Juli 2023, 19:24:
>
>
> On Thu, 20 Jul 2023, Martin Frb via fpc-devel wrote:
>
> > For const param, it is well documented that the value (that includes the
> > variable that is passed) must not be changed.
> >
> > But for "var param"?
> >
> >
J. Gareth Moreton via fpc-devel schrieb am
Mi., 19. Juli 2023, 19:53:
> Hi everyone,
>
> So I've come across a bit of awkwardness with the compiler. I'm not
> sure if it's a well-defined rule that I've overlooked, but in a
> for-loop, you can't use a 64-bit control variable when compiling for
>
Martin Frb via fpc-devel schrieb am So.,
26. März 2023, 16:50:
> It also would fall short, if ever Fpc did what Delphi did:
> {$ZEROBASEDSTRINGS }
> Though, maybe that is a "wont ever happen".
>
FPC supports that directive since at least 3.2.0 (though apparently it was
forgotten to be
Am 26.03.2023 um 13:30 schrieb Martin Frb via fpc-devel:
3.2.3 and 3.3.1 on Win 64bit
Trying a generic linked list.
So the specialized class must have an entry for the "next" element.
And that entry is of the same type as the class itself.
Now at first, this seems to be not possible using
Martin Frb via fpc-devel schrieb am Fr.,
3. März 2023, 12:55:
> To me the below behaviour appears inconsistent.
> But before I file a bug, I want to double check, if maybe this is
> intention
>
> Tested with 3.2.3 and 3.3.1
>
> Apparently
> - when the generic TGen is compiled, it does check
J. Gareth Moreton via fpc-devel schrieb am
Mi., 1. März 2023, 12:25:
> My peephole optimisations mostly save only a handful of cycles each time
> which probably won't add up to much for a relatively short test. The
> most major optimisation I can think of, although I'm not quite sure when
> it
Kostas Michalopoulos via fpc-devel schrieb
am Mi., 22. Feb. 2023, 10:37:
> > Because Delphi doesn't have them and when constraints were implemented
> > they were implemented for Delphi compatibility.
>
> Can they be added? The original announcement ~13 years ago mentioned
> that those could be
Hairy Pixels via fpc-devel schrieb am So.,
19. Feb. 2023, 03:54:
> As a follow up to my other question, why doesn’t FPC support more types
> for generic type constraints, like Pointer, Integer, String etc...?
> Especially since we have implicit function specialization now allowing the
> user to
Ondrej Pokorny via fpc-devel schrieb am
Do., 2. Feb. 2023, 12:09:
> Delphi cannot do it. FPC rocks!
>
> The only disadvantage is that you get a FreeAndNil copy for every type
> you pass into the parameter (?)
>
> Do we want to change it in SysUtils? :)
>
As you might have noticed you need to
Ondrej Pokorny via fpc-devel schrieb am
Do., 2. Feb. 2023, 10:06:
> On 02.02.2023 07:42, Sven Barth via fpc-devel wrote:
> > The case when you *need* a constant reference. Case in point: the
> > passing of TGuid in IInterface.QueryInterface. Delphi code relies on
> >
Adriaan van Os via fpc-devel schrieb am
Do., 2. Feb. 2023, 09:57:
> Sven Barth wrote:
> > Adriaan van Os via fpc-devel > <mailto:fpc-devel@lists.freepascal.org>> schrieb am Do., 2. Feb. 2023,
> > 02:47:
> >
> > Sven Barth via fpc-devel wrote:
> &
Adriaan van Os via fpc-devel schrieb am
Do., 2. Feb. 2023, 02:47:
> Sven Barth via fpc-devel wrote:
>
> > There is no full documentation for that parameter modifier (someone
> > might want to file a bug report for that), but the documentation for
> > “const” (
> >
Am 02.02.2023 um 02:09 schrieb Hairy Pixels:
On Feb 2, 2023, at 4:38 AM, Sven Barth wrote:
Which types are passed by-value or by-reference when using const is determined
by the size of the record and the types of the fields based on whatever the
corresponding ABI defines (e.g. the x86_64
Am 01.02.2023 um 11:30 schrieb Bart via fpc-devel:
I thought that constref would be OK for that (the word constref
suggests to me tah the paramter will be treated (by me) to be a
constant, and that it shall be passed by reference in all cases,
whereas with a const parameter the compiler decides
Am 01.02.2023 um 15:40 schrieb Hairy Pixels via fpc-devel:
On Feb 1, 2023, at 8:27 PM, Michael Van Canneyt via fpc-devel
wrote:
That's exactly what Adriaan is saying. With const the compiler can choose.
With constref, you force it not to copy. But this is not so efficient for
small
Am 13.01.2023 um 01:05 schrieb Bart via fpc-devel:
The issue is indeed the conversion from UnicodeString to WideString
which is not allowed for a var/out parameter. That the compiler doesn't
use the error “Call by var for arg no. 3 has to match exactly: Got
"UnicodeString" expected "WideString"”
Am 11.01.2023 um 23:58 schrieb Bart via fpc-devel:
Given the following program (an excerpt form a test program for a
bugreport about the fpwidestring unit):
===
program test;
{$codepage utf8}
{$mode objfpc}
{$h+}
uses
FpWideString;
var
WSource: WideString = 'source';
USource:
Michael Van Canneyt via fpc-devel schrieb
am Sa., 7. Jan. 2023, 12:46:
>
>
> On Sat, 7 Jan 2023, Mattias Gaertner via fpc-devel wrote:
>
> > On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
> > Michael Van Canneyt via fpc-devel
> > wrote:
> >
> >> [...]
> >> For those that wish to help in testing:
> >>
Wayne Sherman schrieb am Mi., 4. Jan. 2023, 01:13:
> On Tue, Jan 3, 2023 at 12:17 AM Sven Barth wrote:
> >> 1) How do I generate the fpmake.pp file? Or is it created by manual
> coding?
> >
> > This is created manually and is *the* source for how to build a package.
Wayne Sherman via fpc-devel schrieb am
Di., 3. Jan. 2023, 07:36:
> Each package directory (./fpc-source/packages/some-package/) typically
> has these files:
>fpmake.pp (where does this come from?)
>Makefile (this is generated by FPCMake?)
>Makefile.fpc (config file for FPCMake to
Am 20.12.2022 um 15:08 schrieb Martin:
Ok, I don't know too much about the whole initialization
But on the off chance of triggering some ideas, I throw in a couple of
my thoughts
On 19/12/2022 07:42, Sven Barth wrote:
Am 07.07.2018 um 15:04 schrieb Martin:
So (guessing) the original
Ondrej Pokorny via fpc-devel schrieb am
Mo., 19. Dez. 2022, 08:30:
> On 19.12.2022 07:42, Sven Barth via fpc-devel wrote:
> > The RTL assumes that it does not have to deal with threads during the
> > initialization of the System unit. So even if the symptom of the cra
Am 07.07.2018 um 15:04 schrieb Martin:
So (guessing) the original issue may be due to the debugger. The
debugger interrupts the target early on. And that does create a thread
in the target.
If such an external thread happens, would fcp execute the code in
question?
This is likely to be the
Am 16.12.2022 um 02:02 schrieb J. Gareth Moreton via fpc-devel:
The purity analysis process is very dependent on the node tree being
as clean as possible, and so depends on a fair few merge requests that
have not yet been approved. I'm guessing Florian and Jonas and others
are somewhat busy,
Am 14.12.2022 um 12:15 schrieb J. Gareth Moreton via fpc-devel:
To better explain how purity analysis currently works (I'm sure
there's a better name than "purity analysis"), it takes a copy of the
unoptimised node tree (this is the same as the tree used for inline,
and for a space saving,
J. Gareth Moreton via fpc-devel schrieb am
Di., 13. Dez. 2022, 22:09:
> The next big milestone that I want to achieve is to make this a pure
> function:
>
> procedure int_str_unsigned(l:longword;out s:shortstring); pure;
> var
>m1 : longword;
>pcstart,
>pc2start,
>pc,pc2 : pchar;
Ondrej Pokorny via fpc-devel schrieb am
Di., 29. Nov. 2022, 11:39:
> Am 29.11.2022 um 11:08 schrieb Sven Barth via fpc-devel:
>
> J. Gareth Moreton via fpc-devel schrieb
> am Di., 29. Nov. 2022, 10:09:
>
>> Surely that's a bug in the comparison functions
J. Gareth Moreton via fpc-devel schrieb am
Di., 29. Nov. 2022, 10:09:
> Surely that's a bug in the comparison functions that should be fixed and
> not something that can be blamed on introsort. If a comparison function
> is faulty, then pretty nuch any sorting algorithm can be considered to
>
Stefan Glienke via fpc-devel schrieb am
Mo., 28. Nov. 2022, 12:39:
> In Delphi that would be the
> https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.GetTypeKind
> intrinsic - I could not find that one in the 3.2.0 feature list.
>
That one is also supported since 3.2.0, though it
J. Gareth Moreton via fpc-devel schrieb am
Mo., 28. Nov. 2022, 11:01:
> Just want to clarify something... if a type is managed, can it be safely
> typecast to a pointer in all instances and on all platforms? (The
> purpose being so if I wanted to swap two items, so there's no overall
> change in
Stefan Glienke via fpc-devel schrieb am
Mo., 28. Nov. 2022, 00:20:
> Probably not unless FPC has something similar to
>
> https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.IsManagedType
> (that function among a few others is compiletime evaluated).
>
It's supported since 3.2.0:
J. Gareth Moreton schrieb am Do., 10. Nov.
2022, 23:26:
> Funny how you mention "black box" because recently there was a news
> article about scientists increasingly not understanding why machine
> learning is working the way it is with apparent patterns of emergent
> behaviour.
>
That and
Am 10.11.2022 um 19:10 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
This has been something that has been on my mind for a while now, but
with my increasingly more complex optimisations being developed for
the Free Pascal Compiler and the code becoming an ever bigger
spiderweb of
J. Gareth Moreton via fpc-devel schrieb am
Mo., 24. Okt. 2022, 13:52:
> That's useful - thank you. Michael Van Canneyt mentioend he updated the
> documentation for this - where is this usually located? It's not here,
> for example: https://www.freepascal.org/docs-html/ref/refsu45.html
That is
J. Gareth Moreton via fpc-devel schrieb am
Mi., 28. Sep. 2022, 19:44:
> Granted I do think the compiler raising an internal exception is rather
> unclean... possibly not as bad as in internal error but still something
> undesirable.
>
Well, if you want to hunt down these issues, be my guest;
Richard Hyman via fpc-devel schrieb am
Do., 22. Sep. 2022, 09:00:
>
> 1. Does FPC compile natively for the ARM Macs, specifically an M1? Docs I
> found do not directly answer this question (he's thinking about purchasing
> an M1 Mac mini).
>
This is supported since 3.2.2.
2. Does FPC provide
Am 15.09.2022 um 14:32 schrieb Martin Frb via fpc-devel:
https://gitlab.com/freepascal.org/fpc/source/-/issues/39904
On top of adding the functions in the interface to the dwarf info, it
would be great if the compiler could also add some sort of link to the
underlaying TObject.
So the
Joost van der Sluis via fpc-devel schrieb
am Di., 5. Juli 2022, 22:37:
>
>
>
> Op 05-07-2022 om 08:39 schreef Sven Barth via fpc-devel:
> > Joost van der Sluis via fpc-devel > <mailto:fpc-devel@lists.freepascal.org>> schrieb am Di., 5. Juli 2022,
>
Joost van der Sluis via fpc-devel schrieb
am Di., 5. Juli 2022, 00:17:
>
> But my real issue is this: on Windows, using the internal linker, this
> procedure is also omitted *with* Dwarf debug-data. As you implied.
>
> The problem is, though, that the CFI-information (the FDE) is not
> omitted.
Am 04.07.2022 um 19:52 schrieb Joost van der Sluis via fpc-devel:
Hi all,
I have a very small application, see below. One procedure is not
called at all.
But when I compile with
ppcx64 -XX -CX testcfi.pp
The P$TESTCFI_$$_NEVERCALLES symbol is still in the executable.
On Windows (internal
Hairy Pixels schrieb am Fr., 24. Juni 2022, 03:45:
>
>
> > On Jun 23, 2022, at 11:52 PM, Sven Barth
> wrote:
> >
> > As you can see at the end (see below) it falls back to 3.2.2 at the end.
> What commands did you execute to build FPC itself?
> >
>
>
Hairy Pixels via fpc-devel schrieb am Do.,
23. Juni 2022, 04:08:
> I usually solve this by deleting the units folder but for some reason
> after pulling from main it simply won’t build. Can anyone explain why the
> PPU version is wrong? It’s all building from the same source directory so
> the
Am 03.06.2022 um 14:32 schrieb Marco van de Voort via fpc-devel:
There was a question about $modeswitch ISOIO on stack overflow, and
specially why get() and put() are not part of it.
The documentation about this switch seems very sparse. As far as I can
see it is mostly the lookahead and
Hairy Pixels schrieb am Mo., 13. Juni 2022, 05:30:
> Me and Sven had planned this a couple years ago and I finally got around
> to it this weekend since it was pretty trivial. The reason for this being
> we wanted a way to disable the generic keywords in ObjFPC mode. The
> solution is to
Am 27.05.2022 um 04:41 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
Building the compiler with -dDEBUG_NODE_XML got broken recently:
C:/lazarus/fpc/3.2.0/bin/x86_64-win64/ppcx64.exe -Ur -Xs -O2 -n
-Fux86_64 -Fusystems
Am 26.12.2021 um 02:16 schrieb Blaise--- via fpc-devel:
Important design points:
1) Applying round brackets to instances does not collide with the
existing syntax;
2) Naturally, helpers are able to turn helpees into functors;
3) Operator () cannot be applied to types -- that would clash with
Am 25.12.2021 um 20:22 schrieb Blaise--- via fpc-devel:
The attached modeswitch_closures.patch introduces {$modeswitch
Closures}; it is included in {$mode Delphi}.
There is a distinction between anonymous routines (defined in-place,
without a name) and closures (capture the context they are
Am 24.12.2021 um 02:27 schrieb Blaise--- via fpc-devel:
DCC allows the subj (provided that the class type is known at compile
time), FPC does not.
The attached init_methptr_with_classmeth.patch implements this feature.
---8<---
type C = class
class procedure Foo;
end;
class
Am 22.12.2021 um 19:16 schrieb Blaise--- via fpc-devel:
1) The attached metaclass_meth_to_procvar-1.patch fixes the internal
error reported for:
[ICE] Assigning class methods, accessed via a class reference type, to
incompatible procvars
---8<---
type C = class
class procedure
Am 23.12.2021 um 19:13 schrieb Blaise--- via fpc-devel:
Subj silently produces invalid codegen:
---8<---
var Z: procedure of object;
type R = record
procedure Foo;
end;
procedure R.Foo; begin end;
type O = object
procedure Foo;
end;
procedure O.Foo; begin end;
type C = class
Am 21.12.2021 um 21:37 schrieb Blaise--- via fpc-devel:
1) The following three routines:
pdecsub.pas!parse_parameter_dec
pdecvar.pas!maybe_parse_proc_directives
ptype.pas!read_named_type\procvar_dec
create a dummy typesym for the procdef, for the sole purpose of
invoking
Stefan Glienke via fpc-devel schrieb am
Di., 19. Apr. 2022, 12:38:
> If you want to zero small records more efficiently it might be better
> using Default(t) for that and looking at optimizing the code the compiler
> generates for that as it seems it produces an empty temp variable which it
>
Am 16.04.2022 um 22:35 schrieb Wayne Sherman via fpc-devel:
Tested with fpc 3.3.1 trunk (as of 2022-Mar-12) and 3.2.2 stable.
Ubuntu 20.04 64-bit
Good compile time error checking is one of the wonderful things about
Pascal. But some char array and shortstring assignments which are not
size
Florian Klämpfl via fpc-devel schrieb am
Sa., 16. Apr. 2022, 21:00:
>
>
> > Am 16.04.2022 um 01:26 schrieb J. Gareth Moreton via fpc-devel <
> fpc-devel@lists.freepascal.org>:
> >
> > Hi everyone,
> >
> > This is something that sprung to mind when thinking about code speed and
> the like, and
J. Gareth Moreton via fpc-devel schrieb am
Sa., 16. Apr. 2022, 01:33:
> Actual Pascal calls to FillChar would not change in any way and so
> theoretically it won't break existing code. The only drawback is that
> the intrinsic and the internal System functions would have to be named
> the same
Benito van der Zander via fpc-devel
schrieb am Sa., 16. Apr. 2022, 15:43:
> Hi,
>
> it could always inline it.
>
> For small sizes do that mov and for large sizes do rep stosb on x86. It is
> very fast nowadays. Faster than FillChar on my Intel laptop. (except for
> mid sizes like 128 bytes)
>
Am 06.04.2022 um 20:32 schrieb J. Gareth Moreton via fpc-devel:
Another problem... I've tried to declare an ADDPD intrinsic as follows:
function x86_addpd(r0, r1: __m128d): __m128d; [INTERNPROC:
fpc_in_x86_addpd];
I thought using __m128d instead of __m128 was fairly logical since
ADDPD
BogDan schrieb am Sa., 12. Feb. 2022, 13:23:
> Hi,
>
>
> On Saturday, February 12, 2022, 11:23:40 AM GMT+2, Sven Barth <
> pascaldra...@googlemail.com> wrote:
>
>
> BogDan via fpc-devel schrieb am Sa., 12.
> Feb. 2022, 10:18:
> > Also, everything that i
BogDan via fpc-devel schrieb am Sa., 12.
Feb. 2022, 10:18:
> Also, everything that is not used by the application it should be stripped
> by the linker (if it has one). Again I'd like to highlight that I'm new to
> fpc, last time I used pascal it was over 20 years ago :) .
>
The linker can only
BogDan schrieb am Fr., 11. Feb. 2022, 22:20:
> Hi,
>
>
> Thanks a lot for your quick reply.
>
> Adding ihxutil to path fixed the problem.
> But the size problem is stil there, a simple 2 lines of code "begin;
> end." generates over 32k of code. That code should not generate more than
> 8 bytes
Tomas Hajny via fpc-devel schrieb am Fr.,
11. Feb. 2022, 17:24:
> On 2022-02-11 14:14, Sven Barth via fpc-devel wrote:
> > BogDan via fpc-devel schrieb am Fr.,
> > 11. Feb. 2022, 11:09:
>
> .
> .
> >> It seems is an IHX format not tzx
> >> Also the
BogDan via fpc-devel schrieb am Fr., 11.
Feb. 2022, 11:09:
> Hello,
>
> According to https://wiki.freepascal.org/Z80 fpc is able to compile
> pascal code for z80.
> Sadly I'm a newbie on fpc, therefore I have a few questions:
>
> 1. I changed a bit the build script from
>
Am 11.02.2022 um 03:59 schrieb Karoly Balogh:
Hi,
On Thu, 10 Feb 2022, Sven Barth via fpc-devel wrote:
Thorsten Otto via fpc-devel schrieb am
Do., 10. Feb. 2022, 15:47:
Cause in the variant you mentioned where would the allocated memory be
stored?
I'm not that familiar with ObjectGEM yet
Am 10.02.2022 um 19:22 schrieb Thorsten Otto via fpc-devel:
On Donnerstag, 10. Februar 2022 19:13:15 CET Sven Barth via fpc-devel
wrote:
> And how does one work with the created instance? How does one
release it? Do
> you have an example for that?
Maybe some examples of ObjectGEM
Thorsten Otto via fpc-devel schrieb am
Do., 10. Feb. 2022, 15:47:
> On Donnerstag, 10. Februar 2022 14:21:54 CET Sven Barth via fpc-devel
> wrote:
>
> > Anything else does not make sense.
>
> >
>
> > Cause in the variant you mentioned where would the allocated me
Thorsten Otto via fpc-devel schrieb am
Do., 10. Feb. 2022, 13:00:
> - when constructing objects, ObjectGEM uses contructs like
>
> new(PGroupBox, init(...)
>
> Such constructs are not supported by FreePascal, you have to assign the
> result to some variable (i think that is also an
Thorsten Otto via fpc-devel schrieb am
Mo., 7. Feb. 2022, 13:00:
> In the long term, it would be nice to have some automatic selection of the
> correct libraries. Otherwise it will not be possible to produce 68k
> binaries with a compiler that was compiled for 68020, since that will still
> pull
Am 29.01.2022 um 09:24 schrieb Thorsten Otto via fpc-devel:
On Freitag, 28. Januar 2022 20:21:03 CET Karoly Balogh wrote:
> a fixed GAS/LD support would be nice, of
> course.
Yes, but currently i'm a bit lost here. Since that combination
currently does not support "smart linking", i guess
Am 28.01.2022 um 18:04 schrieb Thorsten Otto via fpc-devel:
The error number comes from def_system_macro, when it is invoked with
an empty name. The crash seems to happen in system.o, during
initalization. The external name of the procedure is
'SYSTEM_$$_RECORDRTTI$POINTER$POINTER$TRTTIPROC'
Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 14:45:
> >If I'm not mistaken, GCC for
>
> >Atari used to have some tool like this? Brownout, maybe?
>
>
>
> Yes, but i never used that "brown" tool. For one, i don't like its
> confusing naming convention (depending on gcc version, it
Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 13:03:
> On Dienstag, 25. Januar 2022 12:22:33 CET Karoly Balogh wrote:
>
> > Hi,
>
> >
>
> > On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
>
> > > Yes, a.out support (which is used on Atari) has been dropped in 2.31.
>
> > >
Thorsten Otto via fpc-devel schrieb am
Di., 25. Jan. 2022, 10:54:
> > the prefix $CPU-$OS is just the default prefix for every cross
>
> > compiling, if you need an other, you can supply it with e.g.
>
> > -XPm68k-atari-mint-
>
>
>
> Yes, found that already. But there is also at least one
Mattias Gaertner via fpc-devel schrieb am
Fr., 14. Jan. 2022, 10:01:
> On Fri, 14 Jan 2022 07:32:59 +0100
> Sven Barth via fpc-devel wrote:
>
> >[...]
> > Just FYI what Delphi writes in their documentation (
> >
> https://docwiki.embarcadero.com/RADStudio/
Am 14.01.2022 um 05:20 schrieb Ben Grasset via fpc-devel:
On Thu, Jan 13, 2022 at 9:20 AM Travis Siegel via fpc-devel
wrote:
I wasn't aware of the whole MS not supporting the FPU thing, that was
the missing puzzle piece.
It's not a realistic concern in actuality. There's a reason
Am 14.01.2022 um 03:15 schrieb Ben Grasset via fpc-devel:
On Thu, Jan 13, 2022 at 9:48 AM Nikolay Nikolov via fpc-devel
wrote:
What do other win64 compilers do? Do they generate x87 FPU code
for 64-bit Windows?
Yes. Given the following:
#include
long double do_three(long double
Am 12.01.2022 um 19:26 schrieb Martin Frb via fpc-devel:
On 12/01/2022 18:48, Sven Barth via fpc-devel wrote:
[2] From the users view "random", in that the user can not
predict all
the factors that will affect the selection.
Currently the user must be prepared for
Martin Frb via fpc-devel schrieb am Mi.,
12. Jan. 2022, 18:06:
> On 12/01/2022 17:31, Tomas Hajny via fpc-devel wrote:
> > On 2022-01-12 16:03, Martin Frb via fpc-devel wrote:
> >>
> >>
> >> But, if any change to the code (not even necessarily a functional
> >> change) would allow the compiler
Christo Crause via fpc-devel schrieb am
Fr., 31. Dez. 2021, 16:58:
> On Fri, Dec 31, 2021 at 4:41 PM Marco Borsari via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
>
>> Hi,
>> on Linux with FPC 3.2.2 the executable size of programs compiled with
>> fpc -On -a (tried with n 2 or 4)
>> is
Ben Grasset via fpc-devel schrieb am So.,
19. Dez. 2021, 08:33:
> To be very clear, to me, this is absolutely nothing more than just a
> matter of building the compiler completely normally. It takes like two
> minutes all-in. I don't really get why the person who uploads the 32-bit
> Windows
Martin Frb via fpc-devel schrieb am Do.,
9. Dez. 2021, 00:15:
> https://gitlab.com/freepascal.org/fpc/source/-/issues/39459
> You wrote
> >> No, this can not and this will never work. When a generic parameter has
> a constraint that constraint *must* be adhered to and a forward
> declaration is
Gennady Agranov via fpc-devel schrieb am
Sa., 18. Sep. 2021, 01:11:
> Hi,
>
> I have Delphi RTTI code that takes record's type info, finds method and
> calls it...
>
> The code does not seem to work in 3.2.0 (SEGV)
>
> Should it work?
>
> Should I try 3.2.2 or there are other ways to call record
Am 08.09.2021 um 06:33 schrieb Gennady Agranov via fpc-devel:
Hi,
linker complains about undefined symbol .Lj3016
I checked *.s files and found that one file has no label .Lj3016 but
has following line:
leaq .Lj3016(%rip),%rdx
Am I correct that that this *.s file should also
Bart via fpc-devel schrieb am Di., 24.
Aug. 2021, 06:31:
> On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel
> wrote:
>
> > Just move common.dll from SysWOW64 to system32. The file is placed
> wrongly
> > by some installer.
>
> If I understand Tomas correctly then that would not make
Am 23.08.2021 um 19:33 schrieb Bart via fpc-devel:
On Mon, Aug 23, 2021 at 7:16 PM Bart wrote:
I tried to build with only the path to the starting compiler in %PATH%:
PATH /devel/fpc/3.2.2/bin/i386-Win32
make clean
make all OPT=...
That failed on make clean:
That error goes away if I add
Am 08.08.2021 um 10:06 schrieb Florian Klämpfl via fpc-devel:
Am 07.08.2021 um 16:59 schrieb Mattia Verga via fpc-devel
:
Fedora has recently moved to using glibc 2.34. That caused Free Pascal
Compiler to stop building with the following output:
/usr/bin/ld:
NetSpirit via fpc-devel schrieb am Fr.,
30. Juli 2021, 15:37:
> This code gives distinct results when compiled for Win32 and Win64
> - Win32: 49744125
> - Win64: 49744124.999
>
> procedure Test;
> var
> D: Double;
> begin
> D := 3 * (exp(3 * ln(255)));
> WriteLn('Result: ' +
Am 04.07.2021 um 12:59 schrieb J. Gareth Moreton:
Okay, okay. Not too harsh, please.
Better to stop the intention of modifying defs before you can get a
taste for them. :P
I feel I don't yet know enough about defs and generics to properly fix
this bug, only that the defs used aren't
1 - 100 of 2162 matches
Mail list logo