Applying patch to longlong.h
Hi, I would like to apply the ARC specific fix for bugzilla 89877 to include/longlong.h file, but I don't know for sure if I am allowed or not. I mention that I am the ARC reviewer. Thanks, Claudiu
Re: GSOC Proposal
On 3/29/19, nick wrote: > > > On 2019-03-29 10:28 a.m., nick wrote: >> >> >> On 2019-03-29 5:08 a.m., Richard Biener wrote: >>> On Thu, 28 Mar 2019, nick wrote: >>> On 2019-03-28 4:59 a.m., Richard Biener wrote: > On Wed, Mar 27, 2019 at 6:31 PM nick wrote: >> >> Greetings All, >> >> I've already done most of the work required for signing up for GSoC >> as of last year i.e. reading getting started, being signed up legally >> for contributions. >> >> My only real concern would be the proposal which I started writing >> here: >> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit?usp=sharing >> >> The biography and success section I'm fine with my bigger concern >> would be the project and roadmap >> section. The roadmap is there and I will go into more detail about it >> in the projects section as >> need be. Just wanted to known if the roadmap is detailed enough or can >> I just write out a few >> paragraphs discussing it in the Projects Section. > > I'm not sure I understand either the problem analysis nor the project > goal parts. What > shared state with respect to garbage collection are you talking about? > > Richard. > I just fixed it. Seems we were discussing RTL itself. I edited it to reflect those changes. Let me know if it's unclear or you would actually like me to discuss some changes that may occur in the RTL layer itself. I'm glad to be more exact if that's better but seems your confusion was just what layer we were touching. >>> >>> Let me just throw in some knowledge here. The issue with RTL >>> is that we currently can only have a single function in this >>> intermediate language state since a function in RTL has some >>> state in global variables that would differ if it were another >>> function. We can have multiple functions in GIMPLE intermediate >>> language state since all such state is in a function-specific >>> data structure (struct function). The hard thing about moving >>> all this "global" state of RTL into the same place is that >>> there's global state in the various backends (and there's >>> already a struct funtion 'machine' part for such state, so there's >>> hope the issue isn't as big as it could be) and that some of >>> the global state is big and only changes very rarely. >>> That said, I'm not sure if anybody knows the full details here. >>> >>> So as far as I understand you'd like to tackle this as project >>> with the goal to be able to have multiple functions in RTL >>> state. >>> >>> That's laudable but IMHO also quite ambitious for a GSoC >>> project. It's also an area I am not very familiar with so >>> I opt out of being a mentor for this project. >>> >> While I'm aware of three areas where the shared state is an issue >> currently: >> 1, Compiler's Proper >> 2. The expand_functions >> 3. RTL >> 4.Garbage Collector >> >> Or maybe a project to be more >> explicit about regions of the code that assume that the garbage- >> collector can't run within them?[3] (since the GC is state that would >> be shared by the threads). >> >> This is what we were discussing previously and I wrote my proposal for >> that. You however seem confused about what parts of the garbage collector >> would be touched. That's fine with me, however seems you want be to >> be more exact about which part is touched. >> >> My questions would be as it's changed back to the garbage collector >> project: >> https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit >> >> 1. Your confusion about which part of the garbage collector is touched >> doesn't >> really make sense s it's for the whole garbage collector as related to >> shared >> state? >> 2. Injection was my code here in phase 3 for the callers of the new >> functions or >> macros, perhaps this is not needed as the work with the garbage collector >> is enough? >> 3. Am I not understanding this project as I thought I was in the proposal >> I wrote? >> >> Seems your more confusing my wording probably so I'm going to suggest one >> of >> two things here: >> a) I'm going to allow you to make comments with what's confusing you and >> it needs that's the issue here more than anything else so I sent you >> a link and please comment where you are having issues with this not >> be clear for you: >> Or maybe a project to be more >> explicit about regions of the code that assume that the garbage- >> collector can't run within them?[3] (since the GC is state that would >> be shared by the threads). >> as that's the actual project >> >> b) Just comment here about the wording that's an issue for you or >> where you want more exact wording >> >> Sorry and hopefully this is helps you understand where I'm going, >> Nick >> >>> Richard. >>> Nick >> Any other comments are welcome as well as I write it there, >> Nick
Re: Status of all 3 aktiv bracnhes on x86_64-w64-mingw32.
Nevermind, the Ada issue only affects the 32 bits build. Óscar Fuentes writes: > Rainer Emrich writes: > >> Test results here: >> >> 7.4.1 revision 270001 >> https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03790.html >> >> 8.3.1 revision 270001 >> https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03824.html >> >> 9.0.1 revision 270001 >> https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03904.html >> >> Complete logs can be found here: >> https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W > > Thank you. > > I see that you config with "--enable-languages=all". On the MSYS2 > project Ada fails to build for MinGW-w64 since gcc 8. I wonder what's > special on your builds to succeed.
gcc-9-20190331 is now available
Snapshot gcc-9-20190331 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20190331/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 270048 You'll find: gcc-9-20190331.tar.xzComplete GCC SHA256=d9d5a0f42bd2fe4a942452d1699d3f0310d8bcf5e7068e29003a73161d32b055 SHA1=3de7c6deee17e51bfe16e892c9beeccd03d8eb79 Diffs from 9-20190324 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Status of all 3 aktiv bracnhes on x86_64-w64-mingw32.
Rainer Emrich writes: > Test results here: > > 7.4.1 revision 270001 > https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03790.html > > 8.3.1 revision 270001 > https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03824.html > > 9.0.1 revision 270001 > https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03904.html > > Complete logs can be found here: > https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W Thank you. I see that you config with "--enable-languages=all". On the MSYS2 project Ada fails to build for MinGW-w64 since gcc 8. I wonder what's special on your builds to succeed.
Re: syncing the GCC vax port
On Sun, Mar 31, 2019 at 01:25:50PM -0400, Paul Koning wrote: > > > > On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote: > > > > hi folks, > > > > i was interesting in tackling some problems gcc netbsd/vax has. > > it has some ICEs which are in reload phase. searching around, the answer > > to that is "switch to LRA first". Now, I don't quite know what that is > > yet, but I know I need to try to do it. > > That's not quite the whole story. > > The answer is (1) switch from CC0 to CCmode condition code handling, which > enables (2) switch from Reload to LRA. > > (1) requires actual work, not terribly hard but not entirely trivial. (2) > may take as little as switching the "use LRA" flag to "yes". > > I did (1) as well as a tentative (2) for pdp11 last year. It was reasonably > straightforward thanks to a pile of help from Eric Botcazou and his gcc wiki > articles on the subject. You might find the pdp11 deltas for CCmode helpful > as a source of ideas, since the two machines have a fair amount in common as > far as condition codes goes. At least for the integer ops (pdp11 has > separate floating point conditions, vax doesn't). > > paul > Hi paul! I have been reading on this, so now I have a draft that compiles the world's simplest C code (and nothing more, it will crash), but using CCmode (I think). I am being inspired by your port (which is a good thing since I know I can ask questions about it :)) https://github.com/coypoop/gcc/commit/df135c019de33950c9997fdea3ce07c5c920384d (I know that it's wrong!)
Re: syncing the GCC vax port
> On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote: > > hi folks, > > i was interesting in tackling some problems gcc netbsd/vax has. > it has some ICEs which are in reload phase. searching around, the answer > to that is "switch to LRA first". Now, I don't quite know what that is > yet, but I know I need to try to do it. That's not quite the whole story. The answer is (1) switch from CC0 to CCmode condition code handling, which enables (2) switch from Reload to LRA. (1) requires actual work, not terribly hard but not entirely trivial. (2) may take as little as switching the "use LRA" flag to "yes". I did (1) as well as a tentative (2) for pdp11 last year. It was reasonably straightforward thanks to a pile of help from Eric Botcazou and his gcc wiki articles on the subject. You might find the pdp11 deltas for CCmode helpful as a source of ideas, since the two machines have a fair amount in common as far as condition codes goes. At least for the integer ops (pdp11 has separate floating point conditions, vax doesn't). paul
[GSoC 2019] Proposal: Parallelize GCC With Threads
Hi, I wrote my GSoC Proposal to the "Parallelize GCC with threads" project, and if someone is interested in it, I am linking the text here in order to get feedback. Please let me know if something is not entirely clear, or if there are any problems with the calendar, or if you have any suggestions. :-) Link to the proposal: https://github.com/giulianobelinassi/proposta-gsoc/blob/master/proposta.pdf GitHub seems mess up with the PDF hyperlinks in their viewer, therefore you will need to download the PDF if you want to click on them, or use this mirror i've set: https://www.ime.usp.br/~belinass/GSoC-Proposal.pdf Thank you, Giuliano.
