Interest in Contributing Diagnostic System to GCC
Dear GCC Developers, I'm in the process of writing my own C compiler for educational purposes. To this end, I have decided to integrate into my compiler my own C++ port ( https://github.com/johnythecarrot/mjolnir ) of the Rust crate Ariadne ( https://github.com/zesterer/ariadne ) which provides nice, fancy and readable diagnostics for use in compilers and the like. See the first link for an idea of how my library outputs diagnostics. I had the idea of perhaps contributing this diagnostics system to GCC in one way or another, under a flag perhaps, but considered it might be an unwelcome addition. I was told that there's no harm in raising it with the GCC developers. This message serves as a gauge of interest from the GCC developers for something of this kind. I am aware the current format of my diagnostics do not comply with the GNU Standards, and I'd therefore also like to politely ask for input on your suggestions on making it comply while retaining its cleanliness. I am the sole developer of Mjolnir and can therefore relicense it as necessary. Mjolnir still has a couple of issues to iron out and features to implement, such as multi-line span displaying. Thanks, Tuur Martens
Re: Patch held up in gcc-patches due to size
On Feb 02 2025, Thomas Koenig wrote: > I sent https://gcc.gnu.org/pipermail/fortran/2025-February/061670.html > to gcc-patches also, as normal, but got back an e-mail that it > was too large. and that a moderator would look at it. The mail has been accepted anyway: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/674931.html -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Patch held up in gcc-patches due to size
Hi Thomas, On Sun, Feb 02, 2025 at 07:09:14PM +0100, Thomas Koenig via Gcc wrote: > I sent https://gcc.gnu.org/pipermail/fortran/2025-February/061670.html > to gcc-patches also, as normal, but got back an e-mail that it > was too large. and that a moderator would look at it. I think that was done, since the message is here: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/674931.html I also have in in my local gcc-patches inbox. Didn't you receive it yourself through the list? > Maybe the limits can be increased a bit, sometimes patches can > be quite large, especially if they contain large test cases > or a large number of generated files. The problem is, as always spam... Do you find the current limit (400K) restricts you often from fast posting to the gcc-patches list? > (Does anybody actually look at the messages, as promised in the e-mail?= I think it is done multiple times each day. The current moderators are Jeff and Marc, with help from the Sourceware volunteers monitoring postmaster. I know some of these people, including Marc and myself were at Fosdem this weekend. How long did you have to wait for your message to get to the list? Cheers, Mark
Re: Interest in Contributing Diagnostic System to GCC
Hi Tuur, On Mon, Feb 03, 2025 at 09:46:37AM +, JohnyTheCarrot via Gcc wrote: > I'm in the process of writing my own C compiler for educational purposes. > To this end, I have decided to integrate into my compiler my own C++ > port ( https://github.com/johnythecarrot/mjolnir ) of the Rust crate > Ariadne ( https://github.com/zesterer/ariadne ) which provides nice, > fancy and readable diagnostics for use in compilers and the > like. See the first link for an idea of how my library outputs > diagnostics. Looks nice. Note that the current diagnostics library GCC uses is described here: https://gcc.gnu.org/wiki/libgdiagnostics https://gcc.gnu.org/cgit/gcc/tree/gcc/libgdiagnostics.h https://gcc.gnu.org/onlinedocs/libgdiagnostics/ It already does have some "fancy reporting" features. You might want to look at how these code bases could be combined. Cheers, Mark
Re: Patch held up in gcc-patches due to size
February 3, 2025 at 11:02 AM, "Mark Wielaard" mailto:m...@klomp.org?to=%22Mark%20Wielaard%22%20%3Cmark%40klomp.org%3E > wrote: > > (Does anybody actually look at the messages, as promised in the e-mail?= > > > I think it is done multiple times each day. The current moderators are > Jeff and Marc, with help from the Sourceware volunteers monitoring > postmaster. I know some of these people, including Marc and myself > were at Fosdem this weekend. How long did you have to wait for your > message to get to the list? Hello, I usually look at the queue a few times a day (working day)... So at least in my case, I may not be very active during the weekends (even less so this weekend)... As for unlocking too-big patches, I happen to accept the ones that are "close" to the limit. I think I asked last year about the big translation patches and someone (Jospeh IIRC) told me that it was ok to accept them. Should I be more strict and reject anything above the limit? Marc PS: would be nice if git-send-email could take care of this...
Interest in Contributing Diagnostic System to GCC
> > > I'm in the process of writing my own C compiler for educational purposes. Then look also into https://frama-c.com/ and https://github.com/bstarynk/bismon and https://nwcc.sourceforge.net/ and https://bellard.org/tcc/ > To this end, I have decided to integrate into my compiler my own C++ port ( > https://github.com/johnythecarrot/mjolnir ) of the Rust crate Ariadne ( > https://github.com/zesterer/ariadne ) which provides nice, fancy and readable > diagnostics for use in compilers and the like. See the first link for an idea > of how my library outputs diagnostics. > > I had the idea of perhaps contributing this diagnostics system to GCC in one > way or another, under a flag perhaps, but considered it might be an unwelcome > addition. I was told that there's no harm in raising it with the GCC > developers. > > This message serves as a gauge of interest from the GCC developers for > something of this kind. I am aware the current format of my diagnostics do not > comply with the GNU Standards, and I'd therefore also like to politely ask for > input on your suggestions on making it comply while retaining its cleanliness. > > I am the sole developer of Mjolnir and can therefore relicense it as > necessary. Mjolnir still has a couple of issues to iron out and features to > implement, such as multi-line span displaying. As far as I understand, GCC code needs to be GPL licensed with a copyright assignment contract to the FSF. (See https://gcc.gnu.org/legacy-ml/gcc/2006-12/msg8.html and https://arxiv.org/abs/1109.0779 ) regarding your fancy diagnostic system, consider working at the GIMPLE level and implementing it (at first) as an open source GCC plugin. https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html https://gcc.gnu.org/onlinedocs/gccint/Plugins.html Be aware that GCC extensions (e.g. your open source plugin) will use GCC functions for diagnostics. By working on GIMPLE representation your code analyzer would be usable on most of the languages having a GCC frontend. You probably want to extend the existing GCC static analysis infrastructure: https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html in relation with GCC link-time optimizations abilities. Regarding specifically C++ and its template machinery, you probably would have issues in analyzing C++ template code. As far as I understand this is an undecidable problem, so needs years of research (and could give you some PhD). A naïve insight would be, for improving C++ template diagnostics, to try to instanciate C++ template code (e.g. Boost libraries) with some guessed types. I have no idea of how to achieve this. Do you want to use machine learning techniques to improve your diagnostic tool mjolnir? Perhaps some code from https://github.com/RefPerSys/RefPerSys/ (a GPL licensed inference engine project) could be useful for your tool? Regards from near Paris in France -- Basile STARYNKEVITCH 8 rue de la Faïencerie 92340 Bourg-la-Reine, France http://starynkevitch.net/Basile & https://github.com/bstarynk
Re: Interest in Contributing Diagnostic System to GCC
Dear Basile and other GCC friends, I may have not been clear about the purpose of my code. It does not analyze code, it merely formats / constructs diagnostics for printing to a terminal. I am looking to perhaps contribute the format or presentation of this tool to GCC as an option, utilizing the existing diagnostics and code analysis already built into GCC, and merely presenting it in a different manner. Thank you, Tuur Martens On Monday, February 3rd, 2025 at 11:48 AM, Basile Starynkevitch wrote: > Then look also into https://frama-c.com/ and > https://github.com/bstarynk/bismon > and https://nwcc.sourceforge.net/ and https://bellard.org/tcc/ > > > As far as I understand, GCC code needs to be GPL licensed with a copyright > assignment contract to the FSF. (See > https://gcc.gnu.org/legacy-ml/gcc/2006-12/msg8.html > and https://arxiv.org/abs/1109.0779 ) > > regarding your fancy diagnostic system, consider working at the GIMPLE level > and > implementing it (at first) as an open source GCC plugin. > https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html > https://gcc.gnu.org/onlinedocs/gccint/Plugins.html > > Be aware that GCC extensions (e.g. your open source plugin) will use GCC > functions for diagnostics. > > By working on GIMPLE representation your code analyzer would be usable on most > of the languages having a GCC frontend. You probably want to extend the > existing > GCC static analysis infrastructure: > https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html > in relation with GCC link-time optimizations abilities. > > Regarding specifically C++ and its template machinery, you probably would have > issues in analyzing C++ template code. As far as I understand this is an > undecidable problem, so needs years of research (and could give you some PhD). > A naïve insight would be, for improving C++ template diagnostics, to try to > instanciate C++ template code (e.g. Boost libraries) with some guessed types. > I > have no idea of how to achieve this. > > Do you want to use machine learning techniques to improve your diagnostic tool > mjolnir? Perhaps some code from https://github.com/RefPerSys/RefPerSys/ (a GPL > licensed inference engine project) could be useful for your tool? > > Regards from near Paris in France > -- > Basile STARYNKEVITCH bas...@starynkevitch.net > > 8 rue de la Faïencerie > 92340 Bourg-la-Reine, France > http://starynkevitch.net/Basile & https://github.com/bstarynk
Re: Patch held up in gcc-patches due to size
On Mon, 3 Feb 2025 at 10:27, Marc Poulhiès wrote: > > I usually look at the queue a few times a day (working day)... So at least in > my case, I may not be very active during the weekends (even less so this > weekend)... > As for unlocking too-big patches, I happen to accept the ones that are > "close" to the limit. I think I asked last year about the big translation > patches and someone (Jospeh IIRC) told me that it was ok to accept them. > Should I be more strict and reject anything above the limit? I think if it's a real patch, not spam, then it's OK to accept it. The limit is there partly to stop spam with large PDF/docx/exe attachments that we never want on the lists. The fact that the limits might also make people think twice before sending half a megabyte of text to hundreds of people's inbox is a useful secondary effect IMHO :-) Very, very few people who receive 500kB of generated code or testcases are actually going to review all of that. On the other hand, if patchwork and the automated CI can't handle compressed attachments (can they?) then gzipping things causes other problems.
Re: Patch held up in gcc-patches due to size
On Mon, Feb 03, 2025 at 10:55:10AM +, Jonathan Wakely via Gcc wrote: > On Mon, 3 Feb 2025 at 10:27, Marc Poulhiès wrote: > > > > I usually look at the queue a few times a day (working day)... So at least > > in my case, I may not be very active during the weekends (even less so this > > weekend)... > > As for unlocking too-big patches, I happen to accept the ones that are > > "close" to the limit. I think I asked last year about the big translation > > patches and someone (Jospeh IIRC) told me that it was ok to accept them. > > Should I be more strict and reject anything above the limit? > > I think if it's a real patch, not spam, then it's OK to accept it. The And if the sender has not tried to send it (almost) immediately split up as a patch series or gzipped etc. In that case letting the large patch through would be just waste of bandwidth. Jakub
Re: Interest in Contributing Diagnostic System to GCC
On Mon, 3 Feb 2025 at 10:49, Basile Starynkevitch wrote: > > > > > > > I'm in the process of writing my own C compiler for educational purposes. > > > Then look also into https://frama-c.com/ and > https://github.com/bstarynk/bismon > and https://nwcc.sourceforge.net/ and https://bellard.org/tcc/ > > > To this end, I have decided to integrate into my compiler my own C++ port ( > > https://github.com/johnythecarrot/mjolnir ) of the Rust crate Ariadne ( > > https://github.com/zesterer/ariadne ) which provides nice, fancy and > > readable > > diagnostics for use in compilers and the like. See the first link for an > > idea > > of how my library outputs diagnostics. > > > > I had the idea of perhaps contributing this diagnostics system to GCC in one > > way or another, under a flag perhaps, but considered it might be an > > unwelcome > > addition. I was told that there's no harm in raising it with the GCC > > developers. > > > > This message serves as a gauge of interest from the GCC developers for > > something of this kind. I am aware the current format of my diagnostics do > > not > > comply with the GNU Standards, and I'd therefore also like to politely ask > > for > > input on your suggestions on making it comply while retaining its > > cleanliness. > > > > I am the sole developer of Mjolnir and can therefore relicense it as > > necessary. Mjolnir still has a couple of issues to iron out and features to > > implement, such as multi-line span displaying. > > As far as I understand, GCC code needs to be GPL licensed with a copyright > assignment contract to the FSF. (See > https://gcc.gnu.org/legacy-ml/gcc/2006-12/msg8.html > and https://arxiv.org/abs/1109.0779 ) No, this is incorrect. There's code in GCC under other licenses. It needs to be under a licence that is GPL *compatible*, not necessarily the GPL (e.g. see the zlib, libbacktrace and libsanitizer sub-directories). Third-party libraries do not need to have their copyright assigned to FSF. Even GCC code doesn't need to these days, see https://gcc.gnu.org/contribute.html#legal > regarding your fancy diagnostic system, consider working at the GIMPLE level > and > implementing it (at first) as an open source GCC plugin. > https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html > https://gcc.gnu.org/onlinedocs/gccint/Plugins.html > > Be aware that GCC extensions (e.g. your open source plugin) will use GCC > functions for diagnostics. > > By working on GIMPLE representation your code analyzer would be usable on most > of the languages having a GCC frontend. You probably want to extend the > existing > GCC static analysis infrastructure: > https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html > in relation with GCC link-time optimizations abilities. > > Regarding specifically C++ and its template machinery, you probably would have > issues in analyzing C++ template code. As far as I understand this is an > undecidable problem, so needs years of research (and could give you some PhD). > A naïve insight would be, for improving C++ template diagnostics, to try to > instanciate C++ template code (e.g. Boost libraries) with some guessed types. > I > have no idea of how to achieve this. > > Do you want to use machine learning techniques to improve your diagnostic tool > mjolnir? Perhaps some code from https://github.com/RefPerSys/RefPerSys/ (a GPL > licensed inference engine project) could be useful for your tool? These seems completely irrelevant, it's a library for formatting and displaying diagnostics, not for analyzing code and producing new diagnostics.
Re: Patch held up in gcc-patches due to size
Am 03.02.25 um 11:02 schrieb Mark Wielaard: The problem is, as always spam... Do you find the current limit (400K) restricts you often from fast posting to the gcc-patches list? It happens every now and then, when the patches (as this one) are really big. (Does anybody actually look at the messages, as promised in the e-mail?= I think it is done multiple times each day. The current moderators are Jeff and Marc, with help from the Sourceware volunteers monitoring postmaster. I know some of these people, including Marc and myself were at Fosdem this weekend. How long did you have to wait for your message to get to the list? Fortran patches are somewhat special because they are reviewed on the fort...@gcc.gnu.org mailing list. Putting gcc-patches on there as well is done to give people who are not subscribed to the fortran list a chance to look at them, as well. I do not subscribe to gcc-patches, and I strongly suspect that most Fortran maintainers do not either. The message in question made it through to fortran@, and I never had problems there. Maybe it would be possible to let them through automatically to gcc-patches if they are accepted to fortran? Best regards Thomas
Re: Patch held up in gcc-patches due to size
On Mon, 3 Feb 2025 at 11:06, Thomas Koenig via Gcc wrote: > > Am 03.02.25 um 11:02 schrieb Mark Wielaard: > > The problem is, as always spam... Do you find the current limit (400K) > > restricts you often from fast posting to the gcc-patches list? > > It happens every now and then, when the patches (as this one) are really > big. > > >> (Does anybody actually look at the messages, as promised in the e-mail?= > > I think it is done multiple times each day. The current moderators are > > Jeff and Marc, with help from the Sourceware volunteers monitoring > > postmaster. I know some of these people, including Marc and myself > > were at Fosdem this weekend. How long did you have to wait for your > > message to get to the list? > > Fortran patches are somewhat special because they are reviewed on the > fort...@gcc.gnu.org mailing list. Putting gcc-patches on there > as well is done to give people who are not subscribed to the fortran > list a chance to look at them, as well. > > I do not subscribe to gcc-patches, and I strongly suspect that most > Fortran maintainers do not either. > > The message in question made it through to fortran@, and I never > had problems there. Maybe it would be possible to let them > through automatically to gcc-patches if they are accepted to fortran? That just means any spam sent to both lists would automatically get through. That doesn't seem useful.
Re: Interest in Contributing Diagnostic System to GCC
On Mon, Feb 3, 2025 at 5:58 AM JohnyTheCarrot via Gcc wrote: > Dear Basile and other GCC friends, > > I may have not been clear about the purpose of my code. > It does not analyze code, it merely formats / constructs diagnostics for > printing to a terminal. > > I am looking to perhaps contribute the format or presentation of > this tool to GCC as an option, utilizing the existing diagnostics > and code analysis already built into GCC, and merely presenting > it in a different manner. > You'll want to coordinate with David Malcolm, who has been making a lot of improvements to GCC diagnostic output lately and is generally in charge of diagnostics. Jason
Re: Patch held up in gcc-patches due to size
On 2/2/25 11:09 AM, Thomas Koenig wrote: Hi, I sent https://gcc.gnu.org/pipermail/fortran/2025-February/061670.html to gcc-patches also, as normal, but got back an e-mail that it was too large. and that a moderator would look at it. Maybe the limits can be increased a bit, sometimes patches can be quite large, especially if they contain large test cases or a large number of generated files. I do think an increase in size is probably warranted. (Does anybody actually look at the messages, as promised in the e-mail?= I'd been doing this for a while, but at some point over the last few years I lost the password that allowed me to review this stuff. After that it never bubbled up to get attention on my list. jeff
Re: Interest in Contributing Diagnostic System to GCC
Hi David, I appreciate your very nice words! I wanted to clarify a couple points, as I'm unsure we're entirely on the same page. I am not proposing a new way to parse C++, nor am I using Rust. Mjolnir is written entirely in C++, and its only purpose is to take "labels" i.e, a span with an optional color and message, in order to display them in a visually pleasing and easy-to-parse (for humans) way. All it does is grab an already produced diagnostic and using my code, print it to the terminal. What I am proposing is an additional option (through a flag perhaps) for presentation to the user, specifically one using the visual layout demo'd on the Mjolnir GitHub page. It's nothing less or more than a diagnostics visualizer/renderer. Hence, my proposal is only visual in nature. If that is what you already knew and understood, then you may disregard my paragraphs above, I just wanted to double-check I was clear enough there. > How does mjolnir handle C++ template errors? I have not yet properly looked into this as my own compiler which Mjolnir was originally built for is a C compiler and will luckily not deal with this. I would be willing to try things out with regards to cleanly displaying such diagnostics, depending on if GCC would have a need for my code. > Have you looked into supporting SARIF as a machine-readable output format? I will be looking into it for my compiler, but it may be out of scope for my diagnostics visualizer library itself, I think. All that said, my concise question would be: is there any part of my diagnostics visualizer that would be a welcome addition to GCC? As far as licensing, API or implementation goes, I'm currently concerned primarily with the visual output, and not so much how it is achieved. I am not married to the idea of it necessarily using my library, I am willing to re-implement it as part of GCC, cherry-picking what we like and leaving out what we don't, or what is unnecessary. Also, while my Mjolnir project is likely unable to currently support much of the needs of a compiler with as wide a variety of diagnostics like GCC, it is only so because Mjolnir is about three days old, and I can expand its feature-set as GCC would need. Once again, I appreciate your kind words. Yours truly, Tuur On Monday, February 3rd, 2025 at 3:51 PM, David Malcolm wrote: > On Mon, 2025-02-03 at 09:46 +, JohnyTheCarrot via Gcc wrote: > > > Dear GCC Developers, > > > Hi Tuur > > > I'm in the process of writing my own C compiler for educational > > purposes. > > To this end, I have decided to integrate into my compiler my own C++ > > port ( https://github.com/johnythecarrot/mjolnir ) of the Rust crate > > Ariadne ( https://github.com/zesterer/ariadne ) which provides nice, > > fancy and readable diagnostics for use in compilers and the like. See > > the first link for an idea of how my library outputs diagnostics. > > > That output looks great, thanks! There are some ideas in there I may > borrow for use in GCC - we're always looking for inspiration :) > > How does mjolnir handle C++ template errors? C++ compilers have an > alarming tendency to spam the user with multiple pages of output on > even simple errors, and I wonder if you've got any ideas on this. FWIW > we're working towards addressing this in GCC; see > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253 > and an example here: > https://godbolt.org/z/xs4Gr6n6K > > > Have you looked into supporting SARIF as a machine-readable output > format? GCC supports capturing most of this "rich" diagnostic > information in its SARIF output; see e.g. > https://gcc.gnu.org/wiki/SARIF > > (or indeed, as a input format, for pretty output of SARIF log files?) > > > I had the idea of perhaps contributing this diagnostics system to GCC > > in one way or another, under a flag perhaps, but considered it might > > be an unwelcome addition. I was told that there's no harm in raising > > it with the GCC developers. > > > > This message serves as a gauge of interest from the GCC developers > > for something of this kind. I am aware the current format of my > > diagnostics do not comply with the GNU Standards, and I'd therefore > > also like to politely ask for input on your suggestions on making it > > comply while retaining its cleanliness. > > > I'm the maintainer of GCC's diagnostics subsystem, and since GCC 6 (?) > have been adding things like support for underlined ranges, fix-it > hints, and so forth. > > I confess that while I'm aware that there are some GNU standards for > diagnostics online somewhere, I've largely been ignoring them, to focus > on adding new features (what the kids today call "velocity") whilst > retaining compatibility within a >35 year old codebase, and to try to > > improve the user-experience; FWIW I've written a UX guide here for GCC > here: > https://gcc.gnu.org/onlinedocs/gccint/User-Experience-Guidelines.html > > In GCC 15 we've added some support for lines showing contr
Re: Interest in Contributing Diagnostic System to GCC
On Mon, 2025-02-03 at 09:46 +, JohnyTheCarrot via Gcc wrote: > Dear GCC Developers, Hi Tuur > > I'm in the process of writing my own C compiler for educational > purposes. > To this end, I have decided to integrate into my compiler my own C++ > port ( https://github.com/johnythecarrot/mjolnir ) of the Rust crate > Ariadne ( https://github.com/zesterer/ariadne ) which provides nice, > fancy and readable diagnostics for use in compilers and the like. See > the first link for an idea of how my library outputs diagnostics. That output looks great, thanks! There are some ideas in there I may borrow for use in GCC - we're always looking for inspiration :) How does mjolnir handle C++ template errors? C++ compilers have an alarming tendency to spam the user with multiple pages of output on even simple errors, and I wonder if you've got any ideas on this. FWIW we're working towards addressing this in GCC; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253 and an example here: https://godbolt.org/z/xs4Gr6n6K Have you looked into supporting SARIF as a machine-readable output format? GCC supports capturing most of this "rich" diagnostic information in its SARIF output; see e.g. https://gcc.gnu.org/wiki/SARIF (or indeed, as a input format, for pretty output of SARIF log files?) > > I had the idea of perhaps contributing this diagnostics system to GCC > in one way or another, under a flag perhaps, but considered it might > be an unwelcome addition. I was told that there's no harm in raising > it with the GCC developers. > > This message serves as a gauge of interest from the GCC developers > for something of this kind. I am aware the current format of my > diagnostics do not comply with the GNU Standards, and I'd therefore > also like to politely ask for input on your suggestions on making it > comply while retaining its cleanliness. I'm the maintainer of GCC's diagnostics subsystem, and since GCC 6 (?) have been adding things like support for underlined ranges, fix-it hints, and so forth. I confess that while I'm aware that there are some GNU standards for diagnostics online somewhere, I've largely been ignoring them, to focus on adding new features (what the kids today call "velocity") whilst retaining compatibility within a >35 year old codebase, and to try to improve the user-experience; FWIW I've written a UX guide here for GCC here: https://gcc.gnu.org/onlinedocs/gccint/User-Experience-Guidelines.html In GCC 15 we've added some support for lines showing control flow, and for colorized labels highlighting and contrasting different syntactic elements; see e.g.: https://gcc.gnu.org/wiki/cauldron2024talks?action=AttachFile&do=get&target=2024-Cauldron-diagnostics-talk.pdf and the "ASCII" art for buffer overflows added in GCC 14 here: https://developers.redhat.com/articles/2024/04/03/improvements-static-analysis-gcc-14-compiler#visualizing_buffer_overflows > > I am the sole developer of Mjolnir and can therefore relicense it as > necessary. Mjolnir still has a couple of issues to iron out and > features to implement, such as multi-line span displaying. Licensing (under a GPL-compatible license) isn't an issue so much as implementation language. GCC has rather conservative build requirements, since we must be buildable of a wide variety of old machines with hundreds of configure-time variants. Although we implement the very latest versions of C++ and have the beginnings of Rust support, we implement all this in a subset of C++14 (and until recently this was only C++11), and this subset has to be compatible with a few other tools. So, sadly, implementing core GCC functionality in Rust isn't an option at this point (I wish it were, but I don't see it happening any time soon, I'm afraid). That said, I really like what you're doing. >From am implementation point of view, GCC has a text_art::canvas class for "painting" colorized text to a buffer with random access for output to a stream, and a text_art::widget class for doing hierarchical dynamic sizing of drawing elements. There's also a rich_location class which is used by diagnostics that are doing anything "fancy", though perhaps this could be refactored into an API similar to ariadne's (or one of the similar projects). Hope this is constructive; thanks again for the links, and good luck with mjolnir. Dave
Re: Interest in Contributing Diagnostic System to GCC
On Mon, 2025-02-03 at 11:49 +0100, Basile Starynkevitch wrote: > > > > > > I'm in the process of writing my own C compiler for educational > > purposes. > > > Then look also into https://frama-c.com/ and > https://github.com/bstarynk/bismon > and https://nwcc.sourceforge.net/ and https://bellard.org/tcc/ > > > To this end, I have decided to integrate into my compiler my own > > C++ port ( > > https://github.com/johnythecarrot/mjolnir ) of the Rust crate > > Ariadne ( > > https://github.com/zesterer/ariadne ) which provides nice, fancy > > and readable > > diagnostics for use in compilers and the like. See the first link > > for an idea > > of how my library outputs diagnostics. > > > > I had the idea of perhaps contributing this diagnostics system to > > GCC in one > > way or another, under a flag perhaps, but considered it might be an > > unwelcome > > addition. I was told that there's no harm in raising it with the > > GCC > > developers. > > > > This message serves as a gauge of interest from the GCC developers > > for > > something of this kind. I am aware the current format of my > > diagnostics do not > > comply with the GNU Standards, and I'd therefore also like to > > politely ask for > > input on your suggestions on making it comply while retaining its > > cleanliness. > > > > I am the sole developer of Mjolnir and can therefore relicense it > > as > > necessary. Mjolnir still has a couple of issues to iron out and > > features to > > implement, such as multi-line span displaying. > > As far as I understand, GCC code needs to be GPL licensed with a > copyright > assignment contract to the FSF. (See > https://gcc.gnu.org/legacy-ml/gcc/2006-12/msg8.html > and https://arxiv.org/abs/1109.0779 ) > > regarding your fancy diagnostic system, consider working at the > GIMPLE level and > implementing it (at first) as an open source GCC plugin. > https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html > https://gcc.gnu.org/onlinedocs/gccint/Plugins.html Basile, I don't think that's a good idea. What Tuur seems to be advocating for is: (a) improvements to GCC's diagnostics subsystem (in terms of internal API and presentation), which is part of GCC's core functionality, and/or (b) a new approach to parsing C++, which sounds like essentially a replacement of the existing C++ frontend (and thus very ambitious) Neither of these would be appropriate as a plugin. Hope this is constructive Dave
Re: Interest in Contributing Diagnostic System to GCC
On Mon, 2025-02-03 at 11:24 +0100, Mark Wielaard wrote: > Hi Tuur, > > On Mon, Feb 03, 2025 at 09:46:37AM +, JohnyTheCarrot via Gcc > wrote: > > I'm in the process of writing my own C compiler for educational > > purposes. > > To this end, I have decided to integrate into my compiler my own > > C++ > > port ( https://github.com/johnythecarrot/mjolnir ) of the Rust > > crate > > Ariadne ( https://github.com/zesterer/ariadne ) which provides > > nice, > > fancy and readable diagnostics for use in compilers and the > > like. See the first link for an idea of how my library outputs > > diagnostics. > > Looks nice. Very much agreed. > Note that the current diagnostics library GCC uses is > described here: https://gcc.gnu.org/wiki/libgdiagnostics > https://gcc.gnu.org/cgit/gcc/tree/gcc/libgdiagnostics.h > https://gcc.gnu.org/onlinedocs/libgdiagnostics/ To nitpick: GCC doesn't actually *use* libgdiagnostics: both GCC and libgdiagnostics use the same underlying code; libgdiagnostics is a way of exposing that functionality to 3rd-party code. libgdiagnostics presents a cleaned up, opaque, C API to the world, which is similar to but *not* the rather messy C++ API used by GCC and libgdiagnostics internally (though I hope to clean this up and gradually harmonize all this, without breaking anything... [famous last words]) Dave
Re: Patch held up in gcc-patches due to size
On Sun, 2 Feb 2025, 18:10 Thomas Koenig via Gcc, wrote: > Hi, > > I sent https://gcc.gnu.org/pipermail/fortran/2025-February/061670.html > to gcc-patches also, as normal, but got back an e-mail that it > was too large. and that a moderator would look at it. > > Maybe the limits can be increased a bit, sometimes patches can > be quite large, especially if they contain large test cases > or a large number of generated files. > The limits for gcc-patches are already larger than other lists, but 560kB is pretty big. You can gzip the patch if it's too large. > (Does anybody actually look at the messages, as promised in the e-mail? > I don't know about that list. There are moderators and mod queues for other gcc lists. > >
Re: Patch held up in gcc-patches due to size
On Mon, Feb 3, 2025 at 9:55 AM Jonathan Wakely wrote: > > > > On Sun, 2 Feb 2025, 18:10 Thomas Koenig via Gcc, wrote: >> >> Hi, >> >> I sent https://gcc.gnu.org/pipermail/fortran/2025-February/061670.html >> to gcc-patches also, as normal, but got back an e-mail that it >> was too large. and that a moderator would look at it. >> >> Maybe the limits can be increased a bit, sometimes patches can >> be quite large, especially if they contain large test cases >> or a large number of generated files. > > > The limits for gcc-patches are already larger than other lists, but 560kB is > pretty big. You can gzip the patch if it's too large. > >> >> (Does anybody actually look at the messages, as promised in the e-mail? > > > > I don't know about that list. There are moderators and mod queues for other > gcc lists. I don't think we ever unlock too large mails. But I'm not sure the message you get can be altered individually based on the reason of the moderation. Richard. > >> >>
