Hi,
Yes, it's caused by a recent change I made. I have a half-ready patch,
should be fixed over the weekend. However, if you use -O2 only to build
the compiler itself instead, it shouldn't appear.
Charlie
On Sat, 18 Jan 2014, Martin wrote:
Just svn updated (after make clean) trunk to
Hi,
On Mon, 24 Feb 2014, Sven Barth wrote:
Am 24.02.2014 17:29, schrieb Michael Schnell:
On 02/24/2014 03:41 PM, Sven Barth wrote:
are normally OS independant as they normally use corresponding CPU
instructions.
Of course for simple stuff like inc/dec I can (better) use atomic 68 K
Hi,
On Sat, 22 Feb 2014, Sven Barth wrote:
With revision 26849 which I just committed a few minutes ago an imporant
milestone was reached for reviving the M68k port: the cross compiled compiler
is now not only able to compile a program, but this program is also able to
run correctly!
Hi,
On Mon, 10 Mar 2014, Sven Barth wrote:
Well, today on IRC you mentioned Atari too many times for an Amiga guy's
taste, so I couldn't resist...
Once is already too many? :P
Yes! :)
http://charlie.amigaspirit.hu/screenshots/uae/UAE-FPC-m68k-2.7.1-FirstEver.png
:)
Congrats! So
Hi,
I think there are several issues with the cmem memory allocator. The main
issue that it breaks the underlying malloc() memory alignment, by adding
a four/eight byte size value to the start of each block for the sole
reason to be able to throw Runtime Error 204 in case someone tries to free
a
Hi,
On Wed, 19 Nov 2014, Mark Morgan Lloyd wrote:
At least on Linux, malloc() is documented to align to 64 bit on 32 bit and
128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that
to 4 bytes and 8 bytes, respectively.
Since cmem is intended for use by FPC, I don't see
Hi,
On Wed, 19 Nov 2014, Jonas Maebe wrote:
Since the RTL's allocator is documented to align to 16 bytes
Where?
Ok, that's actually a very good question. :) I didn't find it anywhere,
except some earlier ML/forum posts revealed by Google.
However, in practice it still seems to align to 16
Hi,
On Wed, 19 Nov 2014, Marco van de Voort wrote:
Since the RTL's allocator is documented to align to 16 bytes, it's
definitely an issue also with Pascal code. We do have code where also
Pascal side triggers the aligment issue, but indeed, the main issue is
with linked C libs, depending
Hi,
On Tue, 23 Dec 2014, Maciej Izak wrote:
I've Decided to close the FreeSparta. Thanks you all for your interest.
There are several
reasons.
[...]
When I look for new jobs, it seems that there are no more jobs for
Pascal/Delphi Programmers. Now
in my new job I'm using Java EE and C#
Hi,
On Sun, 15 Nov 2015, Michael Van Canneyt wrote:
> Strange, I created a test before committing, and it ran fine. Well. I
> reinstated line 1132. But according to logic, that line should not be
> necessary. Maybe I am not properly seeing a case where it can go wrong.
Wild try/guess just by
Hi,
On Sun, 5 Jun 2016, Sandro Cumerlato wrote:
> fpc svn trunk version 33910 building fails with error:
> *..snip..*
>Compiling .\fcl-db\src\export\fpxmlxsdexport.pp
>Compiling .\fcl-db\src\sqldb\interbase\fbadmin.pp
> The installer encountered the following error:
> Compilation
Hi,
On Sun, 21 Aug 2016, Sergei Gorelkin wrote:
> It is actually the opposite way around.
> g_save_registers/g_restore_registers methods are only used for first
> implemented targets (i386 and maybe m68k). All newer targets are written
> without calling them, since they are completely
Hi,
On Sun, 21 Aug 2016, Michael Ring wrote:
> So unless there is a way to find out which registers get used by a procedure
> the only thing I can do to make interrupt routines as lean as possible is to
> not use procedures in them if possible.
There is a way, of course. Seems like the MIPS CG
Hi,
On Wed, 23 Nov 2016, Alfred wrote:
> To enable cross from Windows towards Darwin, some changes in FPC were needed.
> They have been added into NewPascal, and can be found here:
> https://github.com/newpascal/freepascal/commit/a99fe9054957d2c42c780c4d05e59c6fbda31621
> Not meant to be 100%
Hi,
On Wed, 23 Nov 2016, Alfred wrote:
> > TL;DR: if this patch was accepted into NewPascal w/o comments or concerns,
> > then "ouch"...
>
> Thanks for your advice.
> This is exactly why NewPascal is here !
>
> Have an idea. Implement. Make public.
> perfect:=false;
> while (NOT perfect) Use;
Hi,
On Wed, 14 Dec 2016, Michael Schnell wrote:
> Of course another (better) option would be a fpc directly creating
> WebAssembly, but I understand that this will take a lot of time.
There is some interest in a WebAssembly backend, but yes it will take a
lot of time. No spoilers for now, and
Hi,
On Thu, 16 Mar 2017, LacaK wrote:
> Then I get another error:
>test_IPP.lpr(24,1) Error: Illegal COFF Magic while reading
> .\Intel_IPP\ippcoremt.lib
>
> Am I doing something wrong, or there is some kind of incompatibility
> between format of supplied libraries and object files supported
Hi,
On Mon, 31 Jul 2017, Werner Pamler wrote:
> If the URL exists everything is fine (note on Windows, that the OpenSSL
> dlls must be copied to the exe directory for the demo to work). If the
> URL does not exist, but the server responds, the program returns the
> well-known error 404 (if the
Hi,
On Wed, 9 Aug 2017, Curtis Hamilton wrote:
> I just formally subscribed to this mailing list.
>
> I'm interested in fpc on FreeBSD/PowerPC, however, I don't want to
> create any additional work nor break something that's not broken. That
> being said, I'm willing to work on this alone or
Hi,
On Thu, 10 Aug 2017, Marco van de Voort wrote:
> > The questions is, can I just go in and upgrade our syscall interface to
> > the newer calls (where makes sense), or do we intend to support older
> > systems too?
>
> To my knowledge there is no universal "newer" and "older" BSD syscall
>
Hi,
On Tue, 8 Aug 2017, Karoly Balogh (Charlie/SGR) wrote:
> > I'm interested to know if there has been work on fpc for
> > FreeBSD/PowerPC. I'm interested in the status and helping maintain fpc
> > for this platform.
>
> FreeBSD for PowerPC never existed in FPC (it's
Hi,
On Mon, 7 Aug 2017, Curtis Hamilton wrote:
> I'm interested to know if there has been work on fpc for
> FreeBSD/PowerPC. I'm interested in the status and helping maintain fpc
> for this platform.
FreeBSD for PowerPC never existed in FPC (it's not even in the internal
platform list, only
Hi,
On Mon, 29 May 2017, Tomas Hajny wrote:
> > It is, but it's *pregenerated*, and committed to the SVN. The build
> > process doesn't generate any Makefiles, actually. (Lets not argue now it
> > is a nice practice or not, it is what it is...) To fix this, one has to
> > regenerate them. But
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Which is because the buildbox doesn't have these 32bit libraries
> installed, so FPC obviously cannot link against them. This is because the
> very limited multiarch you mentioned before I guess. Now, FPC doesn't need
> L
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:14:26PM +0200, John Paul Adrian Glaubitz wrote:
> > On Mon, May 29, 2017 at 01:09:05PM +0200, John Paul Adrian Glaubitz wrote:
> > > I tried adding "-32" like this:
> >
> > Even passing "-Av8plus" does not
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:57:51PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > Indeed, this worked. Also, not sure what Adrian was doing wrong, but I
> > added -32 into sparc/cpugas.pas file as I said, and from th
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:25:34PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > > > Even passing "-Av8plus" does not help. So, the options from
> > > > compiler/sparc/cpugas.pas are definitely not
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> In the end, I want to build the Debian package. So, the patches have
> to apply against that version.
Well. I applied a 1 line patch against rtl/linux/Makefile.fpc, to append
-32 when it builds the startup code, regenerated the
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > Which is because the buildbox doesn't have these 32bit libraries
> > installed, so FPC obviously cannot link against them. This is because the
> > very limited multiarch you mentioned before I guess. Now, FPC doesn't need
> > Libc on
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
So Adrian, I've got a question. Looking at fixing this in the right way,
the linker search paths at least.
What's the right directory to search for lib
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> Make sure to pass -L/lib32 to the linker because that's where libc6-sparc
> gets installed into:
>
> root@deb4g:~# dpkg -L libc6-sparc |head
> /.
> /etc
> /etc/ld.so.conf.d
> /etc/ld.so.conf.d/zz_sparc-biarch-compat.conf
> /lib
> /lib32
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Plus you need to fix the Makefile.fpc in rtl/linux to include -32 for
> SPARC, and regenerate it using fpcmake -Tall. Then everything works. Maybe
> it's also possible to just add ASTARGET=-32 into the make command line,
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > Can you try if you can reproduce this?
>
> Sure. Can you put the cross-compiled ppcsparc somewhere so I can find
> and use it?
You don't need one. :) See my other mail. Although I did crosscompile a
new bootstrap compiler, in the end
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Like this:
>
> make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
>
> This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
> Debian SPARC64 box without patching anything.
J
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > However, it should probably not be merged to fixes, because it may be a
> > breaking change for older Sparc/Linux versions (see my previous e-mail;
> > note that the situation with MIPS was probably different, because the
> > support
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> However, these also seem to be installed in /usr/lib32... So build running
> now, lets see what happens.
Different error: ... :/ I would gladly keep working on this, but I kinda
ran out of time for now, I can take a deeper look
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> > However, these also seem to be installed in /usr/lib32... So build running
> > now, lets see what happens.
>
> Different error: ... :/ I would gladly keep working on this, but I kinda
> ran out of time for now
Hi,
On Sun, 28 May 2017, John Paul Adrian Glaubitz wrote:
> When trying to cross-build fpc for sparc64, I ran into linker issues. I was
> able to resolve these when changing the ELF format from 32 to 64 bits in
> compiler/system/t_linux.pas and changing the dynamic loader path from
>
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> Running the file utility on one of the object files shows that the
> assembler did not generate 32-bit code. So, at least a hotfix here
> would be to pass "-m32" to the assembler.
That is easy to add, see in compiler/sparc/cpugas.pas,
Hi,
The list server rebooted this morning. We're investigating with the
hosting service why. If you got mails multiple times or your mail got
lost, this is why. By now, everything should be back to normal. Sorry
about the inconvenience.
Charlie
___
Hi,
On Mon, 29 May 2017, Mark Morgan Lloyd wrote:
> My recollection is that the SPARC64 code generator is immature,
> hopefully Jonas will comment on that.
Not sure what "immature" means, granted, I don't know anything about
SPARC, but from what I see, FPC definitely handles SPARC as a 32bit
Hi,
On Tue, 30 May 2017, Marco van de Voort wrote:
> In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > Err, those are invoked directly from the Makefile, not invoked from inside
> > FPC. But you're right, that will be also a problem... Some platforms still
>
Hi,
We had numerous reports over the past few weeks, that the FPC/Lazarus
Bugtracker registration verification was broken. Thanks to the work of
Michael van Canneyt, it should be fixed now.
If you had trouble creating a bugtracker account in the last few weeks,
please try again now.
Charlie
Hi,
On Wed, 20 Sep 2017, Christo wrote:
> I have made an attempt at fixing an AVR related bug. Since this is my
> first attempt at messing with the compiler, I would like a review and
> critique of my attempt.
> (...)
>
> Can anyone see any problems with this approach, or perhaps suggest a
>
Hi,
On Sat, 2 Sep 2017, Marco van de Voort wrote:
> The expansion of texpropcode in r37108 (Mattias) breaks fppasjs because it
> defines an array with texpropcode as range.
>
> This prohibits building of trunk.
Sven fixed it already in r37109.
(The quick-response advantage of receiving build
Hi,
On Thu, 30 Nov 2017, Marco van de Voort wrote:
> For Downloads, please use the FTP server at
>
> ftp://freepascal.stack.nl/pub/fpc/dist/3.0.4/
Not sure why Marco decided to redirect everything to the stack.nl mirror
as primary source in his announcement, but everything should be on
Hi,
On Wed, 13 Jun 2018, Adriaan van Os wrote:
> >> Yuriy Sydorov wrote:
> >>> No special version is needed, use 3.0.4 release sources or trunk
> >>> sources.
>
> I have fpc-3.0.4 installed on OS X 10.6.8. In a separate 3.0.4 sources folder,
> I issue
>
> make clean crossall crossinstall
HI,
On Tue, 26 Dec 2017, Thorsten Engler wrote:
> > Item: BYTE BASED ItemPtr;
>
> Ignoring any other considerations for now, I would have at least used a
> logical extension derived from already supported syntax:
>
> Item: Byte absolute ItemPtr^;
As far as I understand (I did not try) this was
Hi,
On Mon, 30 Jul 2018, J. Gareth Moreton wrote:
> I would say that that's a little naïve and dangerous to think like that.
> Sure, Windows might have the means to clean up memory after an
> application terminates, but not all platforms have such heap
> deallocation features (e.g. pure DOS,
Hi,
Just some technical background to this discussion, I don't care who
documented what, I'm just stating how it works. :P
On Thu, 5 Apr 2018, Ondrej Pokorny wrote:
> >>> Now, it is also correct that the compiler developers are aware that
> >>> many people rely on this implementation detail.
>
Hi,
On Thu, 25 Oct 2018, Michael Van Canneyt wrote:
> >>> - Make Exception handling, TLS etc use the infrastructure that
> >>> libpthread is providing
> >>
> >> TLS is handled already by libpthread. I doubt you will gain much there.
> >>
> >
> > GCC has (depending on the platform) a faster
Hi,
On Thu, 25 Oct 2018, Florian Klaempfl wrote:
> >> That is good news. The contours of a TODO list are becoming visible :)
> >>
> >> But we may need also need a solution for other platforms, which means the
> >> current system should remain in place for those platforms where such a
> >>
Hi,
On Mon, 31 Dec 2018, Olivier Coursière via fpc-devel wrote:
> > if you want, I can integrate those changes into trunk for you.
> Thank you for the offer but i should have some free time in the next two
> days. I should already have the change in a 3.0.4 branch. It should be
> easy to port to
Hi,
(Not sure if Olivier is on the list, so keep cc:-ing him...)
On Mon, 31 Dec 2018, Karoly Balogh (Charlie/SGR) wrote:
> > Not really. I have investigated what need to be done for x86-64 port but
> > the assembly part (cprt0.as) was enough to dissuade me so far ;-) Other
> >
Hi,
On Tue, 1 Jan 2019, Karoly Balogh (Charlie/SGR) wrote:
> (Not sure if Olivier is on the list, so keep cc:-ing him...)
>
> So, bottom line, see the following patch:
>
> http://charlie.amigaspirit.hu/temp/private/haiku_pascal_sysinit.patch
I have updated the patch. The ex
Hi,
On Wed, 2 Jan 2019, Olivier Coursière wrote:
>> Should linking without libc (as in, libroot) be supported?
> I have only maintained the libc/libroot part since the beginning of
> Haiku port ten years ago.
Well, we do have other libc-only ports, like the macOS/Darwin version.
It's best to
Hi,
On Fri, 4 Jan 2019, Olivier Coursière via fpc-devel wrote:
> > There seems to be something wrong with the signal setup so strace is
> > used to hide a fatal error... Also file handling doesn't really work
> > now. But even to get to this level in a few hours was nice.
> For signal handling,
Hi,
On Wed, 2 Jan 2019, Karoly Balogh (Charlie/SGR) wrote:
> > - port/fix to 64bit
> >
> > With the already proposed changes to simplify the initialization part,
> > it is probably "just" a matter of :
> > (...)
>
> Yup, that list sums it up. Also I'
Hi Olivier,
On Fri, 11 Jan 2019, Olivier Coursière via fpc-devel wrote:
> > It would be nice to also get regular testsuite results for Haiku OS!
> I have tested VM automation with vagrant and i should be able to
> automate something to launch and upload the result in one click. And
> maybe for
Hi
On Fri, 11 Jan 2019, Pierre Muller wrote:
> > Make cycle works fine as of current trunk, however "make all" causes a
> > KDL, unless you disable fcl-process usage in fpmake. See this patch:
>
> I already managed to generate a snapshot:
>
>
Hi,
On Thu, 28 Mar 2019, J. Gareth Moreton wrote:
> I think the official unsigned 32-bit integer type in Pascal is
> "LongWord". As others have said, be aware that pointers are 64-bit under
> x64... that's kind of why it's called x64! If you absolutely must have
> a packed record with 32-bit
Hi,
On Mon, 27 May 2019, Pierre Muller wrote:
> The merge of the two commits generate 3 conflicts, but those are easily
> solved.
> See attached patch.
>
> Olivier, did you test the fixes_3_2 branch?
> Do you think it is reasonable to enable x86_64-haiku target in that branch?
I think if
Hi,
On Sat, 15 Jun 2019, J. Gareth Moreton wrote:
> Ryan Joseph requested that I reply to this to show that it's in the
> mailing list. Hopefully the technical problems can be resolved!
There was an issue affecting GMail users, and GMail's SMTP servers over
IPv6. This has been resolved by now.
Hi,
On Fri, 29 Nov 2019, Werner Pamler wrote:
> Who takes care of the wiki software? There is another issue that it is
> not possible any more to replace existing uploaded images by new
> versions (at least when I tried the last time, some weeks ago).
It's me. And I know. I spent today 3 hours
Hi,
On Mon, 27 Apr 2020, Sven Barth via fpc-devel wrote:
>> Well, I'm surprised and impressed you got it to work at all...
>> Quite an achievement.
>
> Considering that we already support AVR as well I was rather confident
> here. :D Maybe in the future we can also add GameBoy support which uses
Hi,
On Sat, 20 Jun 2020, Yuriy Sydorov wrote:
> I've added the generic cs_opt_unused_para optimization option.
> In future, if needed, more fine-grained related options can be introduced.
>
> So now the parentfp optimization is enabled for -O2 and higher.
Yuriy, your changes seem to have broken
Hi,
On Mon, 21 Dec 2020, J. Gareth Moreton via fpc-devel wrote:
> That should be fine - thanks Marcus. I need to reproduce the internal
> error that's being reported, and so I can compare the disassembly of
> ppcross68k to see where my optimisation is going wrong.
To bould any cross compiler,
Hi,
On Sun, 15 Nov 2020, Jonas Maebe via fpc-devel wrote:
> On 15/11/2020 15:19, Karoly Balogh (Charlie/SGR) via fpc-devel wrote:
> >
> > Yes, I already had to dothis in my build scripts on Mojave. I defined an
> > "FIXMOJAVE" environment var, which contain
Hi,
On Sun, 15 Nov 2020, Jonas Maebe via fpc-devel wrote:
> > my Macs that the timestamp of that file changed), but this will not help
> > for compiling the compiler as the compiler is beeing compiled with the
> > flag -n which effectively turns off reading /etc/fpc.cfg.
>
> Indeed, I glossed
69 matches
Mail list logo
