Re: GSoC age limit

[Philip Herron]

Hi,

I am the maintainer for the GCC Rust project and feel free to ask questions
and join our zulip server I can help mentor you on some work if you want to
gain experience.

You will need to get proficient with C++ so I think spending time getting
used to writing C++ would be a great thing to do in the meantime as well.

Thanks

--Phil

On Wed, 10 Feb 2021 at 12:25, Martin Jambor  wrote:

> Hi,
>
> On Wed, Feb 10 2021, oilab kowaski via Gcc wrote:
> > Hi! I am very interested in parsers and compilers. I would be very happy
> to
> > participating in the development of GNU Rust compiler by applying to the
> > Google Summer of Code. But I am 17 years old and I do not satisfy the
> > requirements of the GSoC. What would you suggest me to do?
>
> I am afraid that means that there is no way for you to be paid this
> year, at least not by Google.
>
> That does not mean you cannot pursue your interest in parsers and
> compilers with us though.  Look at the gcc-rust repo (currently on
> github), contact the authors and see if you can contribute to the effort
> informally.  I am sure they will appreciate any help.
>
> I am also sure that there will be work to be done on the Rust-gcc front
> end for years to come, so if you become a contributor this year, you
> will be in a prime position to become our GSoC student next year.
>
> I understand that the financial renumeration is an important incentive
> to participate in GSoC but I am afraid we cannot offer any more help,
> Google will not change their rules for us.
>
> Martin
>

Re: Interested in GSoC 2021: Rust frontend

[Philip Herron]

Thanks for your interest I see you have already joined our zulip channel
and I have replied to you off-list.

Thanks again,

--Phil

On Sat, 13 Feb 2021 at 06:59, 孙译喆 via Gcc  wrote:

> Hello, I’m looking to contribute to the project regarding the Rust
> frontend.
>
> I’ve compiled the project from the Rust-GCC repository and ran the
> testsuite. Any pointers what to do next?
>
> By the way, is the mailing list the prefered way of communication? Or
> should I use Zulip/Discord?
>
> Regards
> Yizhe

Re: GSoC

[Philip Herron]

Hi George,

I am the maintainer for GCC Rust, please feel free to join our zulip server
https://gcc-rust.zulipchat.com/, there are other students on the server
also. In terms of getting involved, the first thing to do is make sure you
are able to download the code via git, compile and run the test suite.

After you are able to do that I would suggest writing some test cases and
running the compiler yourself to get familiar with it. As part of helping
students get started, I have been trying to create issues tagged with
good-first-pr
https://github.com/Rust-GCC/gccrs/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-pr
and feel free to ask questions and guidance on those specific issues as a
coding starting point.

Does this help?

Thanks

--Phil

On Fri, 12 Mar 2021 at 09:26, ΓΙΩΡΓΟΣ ΛΙΑΚΟΠΟΥΛΟΣ via Gcc 
wrote:

> To whom it may concern ,
>
> My name is George Liakopoulos and I am an undergraduate student in the
> Department of Informatics at the University of Athens .
> The past 4 years I code in C/C++ , as my department is focused very much in
> these languages .
>
> I would like to contribute to one of your GSoc 2021 projects and more
> precisely
> in the "Rust Front-End" project . The last few days ( from the
> organizations announcing ) I look into the git-repo code and I am quite
> excited .
>
> I would like to ask you if there is something that i could do from now , to
> warm up and get more familiar with the project . Can you point me to a more
> specific direction ?
>
> I look forward to hearing from you ,
> George Liakopoulos
>

Re: GSoC

[Philip Herron]

Hi Isitha,

Thanks for your interest in GCC Rust, it's an exciting project that is
early on in development, so there is plenty of scoping for making your mark
on the compiler. In regards to your proposal feel free to join our Zulip
server https://gcc-rust.zulipchat.com/ and it can be discussed with the
community.

As for the Google Summer of Code timeline, I would have to defer to their
rules. Maybe others here know better in this mailing list but as far as I
know, to complete the google summer of code there are dated milestones of
review so this might break the rules if you have exams and are unable to
allocate the time towards it.

Hope this helps, I hope it works out for you.

Thanks

--Phil



On Fri, 19 Mar 2021 at 08:04, Isitha Subasinghe via Gcc 
wrote:

> To whom it may concern,
>
> I am a student interested in participating in GSoC this year. After having
> a look at some of the available PL projects, gccrs caught my attention. I
> love Rust and have an interest in exploring more about type theory and
> automatic garbage collection.
>
> My background is that I am a Masters's student at the University of
> Melbourne in Australia, I have undertaken a graduate-level compiler class
> where we implemented a stack-based compiler in Haskell.
>
> I am quite interested in working on the static analysis project but wanted
> feedback to iron out and address my proposal before I submit it.
>
> I am quite confident in my C/C++ skills but somewhat unsure about the level
> of knowledge of static analysis that I would need. Unfortunately, I am yet
> to take any classes in this particular subfield but I am absolutely happy
> to learn on my own time and have purchased the book Principles of Program
> Analysis to assist with this matter.
>
> Also, I did want to notify you that I would be available for less than the
> entire coding duration of GSoC due to university commitments.
> Unfortunately, my exams overlap with GSoC, and it is hard to compromise on
> University studies since I am hoping to do a PhD in PL after the completion
> of my master's. I would be absolutely happy to make up this time at the end
> of the year where I have a 3-month break.
>
> Best Regards,
> Isitha
>

Re: GSoC Rust

[Philip Herron]

Hi Aidan,

Thanks for your interest in the Rust Front-end project
https://github.com/Rust-GCC/gccrs. I have prepared a specific wiki page for
Google Summer of code you might find useful:
https://github.com/Rust-GCC/gccrs/wiki/Google-Summer-of-Code.

Please feel free to join our Zulip server:  https://gcc-rust.zulipchat.com/
to ask any questions you might have. I would recommend as a starting point
to download the code via git and follow the README instructions to compile
and run the test suite to get started.

Hope this helps.Thanks,

--Phil

On Thu, 25 Mar 2021 at 03:03, Aidan Goldfarb via Gcc 
wrote:

> Hi,
>
> My name is Aidan Goldfarb and I am a junior studying Computer Science at
> the University of Rochester. I am very interested in working on the Gnu
> platform for the 2021 Google SoC, specifically any projects that involve
> Rust programming. I notice projects such as several Rust Front-End
> projects. I would love to discuss this idea more, as I think my knowledge
> and experience make me a strong candidate for this position.
>
> Thank you for your time,
> Aidan Goldfarb
>

Re: GCC Gathering in London 17/Jun to 19/Jun 2011

[Philip Herron]

On 8 April 2011 21:15, Diego Novillo  wrote:
> We are organizing a gathering of GCC developers and interested parties
> at the Google office in London, UK for the weekend of 17-Jun-2011.
> The gathering will be Friday evening, all day Saturday, and Sunday
> until some time in the afternoon.
>
> The idea is to simply get together and discuss current/future work,
> coordinate efforts, and perhaps do some collective GCC hacking.
>
> The format is going to be an informal unconference:
>
> - No papers.
> - No prepared presentations (unless it's really interesting).
> - No attendance fees.
>
> Google will provide meeting facilities and food.  We have space for
> about 100 people.  Attendees are responsible for travel and
> accommodations.  We will meet Friday evening and coordinate a list of
> topics for discussion.  We could also work something out in advance.
>
> At the moment, we need to know how many developers would attend.
> Please RSVP before 22-Apr-2011.  Let us know if you might come; it's
> not a commitment.
>
> The Google London office is near Victoria Station at
>
> Belgrave House
> 76 Buckingham Palace Road
> London SW1W 9TQ
> United Kingdom
>
> http://maps.google.com/?q=Google%20London@51.495238,-0.146663&hl=en
>
> Diego and Ian.
>

I may actually be in England around that time to see my brother but
not sure yet might be cool to pop along and say hi if i am to be in
england at that time at least :)

Have fun anyways.

--Phil

Re: Reminder - GCC Gathering in London 17/Jun to 19/Jun 2011

[Philip Herron]

Looks like i should be in England at the time kind of nervous pop'ing
along but i plant to be there so might as well :)

--Phil

GSOC - Student Rondup

[Philip Herron]

Hey all,

I was talking on IRC the other day with others and we thought this
would be a nice idea, to ask all GSOC students how were all getting on
working within GCC. As i am sure you have noticed GCC is a pretty big
piece of code and it can be hard to get to grips with it all. I am
kind of lucky because i was on GSOC last year and spent most of the
summer if not all just getting comfortable with it.

So i thought we could use this as a thread to introduce us a students
to each other I'll go first!

My name is Philip Herron I'm from Ireland and i got inspired by Paul
Biggars work into PHC http://www.phpcompiler.org/ to implement a
python front-end to gcc. Its hard but just something i find
interesting more than anything. I'm am getting on quite well with my
project, spent last week after the GCC meet-up in London cleaning up
my IL and now i am implementing my own pass system as i have to
iterate several passes over my IL (for various reasons) before i
generate GENERIC.

As i was on GCC last year i thought i would share things i found to be
helpful when you encounter a problem:

1 - Work at it for max 1 day on your own but definitely try to join
our irc on irc.oftc.net #gcc and ask. If you still find no help send a
mail to gcc-help

2 - gcc -save-temps can be helpful now and again when working with
alot of macros

3 - ack-grep is very helpful: http://betterthangrep.com/ makes
searching though code much easier than learning to use grep properly
:P

4 - Don't be afraid to ask questions as often as possible on irc and
to your mentor I've bugged my mentor Ian with alot of really stupid
small things all the time :) but they don't bite.

And just finally i thought i would ask what aspects have you found
within gcc hard to get to grips with if at all, it could be
interesting to see if there is any correlation between areas.

Personally i found getting to grips with Makefiles properly was hard i
used to rely on automake for everything before. And learning to figure
out how to use the generic tree api was confusing but in the end its
very simple. We've found not all students are on irc its a really
great platform to ask questions very informally its worth getting used
to you can use web clients like mibbet irc or firefox extensions, i
use irssi but those clients are much more friendly.

Hope everyone's project is going well and your comfortable or getting
more comfortable with what your doing! :)

Happy Coding!

--Phil

PS: what do you think of the idea if we have a thread like this every
few weeks or sooner (maybe on irc)? Just to see if we can help each
other etc?

Re: Google Summer of Code 2011 Doc Camp 17 October - 21 October

[Philip Herron]

On 12 July 2011 16:07, Diego Novillo  wrote:
>
> We discussed this briefly at the recent London meetings.  If anyone is
> interested in participating, please contact me.
>
>
> Diego.
>
>  Original Message 
> Subject:        Google Summer of Code 2011 Doc Camp 17 October - 21 October
> Date:   Mon, 11 Jul 2011 17:41:02 -0700
> From:   Carol Smith 
> To:     Google Summer of Code Mentors List
> 
>
>
>
> Hi everyone,
>
> This is a call for proposals for the 2011 Google Summer of Code Doc
> Camp. Individuals and projects are invited to submit proposals for the
> GSoC Doc Camp to be held at Google's Mountain View headquarters
> (California) 17 October - 21 October.
>
> The GSoC Doc Camp is a place for documentors to meet, work on
> documentation, and share their documentation experiences. The camp aims
> to improve free documentation materials and skills in GSoC projects and
> individuals and help form the identity of the emergent free
> documentation sector.
>
> The Doc Camp will consist of 2 major components - an unconference and
> 3-5 short form Book Sprints to produce 'Quick Start' guides for specific
> GSoC projects.
>
> The unconference will explore topics proposed by the participants. Any
> topic on free documentation of free software can be proposed for
> discussion during the event.
>
> Each Quick Start Sprint will bring together 5-8 individuals to produce a
> book on a specific GSoC project. All participants of the Doc Camp must
> attend a sprint. The Quick Start books will be launched at the opening
> party for the GSoC Mentors summit immediately following the event.
>
> Individuals with a passion for free documentation about free software
> may apply to attend by filling out the application form [1] and
> submitting before 5 August. Those wishing to attend do not need to be
> from a GSoC project. Accommodation and food will be covered by the GSoC
> Doc Camp. Part or complete travel costs can also be applied for as part
> of the application process.
>
> Quick Start Sprint projects will be chosen from proposals submitted to
> the GSoC Doc Camp before 5 August through the application form [1].
> Applications for Quick Start Sprints are invited from projects that are
> part of the 2011 GSoC program. Quick Start Sprint proposals can nominate
> up to 5 individuals to attend and participate in the proposed sprint. A
> Quick Sprint proposal does not have to nominate individuals to
> participate - you can also use this as an opportunity to promote your
> project to Doc Camp participants. If the proposal is accepted the
> accommodation and food costs will be covered by the Doc Camp for any
> listed individuals and part or complete travel costs for each can be
> applied for (if applicable).
>
> The GSoC Doc Camp is co-organised by GSoC and FLOSS Manuals. Books
> Sprints and unconference facilitation conducted by Adam Hyde.
>
> [1] - https://sites.google.com/site/docsprintsummit/
>


Would Gcc internals documentation count or is it more for a whole
project documentation work? I probably missed the thing about this in
London since i had to leave on the Sunday morning.

I am kind of interested but i am unsure what kind of documentation
would be appropriate i've spent the last few days working on some
internals documentation on and off so its kind of fresh in my mind.

--Phil

Re: GSOC - Student Roundup

[Philip Herron]

On 10 July 2011 22:42, ismail kuru  wrote:
> Hi all,
> I am one of GSOC students. We have started the project with doing some
> experiments for checking the compatibility of
> OpenMP threads with [trans-mem] branch of GCC.
>  We made a presentation
> (http://www.gsd.inesc-id.pt/~mcouceiro/eurotm/1stmeeting/16-IsmailKuru.pdf)
> at EuroTM meeting at Paris
> (http://www.eurotm.org/1st-plenary-meeting-in-paris/program). It was very
> useful for project's future perspective.
> However, I got accepted as a PhD and I have lots of urgent organizational
> and administrative  issues to complete before the mid of August so  I have
> no chance to go on with project until mid of August.
> But I am optimistic for the project even if I do not have a overlapping
> time-schedule with GSOC.
>

Yeah my last years Gsoc time management i found hard mostly because i
had a really bad sleeping pattern and i would grind out and work way
too much for like 2 weeks then spend 2 days sleeping and then same
thing again.

It was kind of stupid but this year i treat it like 9-5 but i can seem
myself working on a lot more once i get to parts when its mostly a
grind at the moment i am filling in and fixing lots of awkward pieces
which takes time.

But Gsoc is very flexible so i wouldn't worry about having to do
things in RL if you feel your are on track in your own time frame then
your ok.

--Phil

Re: Google Summer of Code 2011 Doc Camp 17 October - 21 October

[Philip Herron]

On 12 July 2011 18:29, Diego Novillo  wrote:
> On 11-07-12 12:52 , Philip Herron wrote:
>
>> Would Gcc internals documentation count or is it more for a whole
>> project documentation work? I probably missed the thing about this in
>> London since i had to leave on the Sunday morning.
>>
>> I am kind of interested but i am unsure what kind of documentation
>> would be appropriate i've spent the last few days working on some
>> internals documentation on and off so its kind of fresh in my mind.
>
> Any kind of documentation is fine.  Internals, user documentation, etc.
>
>
> Diego.
>

I am quite interested in applying for this but not quite sure what my
proposal should be like. Should i just discuss my interest in
front-end and middle-end stuff and the lack of documentation currently
etc.

Plus the question "Who else would you like to recommend to attend the
book sprint?"

I can only think of you and Ian off the top of my head but i would
suggest Andi who has helped me a lot especially in documentation.

--Phil

Re: Interested In Doing Documentation Project

[Philip Herron]

On 16 July 2011 04:07, selma leathem  wrote:
> -- Forwarded message --
> From: selma leathem 
> Date: Fri, Jul 15, 2011 at 8:50 PM
> Subject: Interested In Doing Documentation Project
> To: gcc@gcc.gnu.org
>
> Hello,
>
> I am interested in doing the front end documentation project. How do I
> sign up for that, or learn what is going on with it at this current
> time please?
>
> I am an ex-physicist with some computing including c/c++ and technical
> writing experience who is trying to gain more experience in this area.
>
> Thank you,
>
> Selma Leathem
>

Andi Hellmund and i have actually done alot of work into front-end
documentation work maybe you could sync with us if your interested how
did you find this as a project and what are you interested in?

Re: GSOC - Student Roundup

[Philip Herron]

On 17 July 2011 13:21, Franck Z  wrote:
> Hello!
>
> Technically, I'm not a GSOC Student, but I've also started delving recently
> into the depths of gcc's source code.
>
> Would you mind I if joined your IRC Chat in case I'm stuck somewhere in my
> understanding of the source ?
Yeah of course its very friendly. The gcc-help or this list is also
great for help where maybe someone wasn't able to help in the irc
channel.

>
> There are indeed occasional questions that I don't dare to ask here, given
> that I'm not as an accomplished programmer as any one of you is.
>
> I hope you'll indulge me if I here introduce myself to you, although I
> surely wouldn't meet GSOC's application criteria.
Dont worry.

>
> My name is Franck (Z is not my last name initial, I keep using a pseudo
> because I've been using it on other social websites, where it is advocated
> not to give any personal information, mainly Yahoo Answers). For now, it
> doesn't hurt, as I'm far from proposing any patch! I'll meet FSF
> requirements whenever I'm asked to.
>
> I'm French. I graduated in the 90's and have been keeping occasional links
> with computer sciences, following my curiosity, but never really tackled on
> an industrial programming project on my own.
>
> The fact is that, a few months ago, I eventually dared to download gcc's
> source and subscribe to the gcc list, again out of curiosity, after reading
> a post from Walt Brian about C/C++ compilers being much slower than
> compilers for other programming languages.
>
> I skimmed up was I'm leaning toward in a former message here:
> http://gcc.gnu.org/ml/gcc/2011-06/msg00141.html
>
> In fact, I may opt for another way of doing, using event programming
> techniques between "make" and "gcc". Namely, instead of having "make" call
> "gcc" through several jobs, I consider having "gcc" being launched only once
> by "make" and then ask "make" about the tasks he should do, up to the
> numbers of jobs allowed when "make -j..." was invoked.

Interesting idea i have a feeling i read something about this recently
I'm not really sure how it could work in how you could query make to
get the next source, but at the same time sounds like it could be a
niche piece of tech although you could maybe just have it as a switch
in the front-end. It could possibly be handled at compiler driver
level.

> It seems to me that this would allow, besides the original aspect of how
> disk is accessed throughout a compilation session, to include a
> task-oriented parallelism in compilation tasks, with Intel's TBB library,
> based on the "natural" organisation of a compilation around *.c (or such)
> files.
>
> Actually, my main issue with respect to understanding gcc's source, is that
> my knowledge of C isn't precise enough to meet gcc's writing standards, for
> instance what I suspect to be workarounds to silent out some spurious
> warning messages in the compilation.
>
> I keep to the front-end part, so it's easier for now. Still, I'm *slightly*
> overwhelmed by the numerous tools and libraries I need to get precisely
> acquainted with, before I'm able to hack in (git, autogen, ...). Don't mock
> me, but, as a matter of fact, gcc's source being gigantic is part of my
> pleasure! I've enjoyed browsing similarly wide and intricated sources in the
> past years (for instance OCaml or TBB) and I relished learning from these.
>
> I hope I don't put too much hope in what I can do and that one day, I'll
> help a little teeny bit. :-)

Cool, happy hacking

--Phil

Projects

[Philip Herron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey

I have been lingering around the gcc mailing lists for sometime and
done a little work with a basic front-end, and working on doing decent
documentation into the gcc-internals manual.

But i would also like to get a little more involved, i got the gcc
copy-approval at the same time as i had to push my work into automake.

But i was wondering what work is there being done on:
http://gcc.gnu.org/wiki/Graphite/Parallelization

That is something i was always wanting to work on, but i was going to
make an external translator program to open-mp pragma's but this is
much better system.

Or would be great to know some good places to start, even what areas
need cleanup, just the projects list and regressions etc all seem to
be quite old and not sure which are still relevant!

I would like to do this for a while, but i was ultimately thinking of
doing a haskell implementation or python implementation maybe not too
sure haven't thought about it too much yet got my own work to finish
first.

Thanks

- --Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkp7jtcACgkQAhcOgIaQQ2EaFwCfRdd7bT4BqgzEIcAIq+bvWWOJ
PHEAnikkh1pi4YGdTKfrmWOuywy70uL6
=Xwti
-END PGP SIGNATURE-

Front-End error

[Philip Herron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey

I'm working on my own front-end its all just a skeleton based quite
closely off the java front-end/treelang,
But after i return true in lang_init i get the error:

gpy1: internal compiler error: in init_excess_precision, at toplev.c:2160

Really not sure where i can start to debug this any help would be
great. Another thing is i am not too sure how command line parsing
should work.

Is it that any option i specify in lang.opt i just need to handle in
lang_handle_option? And then i notice from:

static
bool lang_post_options( const char **pfilename )
{
  printf("lang_post_options!\n");
  const char *filename= *pfilename;

  if( filename == 0 || !strcmp(filename, "-") )
{
  printf("stdin\n");
  finput= stdin;
  filename= "stdin";
}
  else
{
  printf("file %s\n", filename);
}

  return false;
}

i notice it figures out if i say executed the compiler as:

./host-i686-pc-linux-gnu/gcc/gpy1 -v bla.lang

It will figure out that the filename to compile is bla.lang. But then
how does it work say if i use it to link lots of different .o together?

Thats a lot of different questions :)

- --Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqO+voACgkQAhcOgIaQQ2FbOACfb7qoSHTjJcSDHz0326SDA3KU
swIAn0P3iArXadmQXdEoAxzR9UTu/QiJ
=uiQP
-END PGP SIGNATURE-

Front-End errors again

[Philip Herron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey guys

I am having problems in building my front-end again, so i'll show you
the output.

lang_init_options...
argv[0] = ./host-i686-pc-linux-gnu/gcc/gpy1
argv[1] = -v
argv[2] = foo.lg
argv[3] = -Wall
lang_handle_option!
scode = 37
lang_post_options!
file foo.lg
lang_hooks.init()
lang_init!
done
init_asm_output (name);
init_eh()
Inside lang_dependent_init_target!
init_excess_precision
lang_print_error_function!
gpy1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Thats the output so far i've tracked the segfault to come from in
toplev.c

static void
lang_dependent_init_target (void)
{
  printf("Inside lang_dependent_init_target!\n");
  /* This determines excess precision settings.  */
  init_excess_precision ();
  printf("init_excess_precision\n");

  /* This creates various _DECL nodes, so needs to be called after the
 front end is initialized.  It also depends on the HAVE_xxx macros
 generated from the target machine description.  */
  init_optabs ();
  printf("init_optabs\n");

So it doesn't reach that last printf so it must be failing in
init_optabs, and i don't think i want to track this much further into
the gcc code so i am missing something in my front-end i just don't
know what yet. So from that comment i guess it must call something
like decl_* function from a front-end but i am not quite sure what
they are supposed to do, i mean i haven't even got a change to merge
in my own parser i made for a previous compiler to into this so i can
start working on the language proper.

Oh yeah i just want to say I really love how lang.opt works thats
really nice setup :)! Lang-specs.h is another file i am wondering i
added an entry into gcc.c the default compilers with the extension to
source files and also into a lang-spec.h but its very short:

  {".lg",   "@lang" , 0, 0, 0},

:) i am just calling this front-end lang i don't want to give the name
until i get a bit further into how the front-end works. But not sure
of what really should go in here other front-ends have very
complicated lang-specs.h and not quite sure whats it meant to
accomplish other than make the compiler aware of what the extension
should be.

The fortran one shows older fortran dialects turning on different
features on the fortran compiler i guess that another feature of it.

Anyways thanks again!

- --Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqW/IIACgkQAhcOgIaQQ2GcFQCeLpnPoWFfGdid2mcnS+wAFVlk
tk8An2IBHOFooHaIJqQMD6E5C7ctlKiP
=/5Oy
-END PGP SIGNATURE-

Re: proper c source coding standard - style changes?

[Philip Herron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David C. Rankin wrote:
> Listmates,
>
> First post, and more of a curiosity than a problem. Years ago I
> worked extensively with c, fortran, etc. (late '80s, early 90s). I
> do my own office infrastructure/networking/groupware, etc. all with
> linux and open source software. Occasionally that requires me to
> dust off my programming tools to tweak this or that to work in my
> setting. Most recently a bit of c with the mysql connector. In
> doing so I have noticed one big change to the way source files are
> now formatted.
>
> When I grew up doing this your source files and functions would
> normally be laid out in this order:
>
> #include 
>
> void function ();// function headers defs int *function ();
>
> int main () { do something; return 0; }
>
> void function () { stuff; }
>
> int *function () { stuff; }
>
> Now I see through much of the glibc documentation and other sources
> a layout like this:
>
> #include 
>
> void function () { stuff; }
>
> int * function () { stuff; }
>
> int main () { do something; return 0; }
>
> And, yes, I know it doesn't matter to the compiler, but as I said I
> was curious. Has there been some type of recommended standard for
> doing it in this way, or is it just more of a some people like
> chocolate ice cream versus vanilla issue? In the olden days, IIRC,
> the logic was that you wanted to see the most important part of
> your code up top -- the main function, without having to wade
> through all the function bodies before you got to it. With the new
> layout, you don't have to worry about an additional function def up
> top with eliminates the chance of typos and makes changes easier.
> So I see the benefits of both.
>
> Also, if this is some type of flame war issue like vi/emacs, I
> apologize in advance, I am not aware of its sensitivity, I'm just
> curious and like to follow the "recommended" standard in case
> somebody has to read my code in the future. Thanks.
>
> All I'm looking for is either a (yep there was a new
> recommendation, here's the link) or a (it's a chocolate or vanilla
> thing).
>
I take it you haven't done much programming, take a look at any
project on the net they all have their own code formatting preferences
for whatever helps _you_ read your code. This should probably be moved
to gcc-help...

A benefit of using the bottom formating is you don't need to keep
prototypes for the extra functions if they are being called by main.

Try not to ask questions like this in GCC, GCC-help is for help on
using gcc etc.

- --Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqZ2b0ACgkQAhcOgIaQQ2GJ4QCfXCtFIHeDfYIhoVAbMQNiEV/P
WVIAn2/61h/MwEb0f4LTdVnnZXwarbNo
=6paS
-END PGP SIGNATURE-

Thanks GSoC

[Philip Herron]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey

I want to say a quick thank you for accepting my proposal "Partial
Implementation of Python as a GCC Front-end".

Can't wait to get started :).

- --Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvXFL0ACgkQAhcOgIaQQ2HBWACgjGcGA5eZagf4Wcmob+Znu3G4
rgsAn06a1BbXLsmAfKUwm3BXVyR8d0Lz
=N0Nv
-END PGP SIGNATURE-

Re: GCC Internals FE documentation

[Philip Herron]

Hey guys

I am reposting this link to GCC-help and GCC to get more feedback on
some front-end documentation I added a lot more texinfo mark-up, not
quite sure if i can generate a pdf and the .info is quite big to send
around. so the link to look at would be:

http://code.redbrain.co.uk/cgit.cgi/gcc-dev/tree/gcc/doc/languages.texi?h=documentation

There are some texinfo errors I need to correct in the output it
compiles fine but the output some of the @fi...@var{}} inside verbatim
blocks were not liked.

I am trying to shape it into a tutorial so I hope that format is ok,
but it is less formal that some of the other gcc internals
documentation.

--Phil

GCC Rust git branch

[Philip Herron]

Hi everyone,

As some of you might know, I have been working on GCC Rust over on
GitHub https://github.com/Rust-GCC/gccrs. As the project is moving
forward and enforcing GCC copyright assignments for contributors, I
would like to create a branch on the GCC git repo to show the intention
to be upstream with GCC someday.

I tried to push the branch towards the start of the year, but I hit an
issue:

```
Enumerating objects: 4706, done.
Counting objects: 100% (4706/4706), done.
Delta compression using up to 8 threads
Compressing objects: 100% (1699/1699), done.
Writing objects: 100% (4412/4412), 3.33 MiB | 948.00 KiB/s, done.
Total 4412 (delta 3058), reused 3869 (delta 2683)
remote: Resolving deltas: 100% (3058/3058), completed with 271 local
objects.
remote: *** Invalid revision history for commit
c7c6f785c8e893ec7bcacd1a2319ce309d2450f2:
remote: *** The first line should be the subject of the commit,
remote: *** followed by an empty line.
remote: ***
remote: *** Below are the first few lines of the revision history:
remote: *** | Adding Rust target hook documentation
remote: *** | Added powerpc target hook and improved aarch64 feature
handling
remote: *** | Added DEC Alpha target hook
remote: *** | Added ARC target hook
remote: *** | Created ARM target hook (at least preliminary support)
remote: ***
remote: *** Please amend the commit's revision history and try again.
remote: error: hook declined to update refs/heads/gccrs
To ssh://gcc.gnu.org/git/gcc.git
 ! [remote rejected] gcc-mirror -> gccrs (hook declined)
```

The commit message here is poorly formatted. To move forward, should I
rebase the tree to fix this commit and force push to rewrite the
history? Or is there a way to relax the rule for a new branch? Any
advice would be welcome.

Separately, some contributors have expressed interest in maintaining the
GCC style communications of using a mailing list and irc. Is it
reasonable for this project to get a r...@gcc.gnu.org?

Thanks,

--Phil




OpenPGP_signature
Description: OpenPGP digital signature

Re: GCC Rust git branch

[Philip Herron]

On 28/05/2021 04:05, Thomas Fitzsimmons wrote:
> Hi Philip,
>
> Philip Herron  writes:
>
>> As some of you might know, I have been working on GCC Rust over on
>> GitHub https://github.com/Rust-GCC/gccrs. As the project is moving
>> forward and enforcing GCC copyright assignments for contributors, I
>> would like to create a branch on the GCC git repo to show the intention
>> to be upstream with GCC someday.
> I tried building GCC Rust on ppc64le.  With the attached patches,
> "make check-rust" succeeds with:
>
>   === rust Summary ===
>
> # of expected passes  2368
> # of expected failures26
>
> Thomas
>
Hi Thomas,

Thank you so much for doing this, we will merge these later today. The
results look the same as the numbers were getting on x86 too.

If you are interested I maintain weekly and monthly status reports for
the project over on: https://github.com/Rust-GCC/Reporting

Thanks

--Phil




OpenPGP_signature
Description: OpenPGP digital signature

Re: GCC Rust git branch

[Philip Herron]

On 28/05/2021 04:22, Jason Merrill wrote:
> On Mon, May 24, 2021 at 9:25 AM Philip Herron
> mailto:philip.her...@embecosm.com>> wrote:
>
> Hi everyone,
>
> As some of you might know, I have been working on GCC Rust over on
> GitHub https://github.com/Rust-GCC/gccrs
> <https://github.com/Rust-GCC/gccrs>. As the project is moving
> forward and enforcing GCC copyright assignments for contributors, I
> would like to create a branch on the GCC git repo to show the
> intention
> to be upstream with GCC someday.
>
>
>  [snip]
>
> Separately, some contributors have expressed interest in
> maintaining the
> GCC style communications of using a mailing list and irc. Is it
> reasonable for this project to get a r...@gcc.gnu.org
> <mailto:r...@gcc.gnu.org>?
>
>
> That makes sense to me; I think overseers@ can help set up a new
> mailing list.
>
> Jason

Thanks For the info everyone i will reach out to overseers about the
Mailing List idea.

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature

Re: GCC Rust git branch

[Philip Herron]

On 24/05/2021 19:29, Mark Wielaard wrote:
> Hi Philip,
>
> On Mon, May 24, 2021 at 02:24:13PM +0100, Philip Herron wrote:
>> As some of you might know, I have been working on GCC Rust over on
>> GitHub https://github.com/Rust-GCC/gccrs. As the project is moving
>> forward and enforcing GCC copyright assignments for contributors, I
>> would like to create a branch on the GCC git repo to show the intention
>> to be upstream with GCC someday.
>> [...] 
>> The commit message here is poorly formatted. To move forward, should I
>> rebase the tree to fix this commit and force push to rewrite the
>> history? Or is there a way to relax the rule for a new branch? Any
>> advice would be welcome.
> As Joseph said you could create a developement branch for hacking on
> the GCC Rust Frontend and relax the commit push rules for that one:
> https://gcc.gnu.org/git.html#devbranches
>
> Is the intention to eventually make this branch the main development
> branch? Or will it just be a mirror of the main github repo/branch?
>
> I assume it will be some months (years?) before this frontend will be
> merge into the main gcc git repo. I wonder if it makes sense to create
> a separate repo for the gcc rust frontend so you can use your own
> rules for development. Currently you are using some github services,
> like bors, that we might want to replicate. That might require some
> special git branches for the automation. We can then experiment with
> having a gccrs.git repo on gcc.gnu.org to see if such services can be
> replicated on our own server. And the gcc rust community might show
> other gcc developers whether and how that helps development.
>
> It would also be great if we could somehow have "normal" gcc bugzilla
> tickets instead of these github issue and pr numbers (which won't make
> sense anymore once the frontend is merged).
>
>> Separately, some contributors have expressed interest in maintaining the
>> GCC style communications of using a mailing list and irc. Is it
>> reasonable for this project to get a r...@gcc.gnu.org?
> Personally I would love to have a normal mailinglist, but I am
> personally somewhat (unrationally?) allergic to github and
> web-chat-systems. If we are trying to make this new frontend a bit
> more accessible to traditional gcc hackers, could we also have a
> normal irc channel (there is #gcc on irc.oftc.net). It would be great
> to also have a #gccrust channel on oftc.
>
> Cheers,
>
> Mark
>
Hi Mark,

I think a branch on GCC's git repo will be a mirror of the github, but I
think its really important for the project to respect GCC traditions. By
that I mean that we respect patches sent to gcc-patches such that they
are treated with the same respect as PR's on Github.

If for instance a Mailing list on gcc.gnu.org became more active than
github i think at that point i would have to reconsider this, and weigh
up switching the main development over to gcc.gnu.org.

As for the git hooks, is it possible that I amend the hooks within the
gccrs repo .git/hooks folder? Or is this something i need to change in
the GCC repo? Sorry i should really read up more on git hooks in general.

Thanks.

--Phil




OpenPGP_signature
Description: OpenPGP digital signature

GCC Rust monthly call

[Philip Herron]

Hello,

On the first Friday of every month, GCC Rust has a community call. The
next one will be on the 4th of June 2021, at 10am utc+1 (I am based in
Northern Ireland). We use our zulip server
(https://gcc-rust.zulipchat.com/), which provides a jitsi integration to
facilitate the video call. I want to invite people from the GCC
community to join if they wish.

These monthly calls have associated meeting notes for those who cannot
attend. Here is an example from our last meeting: 
https://github.com/Rust-GCC/Reporting/blob/main/2021-05-07-community-call.md

The agenda for this next call is currently being set up in a
collaborative document here: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg

Please find the monthly report for May 2021 for more information:
https://github.com/Rust-GCC/Reporting/blob/main/2021-05-monthly-report.org

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature

Re: GCC Rust monthly call

[Philip Herron]

Hi everyone,

Just a reminder that tomorrow is the community call: at 10am utc+1. The
agenda so far is detailed within: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg

The call will be hosted on Jitsi, here is the link we will use:
https://meet.jit.si/259057065581073

Thanks

--Phil

On Mon, 31 May 2021 at 12:48, Philip Herron 
wrote:

> Hello,
>
> On the first Friday of every month, GCC Rust has a community call. The
> next one will be on the 4th of June 2021, at 10am utc+1 (I am based in
> Northern Ireland). We use our zulip server
> (https://gcc-rust.zulipchat.com/), which provides a jitsi integration to
> facilitate the video call. I want to invite people from the GCC
> community to join if they wish.
>
> These monthly calls have associated meeting notes for those who cannot
> attend. Here is an example from our last meeting:
>
> https://github.com/Rust-GCC/Reporting/blob/main/2021-05-07-community-call.md
>
> The agenda for this next call is currently being set up in a
> collaborative document here: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg
>
> Please find the monthly report for May 2021 for more information:
> https://github.com/Rust-GCC/Reporting/blob/main/2021-05-monthly-report.org
>
> Thanks
>
> --Phil
>
>

Re: GCC Rust monthly call

[Philip Herron]

Hi everyone,

For those interested, you find the meeting notes of our call over on:
https://github.com/Rust-GCC/Reporting/blob/main/2021-06-04-community-call.md

Thanks,

--Phil

On Thu, 3 Jun 2021 at 12:33, Philip Herron 
wrote:

> Hi everyone,
>
> Just a reminder that tomorrow is the community call: at 10am utc+1. The
> agenda so far is detailed within: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg
>
> The call will be hosted on Jitsi, here is the link we will use:
> https://meet.jit.si/259057065581073
>
> Thanks
>
> --Phil
>
> On Mon, 31 May 2021 at 12:48, Philip Herron 
> wrote:
>
>> Hello,
>>
>> On the first Friday of every month, GCC Rust has a community call. The
>> next one will be on the 4th of June 2021, at 10am utc+1 (I am based in
>> Northern Ireland). We use our zulip server
>> (https://gcc-rust.zulipchat.com/), which provides a jitsi integration to
>> facilitate the video call. I want to invite people from the GCC
>> community to join if they wish.
>>
>> These monthly calls have associated meeting notes for those who cannot
>> attend. Here is an example from our last meeting:
>>
>> https://github.com/Rust-GCC/Reporting/blob/main/2021-05-07-community-call.md
>>
>> The agenda for this next call is currently being set up in a
>> collaborative document here: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg
>>
>> Please find the monthly report for May 2021 for more information:
>> https://github.com/Rust-GCC/Reporting/blob/main/2021-05-monthly-report.org
>>
>> Thanks
>>
>> --Phil
>>
>>

GCC Rust Monthly Call - 2nd July 2021

[Philip Herron]

Hi everyone,

It is that time again and we will be having our 4th community call over
on Jitsi for the first Friday of the month.

  * Date: 2nd July 2021
  o UTC: 0900
  o UK/Ireland UTC+1/BST: 1000
  o Central European Summer Time UTC+2: 1100
  * Monthly Report: WIP
  * Agenda (WIP): https://hackmd.io/A-b-G90YTNSCEVjiHXz7Qg

  * Jitsi video call: https://meet.jit.si/259057065581073


Here is the latest weekly report for the project:
https://github.com/Rust-GCC/Reporting/blob/main/2021-06-21-report.org

Please feel free to suggest any topics/questions you wish to be
discussed here or directly onto the agenda hackmd document.

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature

Re: Unit Type for Rust

[Philip Herron]

On 28/06/2021 14:49, Philip Herron wrote:
> Hi everyone,
>
> In Rust the language has the notion of the unit type '()', so for example:
>
>  fn foo ->i32 { ... }
>  fn bar() { ... }
>
> Foo has the return type i32, and bar has no return type, which means it
> is unit-type so that it can be a value assignable just like any other
> function call. You can also declare unit-structs or unit as a type on
> variables:
>
>  struct foobar; // empty unit struct
>  let a:() = (); // unit type
>
> I thought I could use GCC's void_type_node to represent the unit type
> and void_node for the value when assigning or using it, but this causes
> the ICE:
>
> ```
> In function ‘test’:
> rust1: internal compiler error: in create_tmp_var, at gimple-expr.c:482
> 0x13fd3bf create_tmp_var(tree_node*, char const*)
>     ../../gccrs/gcc/gimple-expr.c:482
> 0xe5d195 Gcc_backend::temporary_variable(Bfunction*, Bblock*, Btype*,
> Bexpression*, bool, Location, Bstatement**)
>     ../../gccrs/gcc/rust/rust-gcc.cc:2889
> 0xfe3479 Rust::HIR::Function::accept_vis(Rust::HIR::HIRVisitor&)
>     ../../gccrs/gcc/rust/hir/tree/rust-hir-full-test.cc:4414
> 0xf95cdb Rust::Compile::CompileCrate::go()
>     ../../gccrs/gcc/rust/backend/rust-compile.cc:49
> 0xf95b8b Rust::Compile::CompileCrate::Compile(Rust::HIR::Crate&,
> Rust::Compile::Context*)
>     ../../gccrs/gcc/rust/backend/rust-compile.cc:39
> 0xee92e7 Rust::Session::parse_file(char const*)
>     ../../gccrs/gcc/rust/rust-session-manager.cc:596
> 0xee8d76 Rust::Session::parse_files(int, char const**)
>     ../../gccrs/gcc/rust/rust-session-manager.cc:459
> 0xe45264 grs_langhook_parse_file
>     ../../gccrs/gcc/rust/rust-lang.cc:171
>
> ```
>
> I think because void_node is likely not COMPLETE_TYPE_P which means it
> hits the assertion when you need temporary's.
>
>
> Then Tom Tromey suggested I try a zero precision integer so I called:
> make_unsigned_type (0) for the type and then use integer_zero_node for
> the value, and this solves the problem; however, if I use this zero
> precision integer type for the return type on functions and turn
> optimizations on I get the ICE:
>
>    ```
>    test.rs: In function ‘main’:
>    test.rs:16:1: internal compiler error: in min_value, at wide-int.cc:346
>   16 | fn main() {
>  | ^
>    0x1d551d5 wi::min_value(unsigned int, signop)
>    ../../gccrs/gcc/wide-int.cc:346
>    0x1146ca5 irange::set_varying(tree_node*)
>    ../../gccrs/gcc/value-range.h:476
>    0x1ce5970 value_range_equiv::set_varying(tree_node*)
>    ../../gccrs/gcc/value-range-equiv.cc:71
>    0x1d3da07 vr_values::set_def_to_varying(tree_node const*)
>    ../../gccrs/gcc/vr-values.c:230
>    0x1d3da70 vr_values::set_defs_to_varying(gimple*)
>    ../../gccrs/gcc/vr-values.c:241
>    0x1c78b2f vrp_prop::visit_stmt(gimple*, edge_def**, tree_node**)
>    ../../gccrs/gcc/tree-vrp.c:4001
>    0x1ad8519 ssa_propagation_engine::simulate_stmt(gimple*)
>    ../../gccrs/gcc/tree-ssa-propagate.c:230
>    0x1ad8a0e ssa_propagation_engine::simulate_block(basic_block_def*)
>    ../../gccrs/gcc/tree-ssa-propagate.c:337
>    0x1ad9f2e ssa_propagation_engine::ssa_propagate()
>    ../../gccrs/gcc/tree-ssa-propagate.c:800
>    0x1c7a0b0 execute_vrp
>    ../../gccrs/gcc/tree-vrp.c:4512
>    0x1c7a3e4 execute
>    ../../gccrs/gcc/tree-vrp.c:4620
>    Please submit a full bug report,
>    ```
>
> The backtrace looks as though the optimizer is looking for min value for
> a default for the return value, but it's a zero precision integer that
> hits the assertion. Note running with -O0, the assertion does not get hit.
>
>
> At the moment, I have left functions with return type unit to keep using
> void_type_node and everywhere else, use this new zero precision integer.
> I am not sure what the best approach is here; I was hoping to solicit
> feedback on what I am doing with the folks here on the mailing list.
>
> Thanks
>
> --Phil
>

Adding in the GCC mailing list for feedback.

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature

Re: GCC Rust Monthly Call - 2nd July 2021

[Philip Herron]

Hi everyone,

Please find the meeting notes for our call over on:
https://github.com/Rust-GCC/Reporting/blob/main/2021-07-02-community-call.md

Thanks again

--Phil

On Mon, 28 Jun 2021 at 12:33, Philip Herron 
wrote:

> Hi everyone,
>
> It is that time again and we will be having our 4th community call over on
> Jitsi for the first Friday of the month.
>
>- Date: 2nd July 2021
>   - UTC: 0900
>   - UK/Ireland UTC+1/BST: 1000
>   - Central European Summer Time UTC+2: 1100
>- Monthly Report: WIP
>- Agenda (WIP): https://hackmd.io/A-b-G90YTNSCEVjiHXz7Qg
>- Jitsi video call: https://meet.jit.si/259057065581073
>
> Here is the latest weekly report for the project:
> https://github.com/Rust-GCC/Reporting/blob/main/2021-06-21-report.org
>
> Please feel free to suggest any topics/questions you wish to be discussed
> here or directly onto the agenda hackmd document.
>
> Thanks
>
> --Phil
>

Re: rust frontend and UTF-8/unicode processing/properties

[Philip Herron]

On 18/07/2021 23:23, Jason Merrill via Gcc-rust wrote:
> On Sun, Jul 18, 2021 at 1:13 PM Ian Lance Taylor via Gcc
> mailto:gcc@gcc.gnu.org>> wrote:
>
> On Sun, Jul 18, 2021 at 6:23 AM Mark Wielaard  > wrote:
> >
> > For the gcc rust frontend I was thinking of importing a couple of
> > gnulib modules to help with UTF-8 processing, conversion to/from
> > unicode codepoints and determining various properties of those
> > codepoints. But it seems gcc doesn't yet have any gnulib modules
> > imported, and maybe other frontends already have helpers to this
> that
> > the gcc rust frontend could reuse.
> >
> > Rust only accepts valid UTF-8 encoded source files, which may or may
> > not start with UTF-8 BOM character. Whitespace is any codepoint with
> > the Pattern_White_Space property. Identifiers can start with any
> > codepoint with the XID_start property plus zero or one
> codepoints with
> > XID_continue property. It isn't required, but highly desirable to
> > detect confusable identifiers according to
> tr39/Confusable_Detection.
> >
> > Other names might be constraint to Alphabetic and/or Number
> categories
> > (Nd, Nl, No), textual types can only contain Unicode Scalar Values
> > (any Unicode codepoint except high-surrogate and low-surrogates),
> > strings in source code can contain unicode escapes (24 bit, up to 6
> > digits codepoints) but are internally stored as UTF-8 (and must not
> > encode any surrogates).
> >
> > Do other gcc frontends handle any of the above already in a way that
> > might be reusable for other frontends?
>
> I don't know that this is particularly helpful, but the Go frontend
> has this kind of code in gcc/go/gofrontend/lex.cc.  E.g.,
> Lex::fetch_char, Lex::advance_one_utf8_char, unicode_space,
> unicode_digits, unicode_letters, Lex::is_unicode_space, etc.  But you
> probably won't be able to use the code directly, and the code in the
> gofrontend directory is also shared with GoLLVM so it can't trivially
> be moved.
>
>
> I believe the UTF-8 handling for the C family front ends is all in
> libcpp; I don't think it's factored in a way to be useful to other
> front ends.
>
> Jason
>
I think it would be ideal to reuse code if possible, it seems like this
project could be an opportunity to at try and make patches to try and
reuse code from other parts of GCC. I bootstrapped the front-end code
from gccgo, which has really helped the project to get going, I would
like to try and give back where I can.

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature

Re: Anything I can contribute?

[Philip Herron]

Hi Kaisheng,

There are plenty of places to get started on the Rust Front-end for
GCC if you are interested?

- https://github.com/Rust-GCC/gccrs
- https://github.com/Rust-GCC/gccrs/blob/master/CONTRIBUTING.md
- 
https://github.com/Rust-GCC/gccrs/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-pr

We keep a list of good first pr's which is the best place to start.
Hope this helps.

--Phil

On Sat, 13 Nov 2021 at 08:36, Deng Kaisheng  wrote:
>
> Hi,
>
> My name is Deng Kaisheng, a graduate student in National University of 
> Sinapore (NUS) now major in computer science. I've read the introduction of 
> your organization and I'm quite interested in what you're doing.
>
> I want to do something and contribute to the community, and I wonder if there 
> is something I can do. I major in computer science since undergraduate with a 
> solid foundation in CS, and I'm also confident in my fast-learning skills. I 
> have programming skills in C++, Python, Java, Objective-C, etc., and database 
> skills in MySQL and Cassandra.
>
> I wonder if your organization is going to take part in the GSoC 2022, if 
> possible, I would like to contribute to your project in GSOC 2022.
>
> I am looking forward to your reply!
>
> Best regards,
>
> Kaisheng

qual_union_type help

[Philip Herron]

Hi everyone

I am seeking some help on using the QUAL_UNION_TYPE it seems ideally
placed to be used for enums in Rust. My initial implementation was
achieved by simply using a union such as:

union my_enum {
  variant_a { enum discriminant; ...data } ;
  variant_b { enum discriminant; ...data} ;
}

Having each variant contain an enum for the discriminant meant that
dataless handling variants were quite simple. Upon trying to use the
QUAL_UNION_TYPE this all seems reasonably trivial but I can't figure
out what to set the DECL_QUALIFIER to be, initially from reading the
documentation on https://gcc.gnu.org/onlinedocs/gccint/Types.html it
seemed that it wants a slightly different layout by using a
placeholder_expr to reference an outer discriminant field such that
the layout becomes:

struct my_enum {
  enum discriminant;
  union variants {
variant_a { data };
variant_b { data };
  }
}

So I have been creating my DECL_QUALIFIER as follows:

```
tree field_offset = NULL_TREE;
tree place_holder = build0 (PLACEHOLDER_EXPR, sizetype);
tree place_holder_expr
  = build3 (COMPONENT_REF, TREE_TYPE (qual_field),
place_holder, qual_field, field_offset);

DECL_QUALIFIER (field)
= build2 (EQ_EXPR, boolean_type_node,
place_holder_expr, discrim);
```

So this seems to generate some interesting code and then finally hit
an ICE inside:

Breakpoint 5, gimplify_expr (expr_p=0x76ff1f48,
pre_p=0x7fffd2d8, post_p=0x7fffbb58, gimple_test_f=0x15aa98f
, fallback=3) at
../../gccrs/gcc/gimplify.cc:15755
15755 gcc_unreachable ();
(gdb) call debug_tree(*expr_p)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7700a000 precision:64 min  max >
   >

This makes sense this we can't gimplify a placeholder expression. So
this seems that when i make a constructor for the QUAL_UNION_TYPE i
must iterate the fields and replace the placeholder_expr to have a
reference to the discriminant via another COMPONENT_REF. Though does
this mean for the constructor i will need to create a temporary to
hold onto it to create another component_ref?

Or am I doing this completely wrong? I haven't had much success in
following the QUAL_UNION_TYPE code in the Ada front-end, but any
pointers would be greatly appreciated.

Thanks.

--Phil

Re: qual_union_type help

[Philip Herron]

Hi Eric,

That makes sense during construction we also know what the value of
the discriminant is. What does the Ada front-end replace the
placeholder_exprs with? Can it simply be the value of the discriminant
at constructor? I haven't tried that.

Thanks

--Phil

On Wed, 23 Feb 2022 at 17:33, Eric Botcazou  wrote:
>
> > This makes sense this we can't gimplify a placeholder expression. So
> > this seems that when i make a constructor for the QUAL_UNION_TYPE i
> > must iterate the fields and replace the placeholder_expr to have a
> > reference to the discriminant via another COMPONENT_REF. Though does
> > this mean for the constructor i will need to create a temporary to
> > hold onto it to create another component_ref?
>
> The Ada compiler gets rid of all PLACEHOLDER_EXPRs in CONSTRUCTORs because the
> subtype of these CONSTRUCTORs is always constrained in Ada parlance, i.e. you
> know the value of the discriminant since it is assigned in the CONSTRUCTOR, so
> the gimplifier is indeed presumably not wired to eliminate them on its own.
>
> --
> Eric Botcazou
>
>

Rust front-end

[Philip Herron]

Hi everyone,

Since November 2020, I've worked full-time on the Rust front-end for
GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
am writing to this mailing list to seek feedback from the collective
experience here early to plan a path for upstreaming the front-end
into GCC.

1. What is the actual process of merging a prominent feature like this upstream
  - How do we review this?
  - Do we create a "mega-commit" patch
  - How long should we expect this review process to take
  - Is there anything we can do to make this easier?

2. What sort of quality does the GCC community expect?
  - I think it is essential that we can compile valid test cases from
a testsuite and real projects before merging.
  - It seems reasonable that our error handling may not be 100% but be
expected to improve over time
  - Upon merging, can features like Rust be marked as experimental

3. How do GCC releases work?
  - If you miss a window can we still merge code into the front-end?
  - Can we merge without a borrow checker and backport this in the future?

4. What about the possibility of merging sooner rather than later,
which would help the project gain interest through the increased
visibility of it as part of the GCC family.
  - Does this still allow for development churn, or will it cause friction?

5. Does anyone have prior experience or advice they could give us?

For some context, my current project plan brings us to November 2022
where we (unexpected events permitting) should be able to support
valid Rust code targeting Rustc version ~1.40 and reuse libcore,
liballoc and libstd. This date does not account for the borrow checker
feature and the proc macro crate, which we have a plan to implement,
but this will be a further six-month project.

Regarding patch management, we currently do our development on GitHub:
https://github.com/Rust-GCC/gccrs; this means we can integrate our
issue tracking with the official Rust project by linking back to the
official Rust project's RFC issues, for example. The downside is that
when someone uses our compiler and hits an ICE, they will be directed
to the GCC Bugzilla, which is correct but can lead to a mismatch in
issue tracking. Nevertheless, I think it's essential to have the
GitHub link here to integrate with the broader Rust community. I
believe we can triage Rust issues on the Bugzilla and raise associated
ones on Github to manage this.

>From my perspective as the lead on this front-end, we are currently
under heavy development, so this means a fair amount of code churn
still, and I don't see this changing until we can successfully compile
the libcore crate later this year. Although I would love to see us
merged into GCC 13, I want to make sure this project is a success for
everyone, and this might mean pushing back to the next release window
to make sure this is manageable to produce a quality front-end to sit
alongside the others.

I wish to thank you those in the GCC developer community, who have
inspired me and helped me navigate my journey to this point in time.

- Thomas Schwinge
- Mark Wielaard
- Tom Tromey
- Ian Lance Taylor
- David Edelsohn
- David Malcolm
- Martin Jambor

Thanks

–Phil

Re: Rust front-end

[Philip Herron]

Hi Richard

Thanks for your detailed response, I took some time to figure this out
myself to give a decent response. It seems like we should keep the end
of the year as our goal to aim for but in the meantime see if we can
split patches which affect GCC over the next month or so. We have no
changes to the GCC gimple/generic IRs. Usually, when I hit something
inside the GCC middle-end, the front-end is doing something wrong,
which has helped keep me on a good path. Other than that we have
changes to:

1. Grabbing target info using the TARGET_HOOKS interfaces in gcc/config.
2. Tweaks to selftest which was already merged last year by Arthur Cohen
3. We have some minor issues with lang.opt in the latest merge from
upstream which Thomas Schwinge is working on, but I believe we can
work around this if we want
4. Our compiler driver needs some cleanup which we can do in the short
term to get it reviewed
5. We need to make some build changes to incorporate libcore being
built by gccrs which is still WIP.

As for the compile link cycle, we mostly reuse the model from the GO
front-end. In Rust the "crate" is a compilation unit, which means if
you have a project with multiple files, you point gccrs at a single
src/source.rs, the main entry point for a library (usually lib.rs).
Keywords such as "mod foo", trigger the expansion of a relative path
of foo.rs like a C++ included inside a namespace. All source files are
then included inside this single compilation unit. When the
compilation is successful, we reuse code from the Go front-end to put
custom front-end metadata into a section ".rust_export". At this
point, all source files are compiled into a single object file, which
can be compiled into an archive or shared library as required. To link
against this, it again follows similar to Go front-end, whereby the
source.rs has a declaration such as "extern crate foo"; the search
code will look for foo.o or libfoo.a (I haven't tested against shared
libraries yet) and grab the metadata out of it and parse it in the
front-end for all the necessary information such as types, public
functions and generics, etc., so we can compile any imports correctly
and emit the correct mangled symbols for linking.

Given we are still working on this I think we can try to line up all
the other GCC relating pieces for review over the summer, do we send
this as usual to gcc-patches?

Again thanks to everyone for helping me navigate this and answering my
questions.

--Phil

On Tue, 28 Jun 2022 at 08:30, Richard Biener  wrote:
>
> On Mon, Jun 27, 2022 at 4:52 PM Philip Herron
>  wrote:
> >
> > Hi everyone,
> >
> > Since November 2020, I've worked full-time on the Rust front-end for
> > GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
> > am writing to this mailing list to seek feedback from the collective
> > experience here early to plan a path for upstreaming the front-end
> > into GCC.
> >
> > 1. What is the actual process of merging a prominent feature like this 
> > upstream
> >   - How do we review this?
> >   - Do we create a "mega-commit" patch
> >   - How long should we expect this review process to take
> >   - Is there anything we can do to make this easier?
>
> Usually a new frontend is first proposed for merge and generally approved
> by the steering committee (which should also sort out legal issues).
>
> For the actual review process it's best to consult previous frontend
> merges - the most recent merged frontend was the D frontend and the
> modula2 frontend is in the process of being reviewed.
>
> To be able to focus on the possibly controversical pieces separating
> out changes to the generic GCC code base (such as driver or
> even middle-end) should be separated out.
>
> It would also be helpful to provide an overview of how a rust
> compile + link cycle works through the pieces in GCC (see the
> modula-2 case where that involved creating stub C++ code,
> compiling and linking that and how this is now done much
> more straight-forward).
>
> > 2. What sort of quality does the GCC community expect?
> >   - I think it is essential that we can compile valid test cases from
> > a testsuite and real projects before merging.
> >   - It seems reasonable that our error handling may not be 100% but be
> > expected to improve over time
> >   - Upon merging, can features like Rust be marked as experimental
>
> Rust can be marked as experimental, sure.  It would be not enabled
> to be built by default (and you can have a whitelist of supported targets).
> The most important part would be that the build works when enabled
> and that most of the existing testsuite passes so it can be used to
> regression test middle-end changes.
>
> If it is no

Re: Rust front-end

[Philip Herron]

Hi everyone,

As the cut-off for merging is coming up in November, quite a few of
our patches have not been reviewed yet.

There are a few main issues that have been raised so far, and we are
fixing those at the moment in preparation for version 3 of the
patches. Is there anything else we can do to make reviewing the rest
of the patches easier?

Thanks

--Phil

On Mon, 11 Jul 2022 at 16:02, David Edelsohn  wrote:
>
> On Mon, Jun 27, 2022 at 10:52 AM Philip Herron
>  wrote:
> >
> > Hi everyone,
> >
> > Since November 2020, I've worked full-time on the Rust front-end for
> > GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
> > am writing to this mailing list to seek feedback from the collective
> > experience here early to plan a path for upstreaming the front-end
> > into GCC.
> >
> > 1. What is the actual process of merging a prominent feature like this 
> > upstream
> >   - How do we review this?
> >   - Do we create a "mega-commit" patch
> >   - How long should we expect this review process to take
> >   - Is there anything we can do to make this easier?
> >
> > 2. What sort of quality does the GCC community expect?
> >   - I think it is essential that we can compile valid test cases from
> > a testsuite and real projects before merging.
> >   - It seems reasonable that our error handling may not be 100% but be
> > expected to improve over time
> >   - Upon merging, can features like Rust be marked as experimental
> >
> > 3. How do GCC releases work?
> >   - If you miss a window can we still merge code into the front-end?
> >   - Can we merge without a borrow checker and backport this in the future?
> >
> > 4. What about the possibility of merging sooner rather than later,
> > which would help the project gain interest through the increased
> > visibility of it as part of the GCC family.
> >   - Does this still allow for development churn, or will it cause friction?
> >
> > 5. Does anyone have prior experience or advice they could give us?
> >
> > For some context, my current project plan brings us to November 2022
> > where we (unexpected events permitting) should be able to support
> > valid Rust code targeting Rustc version ~1.40 and reuse libcore,
> > liballoc and libstd. This date does not account for the borrow checker
> > feature and the proc macro crate, which we have a plan to implement,
> > but this will be a further six-month project.
> >
> > Regarding patch management, we currently do our development on GitHub:
> > https://github.com/Rust-GCC/gccrs; this means we can integrate our
> > issue tracking with the official Rust project by linking back to the
> > official Rust project's RFC issues, for example. The downside is that
> > when someone uses our compiler and hits an ICE, they will be directed
> > to the GCC Bugzilla, which is correct but can lead to a mismatch in
> > issue tracking. Nevertheless, I think it's essential to have the
> > GitHub link here to integrate with the broader Rust community. I
> > believe we can triage Rust issues on the Bugzilla and raise associated
> > ones on Github to manage this.
> >
> > From my perspective as the lead on this front-end, we are currently
> > under heavy development, so this means a fair amount of code churn
> > still, and I don't see this changing until we can successfully compile
> > the libcore crate later this year. Although I would love to see us
> > merged into GCC 13, I want to make sure this project is a success for
> > everyone, and this might mean pushing back to the next release window
> > to make sure this is manageable to produce a quality front-end to sit
> > alongside the others.
> >
> > I wish to thank you those in the GCC developer community, who have
> > inspired me and helped me navigate my journey to this point in time.
> >
> > - Thomas Schwinge
> > - Mark Wielaard
> > - Tom Tromey
> > - Ian Lance Taylor
> > - David Edelsohn
> > - David Malcolm
> > - Martin Jambor
>
> Congratulations! The GCC Steering Committee has voted to accept the
> contribution of the Rust Frontend (aka GCC Rust) to GCC.  Please work
> with the GCC Global Reviewers and GCC Release Managers for technical
> review and technical approval of the patches.  We look forward to
> including a preliminary, beta version of GCC Rust in GCC 13 as a
> non-default language.
>
> Thanks, David

Re: Rust front-end

[Philip Herron]

Hi David

We made a table to try and track this a bit better:

| Patch   |
Reviewed | Accepted |
|-+--+--|
| 0001-Use-DW_ATE_UTF-for-the-Rust-char-type.patch| x
  | x|
| 0002-gccrs-Add-nessecary-hooks-for-a-Rust-front-end-tests.patch | x
  | x|
| 0003-gccrs-Add-Debug-info-testsuite.patch   |
  |  |
| 0004-gccrs-Add-link-cases-testsuite.patch   |
  |  |
| 0005-gccrs-Add-general-compilation-test-cases.patch |
  |  |
| 0006-gccrs-Add-execution-test-cases.patch   |
  |  |
| 0007-gccrs-Add-gcc-check-target-check-rust.patch| x
  |  |
| 0008-gccrs-Add-the-Rust-front-end-AST-data-structures.patch |
  |  |
| 0009-gccrs-Add-Lexer-for-Rust-front-end.patch   | x
  |  |
| 0010-gccrs-Add-Parser-for-Rust-front-end.patch  |
  |  |
| 0011-gccrs-Add-expansion-pass-for-the-Rust-front-end.patch  |
  |  |
| 0012-gccrs-Add-name-resolution-pass-to-the-Rust-front-end.patch |
  |  |
| 0013-gccrs-Add-second-intermedite-representation-called-H.patch |
  |  |
| 0014-gccrs-Add-AST-to-HIR-lowering-pass.patch   |
  |  |
| 0015-gccrs-Add-wrapper-for-make_unique.patch|
  |  |
| 0016-gccrs-Add-port-of-FNV-hash-used-during-legacy-symbol.patch |
  |  |
| 0017-gccrs-Add-Rust-ABI-enum-helpers.patch  |
  |  |
| 0018-gccrs-Add-Base62-implementation.patch  |
  |  |
| 0019-gccrs-Add-implementation-of-Optional.patch |
  |  |
| 0020-gccrs-Add-attributes-checker.patch |
  |  |
| 0021-gccrs-Add-helpers-mappings-canonical-path-and-lang-i.patch |
  |  |
| 0022-gccrs-Add-type-resolution-and-trait-solving-pass.patch |
  |  |
| 0023-gccrs-Add-unsafe-checks-for-Rust.patch |
  |  |
| 0024-gccrs-Add-const-checker.patch  |
  |  |
| 0025-gccrs-Add-privacy-checks.patch |
  |  |
| 0026-gccrs-Add-dead-code-scan-on-HIR.patch  |
  |  |
| 0027-gccrs-Add-unused-variable-scan.patch   |
  |  |
| 0028-gccrs-Add-metadata-ouptput-pass.patch  |
  |  |
| 0029-gccrs-HIR-to-GCC-GENERIC-lowering.patch|
  |  |
| 0030-gccrs-These-are-wrappers-ported-from-reusing-gccgo.patch   |
  |  |
| 0031-gccrs-Add-GCC-Rust-front-end-Make-lang.in.patch| x
  |  |
| 0032-gccrs-Add-config-lang.in.patch | x
  | x|
| 0033-gccrs-add-lang-spec.h.patch|
  |  |
| 0034-gccrs-add-lang.opt.patch   | x
  |  |
| 0035-gccrs-add-compiler-driver.patch|
  |  |
| 0036-gccrs-compiler-proper-interface-kicks-off-the-pipeli.patch |
  |  |
| 0037-gccrs-Add-README-CONTRIBUTING-and-compiler-logo.patch  |
  |  |

I think the formatting from org-mode didn't come through 100%, but it
looks readable enough. The patches which are reviewed but not accepted
have issues which we have fixed locally in preparation for sending
version 3 of the patches. I also found using this link made it much
easier to see which patches have had reviews and which have not:

https://inbox.sourceware.org/gcc-patches/20220824115956.737931-9-philip.her...@embecosm.com/T/#rbff0bb3df2780fecd9ee3d2baa864d9140d24b54

You can easily see the thread of patches and those which have
responses and which have not.

Thanks

--Phil

On Tue, 4 Oct 2022 at 13:43, David Malcolm  wrote:
>
> On Tue, 2022-10-04 at 13:29 +0100, Philip Herron wrote:
> > Hi everyone,
> >
> > As the cut-off for merging is coming up in November, quite a few of
> > our patches have not been reviewed yet.
> >
> > There are a few main issues that have been raised so far, and we are
> > fixing those at the moment in preparation for version 3 of the
> > patches. Is there anything else we can do to make reviewing the rest
> > of the patches easier?
>
> Do you have a list of which patches need reviewing?
> e.g. perhaps a page showing:
> - which patches are waiting for a reviewer, as opposed to
> - which patches are already approved
> - which patches have issues identified in review
>   - ...where no-one is yet working on addressing them
>   - ...where someone is working on addressing them
>

Re: Rust front-end

[Philip Herron]

Hi Jakub,

Thanks for this, as I mentioned in my response to David we have made a
table and use this link to try and see what's going on
https://inbox.sourceware.org/gcc-patches/20220824115956.737931-9-philip.her...@embecosm.com/T/#rbff0bb3df2780fecd9ee3d2baa864d9140d24b54

Do you think I should send a PING email to each patch which we are
waiting on review for?

Thanks

--Phil

On Tue, 4 Oct 2022 at 14:04, Jakub Jelinek  wrote:
>
> On Tue, Oct 04, 2022 at 08:42:58AM -0400, David Malcolm via Gcc wrote:
> > On Tue, 2022-10-04 at 13:29 +0100, Philip Herron wrote:
> > > Hi everyone,
> > >
> > > As the cut-off for merging is coming up in November, quite a few of
> > > our patches have not been reviewed yet.
> > >
> > > There are a few main issues that have been raised so far, and we are
> > > fixing those at the moment in preparation for version 3 of the
> > > patches. Is there anything else we can do to make reviewing the rest
> > > of the patches easier?
> >
> > Do you have a list of which patches need reviewing?
> > e.g. perhaps a page showing:
> > - which patches are waiting for a reviewer, as opposed to
> > - which patches are already approved
> > - which patches have issues identified in review
> >   - ...where no-one is yet working on addressing them
> >   - ...where someone is working on addressing them
> > etc
> >
> > to make it clearer what the next action is for each patch, and who is
> > meant to be taking it.
> >
> > (within Red Hat, we used to call this "who has the ball?")
>
> Yeah, our policy in https://gcc.gnu.org/contribute.html states that
> "Pinging patches, Getting patches applied
>
> If you do not receive a response to a patch that you have submitted within
> two weeks or so, it may be a good idea to chase it by sending a follow-up
> e-mail to the same list(s).  Patches can occasionally fall through the
> cracks.  Please be sure to include a brief summary of the patch and the URL
> of the entry in the mailing list archive of the original submission."
>
> If some patches have been already reviewed, others partly, others in the
> works and others need review, sending a mail with those details
> so that it is easy to find out what is still pending is appreciated even
> more.
>
> Jakub
>

Proposal: New Layer Maybe

[Philip Herron]

Hey all

I've been quietly spending the last years working on my
python-front-end in the background. And over the last few years always
been thinking that gcc could be simpler for front-end-developers. I am
just going to post up this simple high-level proposal just to gauge
the opinion of the gods that are GCC developers as i don't really want
to start working on something in a certain way in vain.

1 - How about an _optional_ library for front-ends, and some
generators: The library say libgcchelper could be optionally used in
the front-end code so developers could have a simpler higher-level api
(something akin to Kaleidoscope from llvm
http://llvm.org/docs/tutorial/LangImpl3.html) to generate code ready
for GCC. So over all it will be a high level IL which gets lowered to
GENERIC then we call gcc middle-end as normal. It could also provide
some generators to build a config.lang/lang.specs and your compiler
driver and the necessary boiler-plate code like langhooks. This could
work well so existing front-ends can use their code as usual and new
front-ends could use the generates to get the boiler plate code done
for them and then able to use GENERIC if they wish. But comes with the
cost of extra code to maintain which probably won't get picked up. in
the existing front-ends.

---

2- Another way to go is, implementing these generators and also adding
more code to the existing GENERIC api to make things simpler and maybe
some more error handling to GENERIC. By make things simpler i would
mean making new constructs like:

Function *F = Function::Create(FT, Function::ExternalLinkage, Name, TheModule);
...
BasicBlock *BB = BasicBlock::Create(getGlobalContext(), "entry", TheFunction);

Instead of the mountain of different ways you can make functions at
the moment. I think what makes GENERIC is so confusing is BIND_EXPR's
to implement blocks of code. As well as SUB/SUPER context's etc. Feels
very abstract talking about code in this way without knowing the
internals very well. Having a builder class like llvm to handle a lot
of the complicated fiddly trickery pokery to get things working.

But this is difficult because the tree api code is pretty much black
magic to me most of the time. But in the end probably the ideal
solution. I think with the move to c++ is probably going to get much
simpler with time.

---

This probably looks more like a brain dump but i think i want to work
on making something better in gcc and i think i can do something here
some opinions or discussion would be cool.

--Phil

Re: libgccjit.so: an embeddable JIT-compilation library based on GCC

[Philip Herron]

This is a great project dying to start helping out there!

--Phil

On 13 October 2013 21:34, Paulo J. Matos  wrote:
> On 10/10/13 20:52, David Malcolm wrote:
>>
>> I've added detailed information on the project to the wiki as:
>>http://gcc.gnu.org/wiki/JIT
>> and added a link to that page to the front page's "Current Projects"
>> section.
>>
>>
>
> For reasons unknown to me, check-parallel-jit has to be issues inside
> build/jit/gcc, contrary to was is said in the wiki.
>
> 302 passes here.
>
> Cheers,
>
>
> --
> PMatos
>

Rust front-end to GCC

[Philip Herron]

Hey all

Some of you may have noticed the gccrs branch on the git mirror. Since
PyCon IE 2013 i gave a talk on my Python Front-end pet project and
heard about rust by a few people and i never really looked at it
before until then but i've kind of been hooked since.

So to learn the language i've been writing this front-end to GCC. Only
really a a month or  so on and off work in between work. Currently it
compiles alot of rust already in fairly little effort on my side GCC
is doing loads of the heavy lifting.

Currently it compiles most of the basic stuff such as a struct an impl
block while loop, functions expressions calling methods passing
arguments etc. Currently focusing on getting the typing working
correctly to support & and ~ and look at how templates might work as
well as need to implement break and return.

There is still a lot of work but i would really like to share it and
see what people think. Personally i think rust will target GCC very
well and be a good addition (if / when it works). I really want to try
and give back to this community who have been very good to me in
learning over the last few years with GSOC.

To get a jist of what i am compiling in my tests are something like:

fn fib1 (n:int) -> int {
if (n <= 1) { 1 }
else { n * fib1 (n - 1) }
}

fn fib2 (n:int) -> int {
let mut i = 1;
let mut result = 1;
while (i <= n) {
result = result * i;
i = i + 1;
}
result
}

fn main () {
fib1 (10);
fib2 (10);
}

Or

struct mytype {
x : int
}

impl mytype {
fn test (self) -> int {
println ("yyoyoyo");
test2 (1)
}
}

fn main () {
let x = mytype { x : 1 };
let z = x.x;
let y = x.test ();
let a = test2 (y);
}

fn test2 (x : int) -> int {
let z = x;
1 + z
}

Theses are both pretty abstract test cases but were the ones i just
made work a while ago. Lots more work to do on it but i feel these 2
test cases working is kind of a mile stone for me.

I will start a wiki page on the project and the code i work on is at
http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gccrs and i
have it on github first mostly for travis CI and so i can do a bunch
of commits and rebase etc http://github.com/redbrain/gccrs

Thanks

--Phil

Re: [GSoC] gccrs Unicode support

[Philip Herron via Gcc]

Hi Raiki

Excellent work on getting up to speed on the rust front-end. From my
perspective I am interested to see what the wider GCC community thinks
about using https://www.gnu.org/software/libunistring/ library within GCC
instead of rolling our own, this means it will be another dependency on GCC.

The other option is there is already code in the other front-ends to do
this so in the worst case it should be possible to extract something out of
them and possibly make this a shared piece of functionality which we can
mentor you through.

Thanks

--Phil

On Mon, 13 Mar 2023 at 16:19, Raiki Tamura via Gcc  wrote:

> Hello,
>
> My name is Raiki Tamura, an undergraduate student at Kyoto University in
> Japan and I want to work on Unicode support in gccrs this year.
> I have already written my proposal (linked below) and shared it with the
> gccrs team in Zulip.
> In the project, I am planning to use the GNU unistring library to handle
> Unicode characters and the GNU IDN library to normalize identifiers.
> According to my potential mentor, it would provide Unicode libraries for
> all frontends in GCC. If there are concerns or feedback about this, please
> tell me about it.
> Thank you.
>
> Link to my proposal:
>
> https://docs.google.com/document/d/1MgsbJMF-p-ndgrX2iKeWDR5KPSWw9Z7onsHIiZ2pPKs/edit?usp=sharing
>
> Raiki Tamura
>