Hi,
I have added support for LLVM's address sanitizer to the LLVM backend.
You can find more information here:
https://wiki.freepascal.org/LLVM#Using_Address_Sanitizer_.28asan.29
It caught a couple of (minor) errors in the compiler itself while I was
testing it.
Jonas
> On Nov 14, 2021, at 4:58 PM, Jonas Maebe via fpc-devel
> wrote:
>
> Afaik there's also a C binding (or at least there used to be one).
There is some c bindings but they seem incomplete, or at least I couldn't
figure out how to follow the tutorial using what was provided there.
>
>> How
On 2021-11-14 05:58, Ryan Joseph via fpc-devel wrote:
As a fun weekend project I wanted to follow along with the tutorial at
https://llvm.org/docs/tutorial/index.html but I noticed the API in in
C++ so it wouldn't be possible to do this in Pascal without at least
some plain C API.
Afaik
As a fun weekend project I wanted to follow along with the tutorial at
https://llvm.org/docs/tutorial/index.html but I noticed the API in in C++ so it
wouldn't be possible to do this in Pascal without at least some plain C API.
How did Free Pascal/Jonas accomplish this in the LLVM backend?
Jonas Maebe wrote:
On 17 Nov 2009, at 08:18, Vincent Snijders wrote:
If you look at CPU secs, then the factor is 3 at most. What helps the C++
programs most is that they use 4 cores more, the fpc programs are mostly
singlethreaded. LLVM doesn't help to solve this (AFAIK).
Anyway, the above
On 17 Nov 2009, at 09:30, Micha Nelissen wrote:
Jonas Maebe wrote:
On 17 Nov 2009, at 08:18, Vincent Snijders wrote:
If you look at CPU secs, then the factor is 3 at most. What helps the C++
programs most is that they use 4 cores more, the fpc programs are mostly
singlethreaded. LLVM
In our previous episode, Matej Spiller-Muys said:
[ Charset ISO-8859-1 unsupported, converting... ]
You also get breaking backwards compatibility with a lot of existing
Delphi code for free. I repeat: you really cannot underestimate the amount
of
implementation details that existing Delphi
Matej Spiller-Muys wrote on Mon, 16 Nov 2009:
I would love fpc to be based on LLVM backend. C bindings are ok, but
wouldn't it be better to fix support for cppclass inside fpc (since it is
already there) and create more proper C++ headers.
C interfacing works today and has been very
C interfacing works today and has been very thoroughly tested. cppclass
only works, for very basic things, since 2 days ago or so. Unless someone
enjoys
debugging a new code generator and a new external language interfacing
paradigm at the same time, that does not sound like a very good idea to
Matej Spiller-Muys wrote on Mon, 16 Nov 2009:
C interfacing works today and has been very thoroughly tested. cppclass
only works, for very basic things, since 2 days ago or so. Unless someone
enjoys
debugging a new code generator and a new external language interfacing
paradigm at the same
You also get breaking backwards compatibility with a lot of existing
Delphi code for free. I repeat: you really cannot underestimate the amount
of
implementation details that existing Delphi code depends on, and people
already complain about FPC's incompatibility with those implementation
On 17 Nov 2009, at 07:31, Matej Spiller-Muys wrote:
I have no idea. All I know that's slightly related is the alioth computer
language benchmark game (with the stress on game), where you have at least
both FPC and GCC results.
Yup, the FPC factor is 2x-10x slower.
That's because you are
Jonas Maebe schreef:
On 17 Nov 2009, at 07:31, Matej Spiller-Muys wrote:
I have no idea. All I know that's slightly related is the alioth computer
language benchmark game (with the stress on game), where you have at least
both FPC and GCC results.
Yup, the FPC factor is 2x-10x slower.
On 17 Nov 2009, at 08:18, Vincent Snijders wrote:
Jonas Maebe schreef:
And as mentioned before, it's with the stress on game: the results on that
site depend on almost as much on the implementation effort that people have
put in optimizing the source code for their language as it does on
Samuel Crow wrote:
GCC already does provide C and C++ (this is a Linux system after all :)
) and I suppose it thus also does provide Objective C and Objective Pascal.
I would need FPC (Delphi Language Pascal), as I'd like to port a lot
of Delphi code.
I _HOPED_ LLVM would use the GCC code
P.S.:
In this list, we already did discuss doing an FPC version that creates
the intermediate code that can be fed to the GCC code generator. This
would make available to FPC all relevant CPU architectures and
supposedly the low level optimization that gcc4 does on this
intermediate code is hard
Michael Schnell schrieb:
P.S.:
In this list, we already did discuss doing an FPC version that creates
the intermediate code that can be fed to the GCC code generator. This
would make available to FPC all relevant CPU architectures and
supposedly the low level optimization that gcc4 does on
Florian Klaempfl wrote:
Just use GPC then?
It does not compile the many thousands of lines of the Delphi project I
want to port :(.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Michael Schnell schrieb:
Florian Klaempfl wrote:
Just use GPC then?
It does not compile the many thousands of lines of the Delphi project I
want to port :(.
Yes, because it's probably very hard to make a (Object) Pascal front end
for gcc. Another backend for FPC is 4k-5k lines (pascal, no
Florian Klaempfl wrote:
I'am sure, somebody
will write you a backend for the desired processor.
Yep, a team of three: I, me, and myself.
As this processor, a load/store RISC with 32 non-dedicated 32 Bit
registers, is very similar to MIPS and thus a bit similar to ARM (only
that MIPS-alike it
On 11 Nov 2009, at 23:41, Samuel Crow wrote:
I can work on getting Borland Fastcalls implemented in the LLVM x86
backend. By the time I'm done with that we can talk about what else
needs doing. Is there a test already in the FPC repository that I
can use as a test to make sure that the
Hi Jonas,
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thu, November 12, 2009 7:48:58 AM
Subject: Re: [fpc-devel] LLVM Backend?
-snip-
It does make a difference. Unfortunately. While working
On 12 Nov 2009, at 18:15, Samuel Crow wrote:
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thu, November 12, 2009 7:48:58 AM
Subject: Re: [fpc-devel] LLVM Backend?
-snip-
It does make a difference
Samuel Crow wrote:
I'm looking forward to the challenges of this project.
I am planing for another project: doing an FPC compiler for the NIOS
processor (which is similar to MIPS32) on a Linux target. Do you think
it's viable to consider LLVM instead of trying to modify the native
ARM FPC code
On 11 Nov 2009, at 04:29, Samuel Crow wrote:
The IRBuilder class http://llvm.org/doxygen/classllvm_1_1IRBuilder.html
is as stable as the instruction set it builds and is maintained as
such since it is used by Clang, LLVM-GCC and other frontends.
Ok, that would be fine then. The only
Jonas Maebe wrote:
b. the dragonegg approach (http://dragonegg.llvm.org/), where you make
use of the support in an existing compiler (again GCC in this case) for
abstract code generator support to emit LLVM assembler/bitcode rather
than machine code
For my upcoming project: I (of course) do
On 11 Nov 2009, at 12:24, Michael Schnell wrote:
Jonas Maebe wrote:
b. the dragonegg approach (http://dragonegg.llvm.org/), where you
make
use of the support in an existing compiler (again GCC in this case)
for
abstract code generator support to emit LLVM assembler/bitcode rather
than
Schnell mschn...@lumino.de
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wed, November 11, 2009 4:56:52 AM
Subject: Re: [fpc-devel] LLVM Backend?
Samuel Crow wrote:
I'm looking forward to the challenges of this project.
I am planing for another project: doing an FPC
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wed, November 11, 2009 5:03:52 AM
Subject: Re: [fpc-devel] LLVM Backend?
On 11 Nov 2009, at 04:29, Samuel Crow wrote:
As noted in other messages
On 11 Nov 2009, at 16:55, Samuel Crow wrote:
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wed, November 11, 2009 5:03:52 AM
Subject: Re: [fpc-devel] LLVM Backend?
In a sense it's no problem if the LLVM
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wed, November 11, 2009 1:43:08 PM
Subject: Re: [fpc-devel] LLVM Backend?
-snip-
That's two problems, both fairly significant (although the latter
On 11 Nov 2009, at 21:35, Samuel Crow wrote:
It's not entirely clear to me yet how you see the result: an FPC
frontend added
to the LLVM project, or an LLVM backend added to the FPC project. I
favour the
latter, but a lot of what you talk about seems to be about the
former. Or am I
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wed, November 11, 2009 3:41:22 PM
Subject: Re: [fpc-devel] LLVM Backend?
Yes, it does, thanks. The main problem I see is that my approach would
require
Hello,
I'd like to help with the experimental LLVM backend if anyone is interested.
It's been years since I've used Pascal though, so perhaps my familiarity with C
and C++ on the LLVM end will be beneficial.
While we're on the subject, LLVM has a very powerful optimizer that, when used
in
On 10 Nov 2009, at 19:28, Samuel Crow wrote:
I'd like to help with the experimental LLVM backend if anyone is
interested. It's been years since I've used Pascal though, so
perhaps my familiarity with C and C++ on the LLVM end will be
beneficial.
Thanks for the offer!
While we're on
Hello Jonas,
(Replies inline.)
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, November 10, 2009 1:57:03 PM
Subject: Re: [fpc-devel] LLVM Backend?
-snip-
The main things that basically halted my
On 10 Nov 2009, at 21:35, Samuel Crow wrote:
The current way to implement pointer arithmetic in LLVM is to use an
i64 for all instances of pointers
We can't do that at the high level, since then all pointer fields in
records etc would become 64 bit. And the low level currently assumes
In our previous episode, Jonas Maebe said:
With an LLVM backend, there will obviously be a dependency on LLVM
(either as a library or as an installed tool chain) and hence on its
dependencies, but it would be nice if we could be compatible with as
many different LLVM releases as
On 10 Nov 2009, at 23:00, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
With an LLVM backend, there will obviously be a dependency on LLVM
(either as a library or as an installed tool chain) and hence on its
dependencies, but it would be nice if we could be compatible
Hello again Jonas,
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, November 10, 2009 3:46:59 PM
Subject: Re: [fpc-devel] LLVM Backend?
-snip-
I don't see any problem at all with announcing
40 matches
Mail list logo
