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 d
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 there's
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?
Re
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 Del
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
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 i
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
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.
That
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
> 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
detai
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 time,
> 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:
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 thoroughly
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.
I have studied clang project a bit (as C/C++ frontend for LLVM) and it
actually makes more sense to me t
> > There are classes to create any type documented at
> http://llvm.org/docs/ProgrammersManual.html#Type . As of the current 2.6
> release there are now more extensive C bindings included with LLVM than were
> previously available. Once I get the trunk downloaded I'll see about a link
> to
On 12 Nov 2009, at 18:15, Samuel Crow wrote:
- Original Message
From: Jonas Maebe
To: FPC developers' list
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 a patch
to add
Bo
Hi Jonas,
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> 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 a patch to add
> Bo
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 c
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
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,
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
http://lists.freepascal.org/mailman/listinfo/fpc-dev
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 doe
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 t
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 gene
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> 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 a
> lot of ini
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
misund
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> 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 is
> definit
On 11 Nov 2009, at 16:55, Samuel Crow wrote:
- Original Message
From: Jonas Maebe
To: FPC developers' list
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 backend doesn't support all
targets
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> 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 the l
Message
> From: Michael Schnell
> To: FPC developers' list
> 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
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 mach
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) d
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 proble
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 co
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> Sent: Tue, November 10, 2009 3:46:59 PM
> Subject: Re: [fpc-devel] LLVM Backend?
>
>
> On 10 Nov 2009, at 21:35, Samuel Crow wrote:
>
-snip-
> > Do the object-oriented featu
Hello again Jonas,
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> 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 that people are working on a
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 w
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 pos
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
th
Hello Jonas,
(Replies inline.)
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> Sent: Tue, November 10, 2009 1:57:03 PM
> Subject: Re: [fpc-devel] LLVM Backend?
>
-snip-
> The main things that basically halted my work on the LLVM backend
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 the
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 con
43 matches
Mail list logo
