So, today we have a, despite the slide saying Arthur,
this is with Pierre Manu, going to speak about GCCRS.
Give him a welcome.
And, really well.
Hello everyone, so I'm not Arthur, so I try my best
so please be with me and I'll do my best.
Yeah, okay.
So, I'm a compiler engineer at Ambicosm
and I'm not the co-lead of GCCRS.
I believe there's Philip in the room but I can't see it.
So, yeah, Philip is one of the co-lead of GCCRS.
What will we talk about?
So, I'll introduce GCCRS because some of you
may not know the project.
I'll talk about what we've achieved this year
and what we've done, basically.
And what we will do in the future in the upcoming year.
So, there's a lot of things that's gonna change
and I need to introduce those.
So, let's begin.
So, what is GCCRS?
GCCRS is an alternative compiler for Rust.
So, you may already know Rust C
and we aim to provide a new front end
for the Rust language within the GCC project.
So, there's already a lot of front end in GCC.
There's Hada, Go, and many of them Fortran.
So, there's just one new front end
that could leverage the GCC back end
as well as the GCC plugin system
on the GIMP representation.
We are targeting for version 1.49 of the Rust language
and the work is funded by Mbacosm
as well as Open Source Security.
So, we'll talk about the points.
Why should we create a new compiler?
So, there's a whole lot of architecture
that aren't supported by the LLVM back end.
So, there's already work for a new Rusty compiler
for to leverage, for example, GCC JIT
to get some GCC targets.
And yeah, so basically, we are to leverage
those new architecture and provide more target
for Rust C.
You may check the GCC room later tomorrow actually.
So, there will be more about this.
There's another big point.
It's the Rust for Linux project.
Basically, the Linux channel wants to integrate
Rust program language in Scott Bayes.
And this means we need some people want some support
for the Rust language from the GCC project.
Having multiple compiler apps,
there was multiple domains where helping on this service
draws some attention on some dark spot in the Rust language.
So, we could show the Rusty people
what could be improved, what is good.
Yeah, so this brings some discussion about some subjects.
And after I've been working on Rusty,
on the macro group, for example.
So, a lot of things that's brought by new compiler.
It's bring new point of view for things.
One last thing is working with very old
plus plus compilers.
There are some architecture systems
that have some very old compilers.
We just compile them in C++ or C.
And you may want to bring the Rust ecosystem
to the systems.
So, yeah.
What we've been doing in 2023.
2023, we had three multiple Google summer of code projects.
One was by
Mohamed, who was working on the error framework for GCC.
We basically want to introduce
friendier error codes,
like we can find in the Rusty compiler.
If you've used the Rusty compiler,
you may have seen friendly error codes or user error.
And we want to bring this to the GCC ecosystem.
And the second new Google summer of code was from Raikey,
which I believe, yeah, he's there.
You could see tomorrow in the GCC dev room,
which implemented multiple things to support Unicob.
We've been working on borrow checking,
closure, iterators, and a lot of things.
We, I also worked on Proc Macros.
So, Proc Macros are baking Rusts.
Their views are used almost everywhere.
So, yeah, I've been working on this in the past year.
We are able to expand some Macros right now.
And it's not completely polished, but it's almost finished.
We had to develop a new binary interface.
This is a new system in GCC to leverage Proc Macros.
And you may as well see my talk from code one,
Google code one 2023,
if you want to get deeper into the subject.
Okay.
I've been talking about the borrow checking.
So, we, Jacob Dupac has been working on the borrow checker.
Basically, Rust C has a pass in the compiler
which emits an IR on the borrower checker,
work on this IR to attest and check that some facts are valid,
that the code is valid and that the borrow checking rules
are all assorted.
So, Jacob Dupac has been working on a new IR in GCC.
So, we could have a borrow checker.
It leveraged Polonius.
So, if you've been working on Rust C,
you probably already know Polonius.
So, this is representation of Rust C on the left
and GCC on the right.
As you may see, Rust C,
MIR is the borrower checking steps
and the MIR is then lowered to LVMIR.
In GCC, we've been doing things a bit differently.
Basically, we had to separate two IRs
and there is one kind of dead end IR
specialized in borrower checking
because we couldn't create an IR that could send
below words to the GCC back end.
So, at one time in the compiler,
there will be two parallel IRs that could be created
and on one end there will be GCC tree
and on the other end there will be BIR
and those will be checked.
But the BIR won't be reused for the creation
of your final record.
I've been talking about the InCode support.
So, yeah, I told the InCode support was by Raikey.
Told you tomorrow there will be more.
Rust code, so we want to be able to pass the Rust C test
so this means we should be able to emit the proper error codes
and this means we need to fix our own error codes
to make those the same as Rusty.
We are opening a few more entries this year
for the GSOC for students to help us.
Feel free to apply if you want.
So, what we will be doing in 2024.
We aim to implement format arg macro
as well as the continue the work on the Polynesboro checker
as well as the traits.
Why do we need a smart arg macro?
Basically, this macro is required
in order to compile the standard library
and we would like to be able to compile
even a simple yellow world.
If you have ever used yellow world,
you may not know it, but under the hood,
there is the format arg macro to format all your arguments
and without this, we cannot even compile a simple yellow world.
So, yes, this will come soon before GCC 14, hopefully.
Currently, our borrow checking pass only
rejects some invalid code for some facts
and we still miss a lot of facts
and we still miss a lot of things.
So, yeah, we hope to implement more fact validation
from the Polynesian engine.
Okay.
So, we cannot change our strategy for GCRS.
We've met people at the ERRORUST in Brussels
a few months ago and those were people from the ERRORUST team,
I believe as well as the type language team
as well as the trait team.
And those people told us that the work required
to make the trait solver work was like
easy to do, but to get it right,
you need a lot more work.
So, basically, if you want 90% of the work done,
it's easy, but if you want 99% of the work
on the trait solver, it will be a whole lot of work
because there is many rules
that are very specific to some code and, yes,
it will be very hard.
So, in order to do this,
we chose to not implement those ourselves
but leverage existing RUST code.
So, we'll be using different RUST libraries
in the RUST compiler within GCRS.
So, yeah, what I was saying,
we'll be using RUST code within GCRS.
So, that means there will be two steps
in the GCC bootstrapping process.
The first one will compile GCC RUST
without Borough Checker, without a proper trait solver.
And that's only a later step that GCRS will compile itself
with the Borough Checker as well as all those fancy stuff.
Yeah.
The first version of GCRS,
the one without Borough Checker,
without all those things should never land
in the end of users.
That's only for bootstrapping purpose
and, yeah, nobody should use it.
Here is a schematic about it.
So, yes, as I told you,
bootstrapping process will be in two stages.
First, we'll compile GCC RUST stage one
without the Borough Checker.
Then we'll compile Polyneus
and then we will compile GCC RUST
with Polyneus within embedded inside it.
The format argument parser
follow the same principle.
We will compile it as a separate library
and then we will link it.
So, in order to do this,
we need to make a version of GCRS
which can compile the format argument parser RUST code.
And, yeah, that'll be it.
Let's look at the plan.
So, we need a type checker,
micro expansion, name resolution,
as well as format argument.
So, we will integrate those
in the compiler in a two-step bootstrapping process
in order to then be able to compile the standard library
and then be able to call your favorite print line macro.
Yeah, compile it after.
On a long term, what should we do?
So, we want to catch up with RUST
or line exterior requirements.
We want to be able to compile RUST code
that should be used for Linux model.
So, RUST for Linux targets
a much more recent version of RUST.
I believe it's 1.70, I'm not sure, don't quote me on that.
But, yeah, we still have some additional work.
It won't be that hard because once we have
the standard libraries that compiles,
there's not many things that are left
because most of the work in RUST
is done within the standard library,
not in a language itself.
Yeah.
And then, we need some analysis
as well as semantic testing.
We do not enforce at the current time
some runtime guarantees.
So, for example, array bound checkings,
that kind of things.
RUST panic when you try to access an array
out of bounds, those kind of things.
So, those are not generated yet by compiler,
so we still need to add that.
And we need to ensure the compiler assembly
produces the exact same behavior as RUST.
We want to leverage the RUST test suite
in order to be sure that GCRS is compliant
with the RUST compiler.
We need to work on a lot of improvements,
more CI because currently all CI
is like four little steps and that's all.
We want to make sure the GCRS work
with every architecture supported by GCC.
For example, we have some build failure
with some Spark backend, so yeah,
let's make sure Spark work again.
Spark 64.
And one thing we want to add in the upcoming year
is more upstreaming.
Last year, we were a bit late
and work was coming and coming
and we didn't upstream as soon as we wanted to do.
So yeah, we want to upstream more frequently.
This will avoid this kind of situation
where we want to push 900 commits in one mail
and we GCC a new repository and we're everything crashed
because well, it is not supposed to under 900 commit
in one time.
We want more contributors, more students
and yeah, more fun too.
Thank you for two open source security and because them
and a few members from the RUST community
which are helping us getting detailed from RUST.
There's a lot of people with a lot more experience
in the RUST compiler that's helped us
to improve the GCRS compiler
and as well as many contributors.
So Tomah, Mark and even Riki here.
Thank you.
Here are different links to our blog, Github
if you want to contribute the ISC channel
as well as the main list.
Yeah, so I'm a bit early, I'm sorry, but yeah.
Not my slide, sorry.
Yeah, you're the second replacement speaker.
What?
You're the second replacement after Arthur and then.
I don't know.
So you're, yeah, as a replacement speaker.
I think you did a very good job.
So can we.
Yeah.
Yeah.
Thank you.
Thank you.
Thank you.
Great, we do have some questions up here at the back
coming around.
Yes, so they'll have a microphone for the
the stream, but if you could repeat the question anyway.
Thank you very much.
Thank you.
I have two questions actually.
The first one is related to the borough checker.
So right now the borough checker is really deeply tied
into MIR.
How are you going to guarantee that you have
compatibility between the MIR based borough checker
and the beer based borough checker?
Basically we.
Repeat the question.
So the question was, will we integrate the borough checker?
Is that right in the GCR?
How do you make sure that it's compatible?
I'm sorry, I didn't.
How do you make sure that the borough checker is compatible?
We'll be using the same.
So how will we make sure the borough checker is compatible?
Basically we will reuse the same borough checker as RACI.
We'll be using Polonius.
So Polonius could be compiled as a library.
We'll just be making an FFI interface
and use that interface in order to directly use
Polonius within GCC.
Okay.
And my second question is, do you think you will be able
to emit wasm also?
I'm sorry, it's very hard for me.
One of the nice things with the current REST-C
is that you can emit wasm, WebAssembly.
Can you do that?
Do you think you will be able to do that with GCC-RS?
Yeah.
Okay.
That was a nice answer.
Hello.
From, as a GCC developer,
how can we help from the GCC side?
Well, you could drop by our GitHub repo.
I mean, there's a whole lot of controversy within the GCC.
Sorry, I will repeat the question.
How as a GCC developer could we help
on the GCC-RS project?
Is that right?
Yeah.
So as GCC, there's a whole lot of controversy
on the GCC project somewhat because we're using GitHub
and GCC guys don't really like it.
So there's, I mean, you could,
I believe you could use your user workflow
for pushing patches upstream, but I'm not sure.
I think the best way to help us is to come to
and in our GitHub repository, clone it
and basically to like everyone, submit issues,
solve issues and yeah.
So over here we have a gentleman who would like to.
Hey, I just want to clarify the WebAssembly
so GCC does not currently have a backend for WebAssembly.
So if you want to emit WebAssembly,
you first have to write a backend unfortunately.
There is however precedent in GCC
for other high level assembly backends.
So it should actually not be too difficult to do,
but not available right now.
Okay.
Two questions.
First one is you mentioned at the beginning
compatibility with GCC 4.8.
What are the consequences of this choice
from a technical point of view?
Yes, here.
Yeah.
I mean, you have the modern GCC code base
and you want to your code to be compatible
with this old code base.
Basically for those who are not accustomed to GCC,
GCC 4.8 is a very old version of GCC
which doesn't even support C++11 at least not entirely.
So we have few steps in our CI to make sure
our code is compatible with GCC 4.8
because there are some constructs in C++11
that are not supported by GCC 4.8.
So we need to make sure we don't introduce
those constructs into compiler.
So GCC 4.8 could bootstrap our GCCRs compiler.
Thanks.
And second question.
Rust performance rely on LTO
and GCC and LLVM have different LTO strategies.
Does that impact you in any way?
I haven't much to say about that
because we're not at the stage in the compiler
development where this matter,
we want things to work first and then apply
fix on tricks to improve performance.
For now we won't focus on a working compiler
before focusing on things that work fast.
Thanks.
Yeah, I just had a...
Oh, loud, loud, very loud.
Oh.
I had a...
If I didn't misunderstand,
you said that one of your goals was to be able
to compile GCCRs with itself,
but without the borrower checker or string formatting.
I would just like to know what would be the benefit
of doing that instead of just compiling with Rust C
until you have a working borrower checker.
I'm not sure I understood your question.
Could you please speak louder?
What would be the benefit of compiling GCCRs with itself
without a borrower checker or compiling it with Rust C?
Okay, so what are the benefits of compiling GCCRs
without borrower checker and then with a borrower checker?
So basically, that's the slide here.
Borrower checker as well as trait solver
and many systems like this are very hard to implement.
We would need a lot of time
and we don't have much resources.
So we want to focus on making the compiler work,
even if it means compiling,
reusing components from Rust C.
So this means we first produce a first compiler
without borrower checker that knows
that the Polonius, for example, works well
because Polonius has been compiled with Rust C.
So Rust C leveraged the missing borrower checker step
for GCCRs and this version of GCCRs
will then be linked with Polonius
so it can leverage it itself.
So basically, this is a temporary version
that the user should never see
and that the user will probably never see.
This is a version that will stay on the build machine
of someone who wants to build GCC.
And yeah, most of you won't ever see it.
And yeah, that's it.
You didn't understand quite well, am I right?
Yeah, I understood that you were going to use
the GCCRs version that didn't have
the borrower checker and string formatting
to compile GCCRs itself.
That's what I'm saying, I don't know.
Maybe I misunderstood.
How do you say it?
Quite...
I think what he meant is he wanted to know
why you want a bootstrap step
that is free of Rust C.
What the need is in this?
Because we need to be able to compile Polonius.
You need to be a separate compiler.
I don't remember.
I'm sorry, but those are steps that are not yet implemented
and events look much into it.
So I don't want to say some mistakes or anything.
So...
So you don't support all the architectures that GCC supports.
So if you want a bootstrap on an architecture
that's not Rust C, you want to put it back on.
Oh yeah, okay, thank you.
I had another question.
You talked about the Rust C type of errors
and also panic with out of bound access.
Is there a possibility that we will see this
for other languages in GCC from the work you have done?
Yes, because...
Don't quote me on that, but as I remember it,
the students that made the change of framework
for the errors made change to some common directory
in the GCC project.
So Auto Frontend may be able to use this new code.
So maybe.
But I mean,
ZodChanger won't...
Won't come by themselves.
Confibrators on all of the languages.
We need to integrate those in ZodChanger Frontend.
Good, okay.
So I understand your point in reusing
the Borow Checker and the Format Arc stuff
because it's already done and it's known to work,
so why not reuse it?
On the other hand, on your slide,
why you are doing this GCC-RS project,
you quoted the point that you want to provide
an alternative second implementation next to Rust C
because it oftentimes helps to have different implementations
of the same stuff to better understand
what the stuff is all about,
to better understand the design.
Maybe there is something strange in the design,
you just don't notice if you only have one implementation.
So this would be a point for also having a second Borow Checker,
for also having a checking format ArcSwan.
So what is your philosophy?
Where do you draw the line between
we want to implement a second independent system
and we want to reuse proven code?
Yeah, the question was where do we draw the line
between components that we need to code ourselves
or reuse from the Rust C project?
I would say that.
I mean, we don't draw the line
because those are merely temporary solutions.
We want to project to get to a better understanding
of a state which compiles the Rust code,
but in the long run, that won't be the case.
We will probably reimplement those components
in C++ within GCC.
So yes, for now,
we simply choose components that are too hard
or need too much time.
Yeah, in the long run, we may replace them
with our own implementation.
Hi, so my question is a bit, let's say different,
in the sense that what would be wrong with, for example,
emitting GCC tree directly from Rust C?
This way you have, I think, maximum reuse
already compiled Rust, you know,
because you don't use LVM, but instead you use Rust GCC tree.
And you could, for example, use a feature flag
to toggle between these two things.
So would there be a merit to exploring this?
I'm not sure.
I'm not sure, I'm understanding your question.
Are you talking about the GCC JIT backend in Rust C?
Yes.
Yes?
Well, one thing,
this means we get a new front end
which bring diversity on one end.
And I believe we could backport the new front end
as well as some multiple things
to an earlier version of GCC for really old systems,
which we cannot do on Rust C.
Yeah.
Well, I think my question was a bit different
in the sense that Rust is a bootstrapping compiler.
And the only C++ parts it really needs to function,
I might be wrong here, but is LLVM in the end?
So instead of LLVM, you could substitute
in just a different backend.
I don't want to say any mistakes,
so I think you should come to Zulip
and ask directly to Arthur
because it will be way better than me
to give you a proper answer.
I'm sorry.
No problem, thank you.
Sorry.
So to answer that question, you gave the reason yourself.
You said you want to support GCC for eight,
but the thing is GCC for eight
doesn't have the JIT part yet.
Yeah.
So like if what he was talking about
was the Rust C code can GCC thing
that Rust already supports.
So you can actually already use GCC JIT
to generate code using the Rust C front end.
But again, that does not work
when you want to support very old versions of GCC.
And that is actually what I wanted to ask.
I wanted to ask, do you actually plan to upstream GCC RS
support in GCC for eight so that people
who actually want to use it in an old GCC version
don't have to like patch it themselves?
Probably, I mean for now we're focusing
on only upstreaming things that we could maintain and support,
but it could be possible in the future.
So probably, I don't know yet.
So to answer your question, follow up on your thing.
So I'm the maintainer of libGCC JIT.
I apologize for the name,
because it also does ahead of time
compile compilation and worst project name ever.
And that itself is a part of GCC
and therefore its build time dependency
is the same as your build time dependency.
So as in the subset of C++11 that GCC 4.8 supports.
In terms of the other question,
in terms of back porting the GCC RS work
into GCC 4.8 itself, I believe GCC 4.8
is still written in C.
I'm not sure it's about then that we migrated from C
to C++98 and that sounds like, that sounds difficult.
That sounds like, yeah.
But there is a bootstrapping path.
We had another question over here
and then thank you for being a good sport.
Is there a question over here?
Okay, all right.
No more questions.
Wonderful, can we thank our speaker again?
Thank you.