>Gesendet: Samstag, 30. Juni 2018 um 13:34 Uhr
>Von: "Florian Klämpfl"
Sorry for the late reply.
>> In an ideal world, either the language would not let you write code that has
>> random behavior or the compiler would enforce this.
>
>Compile with trunk and -Sew and you get this behavior.
>Gesendet: Samstag, 30. Juni 2018 um 10:54 Uhr
>Von: "Michael Van Canneyt"
>> Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
>>> The variables we're talking about here *are* initialized.
>
Bit lost here. Maybe A and B are setup, but not result. And the apparent re-use
of tmp vars also
Gesendet: Donnerstag, 28. Juni 2018 um 20:06 Uhr
Von: "Jonas Maebe"
An: fpc-devel@lists.freepascal.org
Betreff: Re: [fpc-devel] Managed Types, Undefined Bhaviour
On 28/06/18 18:45, Willibald Krenn wrote:
>
> type Vector = array of integer;
> function DoSomething (len: longint): Vector
Dear FPC developers,
Since I am unable to provide a comment on bug report #33912 itself, I figured I had but one option to move the discussion here. Basically, I don't follow the reasoning that led to closing the report "as designed" out of several reasons. To put the situation in a
Am 12.03.2011 17:51, schrieb Jonas Maebe:
Hello,
Could someone check whether or not this compiles with Delphi 2009+ ?
No, this does not compile on XE. However, you can do this:
tforward = class;
tc = class
type
tnest = class
end;
end;
ty = class
function f: tforward;
Hi,
Am 21.11.2010 12:49, schrieb Max Vlasov:
I recently read the info about current implementation of packages and a
post that dynamic packages support is at the early stage or not started
yet. Knowing that fpc developers is very skilled and they probably the
I've been very busy lately, so
Am 26.10.2010 21:33, schrieb Jonas Maebe:
Thanks for confirming my thoughts. Shall I still file a bugreport for this?
It's fixed.
Thanks, I just wanted to file a report for this and the assembly thing
but it seems that reporting new issues on mantis does not work
currently. (I am getting
Am 24.10.2010 20:49, schrieb Jonas Maebe:
It should probably check whether the packedbitsize is in [8, 16, 32,
64]. The reason is that if you have a load from a byte-aligned
address using a size that is natively supported by the code
generator, you don't have to go through all the
Hi!
I stumbled accross a bug in fpc that manifests itself when working with
bitpacked records that have fields with pos and size mod 8 == 0; For
example:
type
TField = bitpacked record
case boolean of
true: (value : integer);
false: (
data: 0 .. $FF;
Am 23.10.2010 14:47, schrieb Willibald Krenn:
BTW: Changing is_packed_record to
in nutils.pas (~ 1155)
subscriptn:
result:= is_packed_record_or_object(tsubscriptnode(n).left.resultdef)
and (
(tsubscriptnode(n).vs.vardef.packedbitsize mod 8 0) or
(tsubscriptnode(n).vs.fieldoffset mod 8 0
Am 13.10.2010 09:56, schrieb Pierre Free Pascal:
I tested and committed this change as rev 16151
in trunk, thanks for this!
Cool - thanks!
What version of the win64 GDB are you using?
It says 7.2. Probably I should get a newer version. Some output:
0x00011674 +308: mov
Am 13.10.2010 21:34, schrieb Willibald Krenn:
Yes, your output seems to be fine! I'll try upgrading my gdb to a newer
version - hope this helps. If this is working, then I think we should
switch to DWARF2 on Win64 and close all related bugs in mantis. ;-)
I upgraded my version of gdb
Am 12.10.2010 09:51, schrieb Jonas Maebe:
There is no stabs64 format, afaik. See
http://sourceware.org/bugzilla/show_bug.cgi?id=9327
Just checked, this example is working fine on Win64:
PS C:\source\bugs\lokals gdb test.exe
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
Am 12.10.2010 10:55, schrieb Jonas Maebe:
It currently is because dwarf debug information generation
for x86_64 is still much more buggy than stabs generation.
Is it? I use it all the time on Mac OS X/x86-64 and Linux/x86-64, and it
works fine.
DWARF does not work on Win64: while dwarf3
Am 12.10.2010 20:33, schrieb Jonas Maebe:
dwarf2 debug information seems to be broken too.
Keep this in mind: http://bugs.freepascal.org/view.php?id=15692
I don't know exactly what to conclude from this discussion. Are 32 bit
pointers enough for WinPE? Then stabs would be fine anyways.
Am 12.10.2010 21:02, schrieb Jonas Maebe:
I don't know exactly what to conclude from this discussion.
Try using the -WB004 command line option.
PS C:\source\bugs\exception del *.o
PS C:\source\bugs\exception del *.exe
PS C:\source\bugs\exception fpc -gw -WB004 .\project1.lpr
PS
Hi,
After adding 'tf_dwarf_only_local_labels' to the
flags in i_win.pas (line 105) dwarf2 seems to be working. (Even without
-WB0040).
Cheers,
Willi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 13.10.2010 01:40, schrieb Willibald Krenn:
Hi,
After adding 'tf_dwarf_only_local_labels' to the
flags in i_win.pas (line 105) dwarf2 seems to be working. (Even without
-WB0040).
Additional remark: The -WB option is still needed, otherwise, e.g.,
'disas' is not working correctly in gdb
Hi,
On my Win64 machine, gdb kept crashing whenever I tried to step into
fpc_raiseexception with an error saying that the reg '-1' wasn't
defined. And yes, stabs info showed:
4943 FUN0 18700408710 66408 fpc_raiseexception:F129
4944 RSYM 0 625
Am 04.10.2010 09:35, schrieb Sven Barth:
Yep. (For inlined methods/functions we could - theoretically - provide a
'non-inlined' version in the binary package)
For generics: the token stream is already included in the PPUs (learned
by looking at DoDi's ppudump patches ^^)
This is
Hi!
Here comes my 'official' plan on how I want to implement Delphi-like
Package Support for FPC on Win64. Feel free to comment.
Definitions
~~~
File.ppl Free-Pascal Package Library
(shared module, Delphi: bpl)
File.ppk Free-Pascal
Hi,
To minimize traffic, I'll answer all comments (thanks!) in this e-mail.
Willibald can get access to a branch to commit his work.
Also an idea. But you might outline some rules for commits so that not
the same problems happen as with DoDi's branches.
A branch would be nice, I guess.
Am 03.10.2010 21:42, schrieb Hans-Peter Diettrich:
I don't like the Delph all-or-nothing philosophy here. I'd prefer to
specify the packages, that shall be loaded at runtime, while all other
You can always load packages at runtime.. That is, after the RTL
supports that of course.
packages
maybe others want to contribute too. Will this be a Willibald-only
branch?
I surely don't mind fellow contributors (au contraire!!) - if we agree
on some partitioning of the work and one common plan. For example, it
would be terrific, if someone could do Linux or Win32 as main platform.
And
Wow, that was quick! Thanks for putting this into trunk in record time!
Cool, now I've got a working FPC and can start hacking on Delphi-like
package stuff :)
Cheers,
Willi
Am 28.09.2010 10:40, schrieb Pierre Free Pascal:
Thank you so much!
It's been a while that I was trying to
Hi!
I'm having this issue, too, but with 2.4.3.
The following example code fails with FPC 2.4.2 RC1 as well (system is
i386-win32):
Tried that with trunk and it compiled fine. (FPC 2.5 on win64)
Cheers,
Willi
___
fpc-devel maillist -
Proposed fix now in mantis, #0017500. Turns out RELOC_ABSOLUTE32 seems
to work, I had forgotten to do a proper clean before checking.. :-\
Cheers,
Willi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Hi!
Lately I spent some time debugging the internal error problem and it
turns out that in method TCoffObjSection.fixuprelocs the .stabs section
gets damaged: AFAICT the data.write statement in that method tries to
replace a 4-byte offset pointer with an 8-byte (RELOC_ABSOLUTE) one.
Hence,
Also, I don't know whether the lines
if reloctype=RELOC_RELATIVE then
begin
if win32 then
dec(data,len-4)
in TCoffObjData.writereloc could potenially pose a problem.
Please ignore the above comment in my previous mail.
Cheers,
Willi
___
Hi!
Now, before I start fixing this on my own, I wanted to ask whether
somebody knows what's going wrong?
In case someone is interested: it compiles fine with the flag -OoNOCSE
(disabling of cs_opt_nodecse) set. Seems the common subexpression
elimination pass is the culprit?!
Cheers,
- execute the following command:
fpc -Us -Sg -Fiinc -Fix86_64 -Fiwin -Fiwin64 -FUunits\x86_64-win64
win64\system.pp
Had to change it to
fpc -Us -Sg -Firtl\inc -Firtl\x86_64 -Firtl\win -Firtl\win64
-FUunits\x86_64-win64 rtl\win64\system.pp
but this worked, as expected.
Now you should have
Hi Sven!
Am 19.09.2010 13:49, schrieb Sven Barth:
and the following for Windows:
pp -Twin32 -Fuunits/i386-win32 rtl.ppk
I tried this with my 64 bit-head version of fpc, but it failed to
produce any output except an .a and an .o file.
fpc -Twin64 -Fuunits\x86_64-win64 rtl.ppk
unknown: 12
Hi!
I tried to do a bootstrap of the compiler on my Windows 7 64bit machine
today (svn version 16015). Using the 2.4.0 win64 cross compiler from the
homepage, I got a basic build. The problems, however, start when I want
to include debug information (-gl) as this seems to trigger an
[lots of useful information snipped]
- The ability to import/export functions, procedures AND variables from
binaries (although export from shared library only should be
sufficient). This works on Windows, but on Linux I had problems.
Packages also export/import RTTI, ClassVars, types, all
Sven Barth schrieb:
[snip]
In theory(!) it should be rather simple to implement shared cross
platform packages (those that are loaded on app startup by the OS and
not dynamically during the run).
Thanks for the hints! They are very welcome.
Cheers,
Willi
This is why FPC has specialize (to emphasis this): only class instances
having the same specialized generic type are considered being equal:
type
TList1 = specialize TListLongint;
TList2 = specialize TListLongint;
var
l1a,l1b : TList1;
l2 : TList2;
Only l1a and l1b are
OTOH 'specialize' is an additional
(unfamiliar) keyword and has semantics totally unknown to the world.
So why not take what's already in the language?
As I said, to emphasis that a new type is created, generic
specialization is something really new to the language. The meaning of
type
Well, it's the Delphi way of creating a new type rather than an
alias.
Since they are still assignment compatible, I don't consider it as a
really new type.
Are you sure they are assignment compatible? I thought the whole point of the
type A = type B was to make a new type, not an
Michael Van Canneyt schrieb:
Packages have nothing to do with the language feature. The difficult thing
is run-time resolving of all symbols. What the nature is of these
symbols is really not relevant.
Pardon my ignorance, but why is runtime resolving so difficult? There is
a fine Delphi
Marco van de Voort schrieb:
No it won't. Not all of the implementation of a package needs to be in the
.BPL equivalent. Neither is the case in Delphi.
Seek for $weakpackage and read the packages wiki again
In words of Borland/Embac - Unit files containing the {$WEAKPACKAGEUNIT
ON}
Marco van de Voort schrieb:
No, since any specialization creates the actual types, and they all will
have their respective static fields anyway? (since the static field can be
of the variable type)
There are some languages/runtimes that have some damage control here (most
notably C# which uses
Marco van de Voort schrieb:
Played around with Delphi today, and it seems that class vars are
somewhat broken on generic types. They work as expected (share common
class value amongst all sameclasssametype instances) only in a unit
scope, it seems. Which is a pitty.
To be honest, that is
Hi!
Today I was thinking about fpc packages (whenever I am using this word,
I mean Delphi-style-DLL-packages) and what difficulties might arise when
implementing them. In my opinion, doing packages for D6-like Pascal
should not be conceptually hard. It'll be more of a technical challenge
to
Hi!
Please forgive my ignorance on this topic, but I'd like to know whether someone
is working on adding Delphi-like packages to FPC. (At least for the
windows/linux platforms.) Somehow the lack of this feature always has stopped
me from using fpc/lazarus: For a change, I am thinking of
This is why there is no work on a packages system for FPC: there are
simply too much different versions around. While Delphi has at most one
release per year, FPC/Lazarus has more or less every day a new version.
Well, but not that much stable releases, I suppose. :)
I am sure that Delphi
45 matches
Mail list logo
