Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

On Mon, Jul 29, 2024 at 12:41 PM Björn Schäpers wrote: > > > Instead of deleting those, move them inside the parentheses: > > > > typedef VOID (CALLBACK *LDR_DLL_NOTIFICATION)(ULONG, > > struct dll_notification_data*, > >

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote: > > Am 10.01.2024 um 13:34 schrieb Eli Zaretskii: > >> Date: Tue, 9 Jan 2024 21:02:44 +0100 > >> Cc: i...@google.com, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org > >> From: Björn Schäpers > >> > >> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii: >

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

On Thu, May 2, 2024 at 12:23 PM Björn Schäpers wrote: > > Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor: > > > > Which of your other patches are still relevant? Thanks. > > > only this one. Thanks. Committed. Ian

Re: Updated Sourceware infrastructure plans

On Wed, May 1, 2024 at 11:48 PM Richard Biener wrote: > > We'd only know for sure if we try. But then I'm almost 100% sure that > having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA > I am using for "quick" patch review. It might be comparable to the > review parts I do in

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers wrote: > > > Attached is the combined version of the two patches, only implementing the > > variant with the tlhelp32 API. > > > > Tested on x86 and x86_64 windows. > > > > Kind regards, > > Björn. > > A friendly ping. Thanks. Committed as follows.

Re: Updated Sourceware infrastructure plans

On Tue, Apr 23, 2024 at 2:32 AM Richard Earnshaw (lists) via Gcc wrote: > > I've been forced to use gerrit occasionally. I hate it. No, I LOATHE it. > The UI is anything but intuitive with features hidden behind unobvious > selections. IMO It's not a tool for a casual developer, which makes

Re: Sourceware mitigating and preventing the next xz-backdoor

On Wed, Apr 3, 2024 at 11:05 AM Toon Moene wrote: > > Two questions arise (as far as I am concerned): > > 1. Do daemons like sshd *have* to be linked with shared libraries ? > Or could it be left to the security minded of the downstream > (binary) distributions to link it statically with k

Re: Sourceware mitigating and preventing the next xz-backdoor

On Tue, Apr 2, 2024 at 1:21 PM Paul Koning via Gcc wrote: > > Would it help to require (rather than just recommend) "don't use root except > for the actual 'install' step" ? Seems reasonable, but note that it wouldn't make any difference to this attack. The liblzma library was modified to corru

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

On Thu, Jan 25, 2024 at 11:53 AM Björn Schäpers wrote: > > Am 23.01.2024 um 23:37 schrieb Ian Lance Taylor: > > On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: > >> > >> Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > >>> Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > On Fri, Jan 2

Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls

On Thu, Jan 4, 2024 at 2:33 PM Björn Schäpers wrote: > > Am 03.01.2024 um 00:12 schrieb Björn Schäpers: > > Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor: > >> On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: > >>> > >>> From: Björn Schäpers > >>> > >>> Fixes https://github.com/ianlanceta

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote: > > From: Björn Schäpers > > Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except > that libraries loaded after the backtrace_initialize are not handled. > But as far as I can see that's the same for elf. Thanks, but I don't

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

On Mon, Nov 20, 2023 at 11:58 AM Björn Schäpers wrote: > > An updated version, using neither A or W, but just the macro. Thanks. Committed as follows. Ian 1017495bc91d40570f58c37e88ca013164782129 diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c index 56af4828e27..f976a963bf3 100644 --

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

On Mon, Nov 20, 2023 at 11:57 AM Björn Schäpers wrote: > > this is what I'm using with GCC 12 and 13 on my windows machines, rebased onto > the current HEAD. Thanks. Committed as follows. Ian * fileline.c: Include if available. (windows_get_executable_path): New static

Re: wishlist: support for shorter pointers

On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc wrote: > > W dniu 28.06.2023 o 17:44, Richard Earnshaw (lists) pisze: > [---] > > I think I understand what you're asking for but: > > 1) You'd need a new ABI specification to handle this, probably involving > > register assignments (f

Re: New version of gnu assembler

On Sun, Jul 2, 2023 at 9:50 AM Dave Blanchard wrote: > > On Sat, 01 Jul 2023 13:33:07 +0100 > Sam James via Gcc wrote: > > > If you've taken files from Binutils BFD, please make sure you preserve > > the copyright headers too. > > Why? How is that important? That's all you have to say about this?

Re: When do I need -fnon-call-exceptions?

On Wed, Jun 7, 2023 at 10:09 AM Helmut Zeisel via Gcc wrote: > > I wrote some simple program that set a signal handler for SIGFPE, throws a > C++ exception in the signal handler > and catches the exception. > I compiled with and without -fnon-call-exceptions (on x64 Linux). > In both cases, the r

Re: More C type errors by default for GCC 14

On Tue, May 9, 2023 at 9:45 AM Florian Weimer via Gcc wrote: > > The part David quoted above is about this: > > $ gcc -fno-gnu89-inline -std=gnu89 t.c > cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode > > And some packages need -fno-gnu89-inline, but also rely on implicit in

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

On Sun, Feb 5, 2023 at 1:21 AM Björn Schäpers wrote: > > Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor: > > On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches > > wrote: > >> > >>> From: Ian Lance Taylor > >>> Date: Tue, 24 Jan 2023 09:58:10 -0800 > >>> Cc: g...@hazardy.de, gcc-pat

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches wrote: > > > From: Ian Lance Taylor > > Date: Tue, 24 Jan 2023 09:58:10 -0800 > > Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org > > > > I'd rather that the patch look like the appended. Can someone with a > > Windows

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

On Tue, Jan 24, 2023 at 8:53 AM Eli Zaretskii via Gcc-patches wrote: > > > From: Ian Lance Taylor > > Date: Tue, 24 Jan 2023 06:35:21 -0800 > > Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org > > > > > > On Windows it seems that MAX_PATH is not > > > > a true limit, as an extended l

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

On Tue, Jan 24, 2023 at 5:11 AM Eli Zaretskii via Gcc-patches wrote: > > > Date: Mon, 23 Jan 2023 15:00:56 -0800 > > Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org > > From: Ian Lance Taylor via Gcc > > > > > +#ifdef HAVE_WINDOWS_H > > > + > >

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

On Fri, Jan 20, 2023 at 2:56 AM Björn Schäpers wrote: > > From: Björn Schäpers > > This is actually needed so that libstdc++'s implementation > to be able to work on windows. > > Tested on x86_64-linux and i686-w64-mingw32. > > -- >8 -- > > * configure.ac: Add a check for windows.h. >

Re: [PATCH 1/4] libbacktrace: change all pc related variables to uintptr_t

On Fri, Jan 20, 2023 at 2:54 AM Björn Schäpers wrote: > > From: Björn Schäpers > > It's the right thing to do, since the PC shouldn't go out of the > uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t. > This is a preparation for a following patch. > > Tested on x86_64-linux and i686-w

Re: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc

On Wed, Aug 3, 2022 at 6:26 AM j wrote: > > I've proposed a patch [1] for condition coverage profiling in gcc, > implemented in the middle-end alongside the branch coverage. I've > written most of the tests for C and a few for C++ and finally got around > to try it with a toy example for D and go

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

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

Re: removing toxic emailers

On Tue, Apr 20, 2021, 12:54 AM Jonathan Wakely via Gcc wrote: > > Check the git logs, Google employees are minor contributors these > days. The GPLv3 scared Google away from GCC years ago. > Just for the record, Google has no problem with the GPLv3. Google stopped working on GCC because they ma

Re: removing toxic emailers

This conversation has moved well off-topic for the GCC mailing lists. Some of the posts here do not follow the GNU Kind Communication Guidelines (https://www.gnu.org/philosophy/kind-communication.en.html). I suggest that people who want to continue this thread take it off the GCC mailing list. T

Re: removing toxic emailers

On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote: > > When I refer to a 'California cultural standard', that's not prescriptive. > It's > just a reference to the fact that a *lot* of the SC live in California, and > any > culture prescribed by the steering committee will be overly influenced by that

Re: removing toxic emailers

On Thu, Apr 15, 2021 at 9:08 PM Frosku wrote: > > On the other hand, I also think that a project which goes too far in > policing speech, especially speech unrelated to the project, will drive away > talented people who are more than willing to comply with the project's norms > within the project'

Re: removing toxic emailers

On Thu, Apr 15, 2021 at 9:09 PM Eric S. Raymond wrote: > > Ian Lance Taylor : > > Patronizing or infantilizing anybody doesn't come into this at all. > > I am not even *remotely* persuaded of this. This whole attitude that if > a woman is ever exposed to a man with less than perfect American > up

Re: removing toxic emailers

On Thu, Apr 15, 2021 at 8:02 PM Frosku wrote: > > > We want free software to succeed. Free software is more likely to > > succeed if more people work on it. If you are a volunteer, as many > > are, you can choose to spend your time on the project where you have > > to short-stop unwelcome advances

Re: removing toxic emailers

On Thu, Apr 15, 2021 at 4:29 PM Eric S. Raymond wrote: > > *grumble* Get *over* yourselves. You want to be "welcoming" to > women? Don't patronize or infantilize them - respect their ability to > tell off RMS for themselves *and then keep working with him*! Thank you for sharing your experience

Re: removing toxic emailers

On Thu, Apr 15, 2021 at 1:26 PM Chris Punches via Gcc wrote: > > Every single proponent of this argument that I have seen so far is > employed by one of the same 5 companies and "really isn't doing it on > behalf of my company I swear". > > Why is it almost exclusively that specific crowd saying i

Re: removing toxic emailers

On Thu, Apr 15, 2021 at 12:45 PM Christopher Dimech via Gcc wrote: > > Proposing the guidelines essentially means that the community accepts the fact > that many of us are incapable of navigate everyday problems and dilemmas by > making > “right” decisions based on the use of good judgment and va

Re: removing toxic emailers

On Thu, Apr 15, 2021 at 10:31 AM David Malcolm via Gcc wrote: > > I still admire much of what RMS has written, and have spent much of my > career trying to implement part of a vision inspired by him. I'm sad > about the way things have turned out. Twitter seems to turn everything > into a pitche

Re: removing toxic emailers

On Wed, Apr 14, 2021 at 4:39 PM Frosku wrote: > > On Thu Apr 15, 2021 at 12:36 AM BST, Ian Lance Taylor wrote: > > > > (And I'm still not sure why you think he would "probably be > > moderating.") > > > > Ian > > In my experience, those people who seek code of conducts generally envision > themsel

Re: removing toxic emailers

On Wed, Apr 14, 2021 at 4:28 PM Frosku wrote: > > On Thu Apr 15, 2021 at 12:19 AM BST, Ian Lance Taylor wrote: > > On Wed, Apr 14, 2021 at 3:41 PM Frosku wrote: > > > > > > I think, in general, it's fine to leave this decision to moderators. It's > > > just a little disconcerting when one of the

Re: removing toxic emailers

On Wed, Apr 14, 2021 at 3:41 PM Frosku wrote: > > I think, in general, it's fine to leave this decision to moderators. It's > just a little disconcerting when one of the people who would probably be > moderating is saying that he could have shut down the discussion if he > could only ban jerks, as

Re: removing toxic emailers

On Wed, Apr 14, 2021 at 2:24 PM Jeff Law wrote: > > But yes, I understand your point and it's a good one and I think we can > probably find some common ground there -- but even so I think banning > should be a rare event and some official outreach to the offender should > happen first. Agreed (ex

Re: removing toxic emailers

On Wed, Apr 14, 2021 at 1:49 PM Paul Koning wrote: > > > On Apr 14, 2021, at 4:39 PM, Ian Lance Taylor via Gcc > > wrote: > > > > On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc wrote: > >> > >> once or twice when physical violence with thr

Re: removing toxic emailers

On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc wrote: > > once or twice when physical violence with threatened, but that's about > it (aside from spammers). I don't think we want to get too deep into > moderation and the like -- IMHO it should be an extremely rare event. > As much as I disagree

Re: GCC association with the FSF

On Sun, Apr 11, 2021 at 8:04 AM David Brown wrote: > > On 11/04/2021 16:37, Richard Kenner via Gcc wrote: > >> I guess my point is that the direction in which a project *does* go is not > >> always the direction in which it *should* go. > > > > I agree. And depending on people's "political" views

Re: GCC association with the FSF

On Sat, Apr 10, 2021 at 4:36 AM Pankaj Jangid wrote: > > I think, it would be great help if someone can document what the SC > does. I don't know whether anybody actually tried to answer this. The main job of the GCC steering committee is to confirm GCC maintainers: the people who have the right

Re: GCC association with the FSF

On Fri, Apr 9, 2021, 1:04 PM Giacomo Tesio wrote: > Hi John, > > On April 9, 2021 6:36:31 PM UTC, John Darrington < > j...@darrington.wattle.id.au> wrote: > > On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote: > > > > Different opinions are fine. Bringing national or international

Re: Remove RMS from the GCC Steering Committee

On Tue, Apr 6, 2021 at 3:28 AM Richard Biener wrote: > > Seeing the word "dysfunction" I don't remember using I want to clarify > the non-openess which I intended to criticize. The SC is not "open" because: > - it appoints itself (new members, that is) - in fact in theory it > should be appointed

Re: RMS removed from the GCC Steering Committee

On Sun, Apr 4, 2021 at 6:11 AM Giacomo Tesio wrote: > > with all respect with your personal history, your contributions and > choices, I think you are still missing the point. This conversation is going on circles. You do not seem to hear what I am saying, and you are telling me that I am not he

Re: RMS removed from the GCC Steering Committee

On Sat, Apr 3, 2021 at 10:31 AM Giacomo Tesio wrote: > > I'm still just one Italian hacker: all the huge imbalances that the > removal of the only FSF and GNU member of the Steering Committee > uncovered, are still there! As far as I can tell, the imbalances you refer to are the fact that the GCC

Re: RMS removed from the GCC Steering Committee

On Fri, Apr 2, 2021 at 3:06 AM Giacomo Tesio wrote: > > I'm sorry for this long mail that rivals with the original Nathan's > request, but I wanted to back my request properly. This is free software. If you want to make it better, then make it better. The EGCS branch that displaced and became G

Re: Remove RMS from the GCC Steering Committee

On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell wrote: > > You, the SC, have chosen to fix this as a clerical error. The most > do-nothing response, other than actually doing nothing. > > I am profoundly disappointed that you have not even acknowledged the > harm RMS has caused. Using passive voi

Re: Remove RMS from the GCC Steering Committee

On Wed, Mar 31, 2021 at 7:44 AM Joel Sherrill wrote: > > On Wed, Mar 31, 2021 at 9:23 AM Paul Koning via Gcc wrote: > > > I may have lost it in the enormous flood of text, but I want to ask these > > general questions. > > > > 1. Is there a published code of conduct for GCC community members, > >

Re: Remove RMS from the GCC Steering Committee

On Wed, Mar 31, 2021 at 5:28 AM Richard Biener via Gcc wrote: > > And just to repeat - all the GCC governance structure (the "SC") represents > all of the same non-openess as the FSF governance structure (because > the "SC" is in fact appointed by the Chief GNUisance "or his delegates"). While th

Re: Remove RMS from the GCC Steering Committee

I encourage everyone to please try to keep this discussion focused on GCC. If there is a message that is completely unrelated to GCC, I encourage not responding, or responding off-list. Thanks. Ian

Re: Remove RMS from the GCC Steering Committee

On Mon, Mar 29, 2021 at 4:33 PM Christopher Dimech via Gcc wrote: > > Here is something close to the fundamental issue: Believing in private life, > that people are entitled to their own associations and opinions (even bad > ones!), > and entitled to make their own mistakes, too — and that, barri

Re: ChangeLog files - server and client scripts

On Mon, May 25, 2020 at 12:48 AM Martin Liška wrote: > > On 5/23/20 12:14 AM, Ian Lance Taylor wrote: > > Sure, I can wait. Thanks for looking at it. > > Hello. > > Thank you for patience. There's a patch that fixes that, > I'm going to install it. Thanks. I was able to push my change to master

Re: ChangeLog files - server and client scripts

On Fri, May 22, 2020 at 12:48 PM Jakub Jelinek wrote: > > On Fri, May 22, 2020 at 12:37:29PM -0700, Ian Lance Taylor wrote: > > Thanks for looking into this. > > > > Unfortunately, my push is still failing. I'm not sure why. > > > > remote: *** ChangeLog format failed: > > remote: ERR: cannot fin

Re: ChangeLog files - server and client scripts

On Fri, May 22, 2020 at 4:11 AM Jakub Jelinek wrote: > > On Fri, May 22, 2020 at 12:04:10PM +0100, Richard Earnshaw wrote: > > >> The directories in question are > > >> > > >> gcc/go/gofrontend > > >> libgo > > >> gcc/testsuite/go.test/test > > > > > > The script has: > > > ignored_prefixes = [ >

Re: ChangeLog files - server and client scripts

On Tue, May 19, 2020 at 2:26 AM Martin Liška wrote: > > We've just installed server git hooks that verify git messages > for a correct ChangeLog format. For a limited time period, please > still apply ChangeLog changes to the corresponding ChangeLog files. > We'll use it for comparison of auto-gen

Re: back to cvs, cool

On Wed, May 13, 2020 at 9:56 AM Mike Stump via Gcc wrote: > > As seen in recent bug report: > > CVS Commits 2020-05-12 20:40:40 UTC > > I guess that git thing was a bust and we're back to using cvs now. At least > Ian did up the remote patches to make cvs work better. In fairness, I worked on

Re: Question about git: merging to gccgo branch

On Mon, Mar 30, 2020 at 10:54 AM Joseph Myers wrote: > > On Mon, 30 Mar 2020, Martin Liška wrote: > > > Can you please disable email sending for user branch? Or does it make any > > sense? > > Email sending for user branches makes perfect sense, to make visible the > development going on. It's sp

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD wrote: > > Which brings me to something I find strange in your policy: to me, > merges from trunk to branches should be rare if not nonexistent. And you > are deciding to banish merges the other way around. Out of curiosity, why do you s

Re: Errors building libgcc for powerpc64le-linux-gnu

On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool wrote: > > On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote: > > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool > > wrote: > > > > > > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lan

Re: Errors building libgcc for powerpc64le-linux-gnu

On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool wrote: > > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote: > > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu, > > cross-compiling from x86_64-pc-linux-gnu. I'm at

Re: Errors building libgcc for powerpc64le-linux-gnu

On Sat, Dec 14, 2019 at 10:51 AM Ian Lance Taylor wrote: > > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu, > cross-compiling from x86_64-pc-linux-gnu. I'm at SVN revision 279830. > I'm seeing the following. Is anybody else seeing this crash? Thanks. > > Ian > > /tmp/go-

Errors building libgcc for powerpc64le-linux-gnu

I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu, cross-compiling from x86_64-pc-linux-gnu. I'm at SVN revision 279830. I'm seeing the following. Is anybody else seeing this crash? Thanks. Ian /tmp/go-build-release/gccgo-objdir/ppc/./gcc/xgcc -B/tmp/go-build-release/gccgo-

Re: Is GIMPLE stable?

On Mon, Sep 9, 2019 at 8:09 PM Mateus Carmo Martins de Freitas Barbosa wrote: > > There's an ongoing discussion on the rustc forum > () > on implementing a GCC front-end for the Rust compiler, and

Re: GCC 1.40.

On Fri, Sep 14, 2018 at 3:40 AM, ?yvind Hagen via gcc wrote: > > Hi to you in GCC Development department. > Do you still have manual Version 1.40 so I can decode if that code in Linux > 0.01 is correctly set up 100% and just that. > And, I am wondering if that is easy to decode MS-DOS 5.0 to run

Re: GCC and Meltdown and Spectre vulnerabilities

On Thu, Jan 4, 2018 at 7:14 PM, Zan Lynx wrote: > > On January 4, 2018 8:10:14 PM MST, Eric Gallager wrote: >>Is there anything GCC could be doing at the compiler level to mitigate >>the recently-announced Meltdown and Spectre vulnerabilities? From >>reading about them, it seems like they involve

Re: GCC Runtime Library Exception in gcc/config/* files?

On Fri, Jul 21, 2017 at 2:24 AM, Sebastian Huber wrote: > > there are some files in gcc/config/* that contain the GCC Runtime Library > Exception > > grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l gcc/config | > wc > 186 1865361 > > and some files that don't include it >

Re: GNU Toolchain Fund established at the Free Software Foundation

On Thu, Mar 9, 2017 at 11:49 AM, David Edelsohn wrote: > A fund to benefit the components of the GNU Toolchain (GCC, GDB, > GLIBC, Binutils, Sourceware) has been established at the Free Software > Foundation. > > Personal and corporate donations are welcome! > > http://www.fsf.org/news/gnu-toolcha

Re: GPLv3 clarification - what constitutes IR

On Mon, Mar 6, 2017 at 9:12 AM, wrote: > > I'm looking into the possibility of adding a SPIR-V > (https://www.khronos.org/registry/spir-v) backend to GCC or as a > plug-in. The output of which would be binary from the compiler, not > binutils, with an option to extract a textual representation us