iNGYEN LETOLTES!
Szia! Emlékszel amikor arról beszéltem hogy meg fog nyílni Magyarország legjobb letöltõ oldala? Na, ha igen, akkor itt a link. Jó szorakozást! :) http://href.hu/x/4pnj
Re: gcc 4.6 release date
On Monday 17 of January 2011 11:49:04 Richard Guenther wrote: > 2011/1/16 Mehmet Sinan Şahin : > > Hi, > > > > When do you plan to release gcc 4.6? > > When it's ready. will 4.6 c++0x regression (experimental code) will be taken into account? i'm assking because i'm currently use few c++0x features in my code base with 4.5 and would be nice to have 4.6 with the same c++0x subset working.
Re: gcc 4.6 release date
On Monday 17 of January 2011 16:32:32 Jonathan Wakely wrote: > 2011/1/17 Pawel Sikora : > > > > will 4.6 c++0x regression (experimental code) will be taken into account? > > i'm assking because i'm currently use few c++0x features in my code base > > with 4.5 and would be nice to have 4.6 with the same c++0x subset working. > > You can look at the priority field in bugzilla. If they have priority > P1 then it means they should be fixed before 4.6 can be released e.g. > PR 47067. If they aren't P1 (or there is no PR) then they won't block > the release. i think about these 3 regressions: Bug 46552 - [4.6 Regression][C++0x] Internal compiler error on pointer to member variable with template. Bug 47311 - [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502. Bug 47317 - [4.6 Regression][C++0x] ICE in fixed_type_or_null. they have P3 prio but afaics the P1/P2 are used for serious regressions in released code. c++0x implementation is still an experimental compiler feautre. can we raise a prio for expreimental feature regression?
Can help with task of language frontend cleanup
Hello, Not sure which list is right. I have ideas for code improvement for gcc. Idea1 langhooks cleanup It basically involves clean up of lang hooks. Closing it in special class. Might help to clean up massive defines etc spurious langhooks declarations amongst others and removing some hooks from hooks.h/c and langhooks.h/c. Also in this solution wed gain some cputime by not calling langhooks via func pointers. Idea 1a multiple langhooks in single binary. Choosable in runtime. Ideally will allow compiling in multiple frontends in single binary and choosing in runtime which lang front to use. It doesnt seem very difficult just quite laborious. If anyone is interested in such improvement please authorize me to branch off. Ill drop my changes there. Will need help with extending build system/configure/makefiles. Idea2 multiple targets in single binary choosable at runtime. With those two tasks we will gains some modularity maintainability better architecture and more on par with llvm/clang features. Ps. Gcc target list is great. Love and respect it. Best regards, Pawel Kunio
Re: Can help with task of language frontend cleanup
Hello, Im sorry for posting to wrong group. Wasnt sure. Let me try to explain more clearly. Please forgive my nonnative english. My idea is something like ideally single gcc.exe would be built deployed distributed runtests against per version per some/all frontends. We could think as of whether make frontends as shared objects or compiled statically. Id think id prefer statics for avoiding so mess. You could test all langs tests on single binary amongst other benefits. Also we wouldnt be spawning processes like crazy. Also build process would possibly get simpler less targets and so on. If we stuck with single frontend per binary wed still gain on cleaner interface to langhooks cleaner more consistent basic hooks use calling langhooks statically not through pointer (not sure hiw costly that is) possibly gaining better code locality around frontend inlining many basic hooks and enclosing them into frontend class. As an extra we could get better separation of frontend and middle part. Also adding new frontend would be cleaner process imho. In approach with multiple frontends per binary we could build one gcc and serve many langs possibly optimally building single exe for all langs. I mostly think here of easier testing across frontends. I updated tree processing and i want to check whether i didnt break any frontend on single gcc binary build. In thus approach build process would be simpler and running regressions could be done on single binary. If that still doesnt make any sense or is useless fair enough. I tried. If though multitarget approach would make any sense i could try to think about this approach but id need some help with modifying build process etc. Plus some research on building for all targets at once and so on. On this one im also thinking of avoiding text form of assembly (keeping it as option for debugging but using binary form or calls as default) and running gas internally not as an external process. If any of this makes any sense i can toy with it. Love the project and work you guys are doing. Would like to catch up with clang a bit and sync those two projects. Best regards, Pawel Kunio czw., 25.03.2021, 13:06 użytkownik Jonathan Wakely napisał: > On Thu, 25 Mar 2021 at 09:43, pawel k. via Gcc-help > wrote: > > > > Hello, > > Not sure which list is right. I have ideas for code improvement for gcc. > > Please don't cross-post to gcc@ and gcc-help@, there are almost no > topics relevant to both. You're discussing GCC development, so gcc@ is > the right place. > > > > > Idea1 langhooks cleanup > > > > It basically involves clean up of lang hooks. Closing it in special > class. > > Might help to clean up massive defines etc spurious langhooks > declarations > > amongst others and removing some hooks from hooks.h/c and langhooks.h/c. > > Also in this solution wed gain some cputime by not calling langhooks via > > func pointers. > > > > Idea 1a multiple langhooks in single binary. Choosable in runtime. > > > > Ideally will allow compiling in multiple frontends in single binary and > > choosing in runtime which lang front to use. > > What would be the benefit? > > I can understand the advantage of a single binary that is a > cross-compiler for different targets (but it would be a huge task to > get GCC there). You wouldn't need multiple complete copies of GCC > installed to do cross-compilation if there was a --target option like > Clang's. But what's the benefit to users of a single binary for > different languages? The 'gcc' driver already exists and gives that > functionality, what would change with your proposal? > > > It doesnt seem very difficult just quite laborious. If anyone is > interested > > in such improvement please authorize me to branch off. > > I'm not sure what you mean by this, but you can just create a clone of > the Git repo and host it anywhere you want. >
My 2nd attempt to devel for gcc
Hello, I would like to ask whether there would be interest in the project to be able to build a single binary of gcc where target would be selectable with option flags ie more than one target could be included and aimed for by single binary. If so i could try myself at adding such feature to gcc. It looks ambitious but doable. If so, my another question would be whether no matter configure flags, when for example x86 is selected as target, genned target code is always same. Best regards, Pawel Kunio
Re: My 2nd attempt to devel for gcc
Hmm, Thanks. Not sure I can see answer from him. Ill recheck it. Best regards, Pawel Kunio niedz., 28.03.2021, 01:27 użytkownik Jonathan Wakely napisał: > > > On Sat, 27 Mar 2021, 23:38 pawel k. via Gcc, wrote: > >> Hello, >> I would like to ask whether there would be interest in the project to be >> able to build a single binary of gcc where target would be selectable with >> option flags ie more than one target could be included and aimed for by >> single binary. >> >> If so i could try myself at adding such feature to gcc. It looks ambitious >> but doable. >> > > > See the reply from Jakub. > > > >> If so, my another question would be whether no matter configure flags, >> when >> for example x86 is selected as target, genned target code is always same. >> > > > No, some configure options can affect it, e.g. --with-arch > > >
Re: My 2nd attempt to devel for gcc
Hello, Yea ok got it. Ill reply. I dont get email notifications from him. Ill prepare reply asap as of what we can or cannot do and what will be costs and benefits. Then he/you can decide. Best regards, Pawel niedz., 28.03.2021, 11:34 użytkownik Jonathan Wakely napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., wrote: > >> Hmm, >> Thanks. Not sure I can see answer from him. Ill recheck it. >> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html > > > >
Re: My 2nd attempt to devel for gcc
Hello, Ok fair enough. I thought cleaner separation of FE and generics interface would be useful feature. It would make adding new FE easier too hopefully. We could provide either multiple FEs per binary or not. Additionally, In single FE per binary option of my fegens cleanup scenario we could avoid calling langhooks via pointer and funcs could be statically called. As on data member read from langhooks needing mem access now, we could avoid this too and const data members would be inlined similarly to macro consts generally. But if there is no demand for fe<->generics cleanup its ok. As on your question on avoiding storing bytecode into lto and rereading it, it indeed looks like bit over the top task for me at the moment. I woukd need to researching it more deeply. What i rather meant was compiling in multiple targets and choosing via cmdline opts which one to use. As on Your questions wrt multiple targets, indeed target specific constint macro unrolling would need generally a call and additionally probably indirect one unfirtunately. If the hit on perfirmance is too big here its probably a no go. Unless we just cleanup generics target interface, then target data member reads can be as cheap as constint macro unrolling. As on command line processing, we would probably unfortunately have to make it multipass and opts unresolved in first pass would get checked against registered target opts available in 2nd pass only after targetsel option is found. Id check for availability of all required fkags in last phase where here selected target is already known. Additionally this multitarget scenario might have intermediate "generics target interface cleanup phase" which would help cleaning up this lower interface at first, posibly simplifying target autogen and unifying between constdata reads and calls to a target etc. In this phase data member reads from target will be as cheap as const int macro unrolling too. Here we can also think whether to stop at this phase or to extend it into multitarget feature. Hope all this makes my rationale bit less chaotic. If theres demand on researching and hopefully implementing any of these, please let me know. Best regards, Pawel Kunio niedz., 28.03.2021, 11:34 użytkownik Jonathan Wakely napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., wrote: > >> Hmm, >> Thanks. Not sure I can see answer from him. Ill recheck it. >> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html > > > >
Re: My 2nd attempt to devel for gcc
Hello, Sorry for slight delay. Very happy if i could prepare prototype of this solution. My best guess is if we could hookify all target code everything callable either from frontends or midend, we could try to severly cut this estimate. I also went back to thread you memtioned, i underestimated time for making gcc driver multitarget and likewise for collect binary. What also puzzles me is work on multilib, i still understand multilib clearly enough. In my previous rant i focused mostly on compiler main exec and making it multitarget. We should if this project makes any or some sense think of how configure flags influence codegen of target sources. Im not 100% sure here. If running such project, id focus first on hookifying and possibly wrapping in functions all target genned and callable code. Then id try to make gcc driver multitarget, then same for collect then same for multilib and in the end for gcc main frontend-specific exec ie interface between midend and target and switching configure to gen all code for all targets selected. If still interested and if i should go to clarifying and researching making driver collect multilib multitarget, please let me know. Also if what i say doesnt make much sense, please also let me know. Best regards, Pawel kunio pon., 29.03.2021, 19:25 użytkownik Joseph Myers napisał: > On Sun, 28 Mar 2021, pawel k. via Gcc wrote: > > > Hello, > > I would like to ask whether there would be interest in the project to be > > able to build a single binary of gcc where target would be selectable > with > > option flags ie more than one target could be included and aimed for by > > single binary. > > > > If so i could try myself at adding such feature to gcc. It looks > ambitious > > but doable. > > I've estimated this as taking about two person-years of work (that is, two > person-years of work for someone with extensive experience in GCC > development). > > https://gcc.gnu.org/legacy-ml/gcc-patches/2010-06/msg02675.html > > While there have, for example, been various conversions of target macros > to hooks, and other such similar changes, since then, I don't think > anything fundamentally changes the basic estimate. > > -- > Joseph S. Myers > jos...@codesourcery.com >
On rms controversy
Hello, Im multiyear gcc user on many targets. I love the project and wish it all the best. Im also senior c/cpp and linux sw devel with 20 years of experience. Im observing an rms controversy from some perspective and here are my thoughts: -you didnt base attack on real data but allegations. Additionally falsified ones. -nobody asked rms whether he retracts and indeed he does on some and clarify on others. -part of fsf is rotten by far left mental virus parasite. See gad saads book on the topic. -basically rms didnt do what he was alleged he did. -nobody gave him way to defend like in legal process. -he is back and he should stay. -those who attacked him baselessly and thoughtlessly should disappear in shame and their names should be on gcc and fsf front pages linked shamelist. -rms is heavily autistic as some may know and he might not have perfect judgmental powers over his words. -last but not least all far left snowflakes of you assuming guilt and barring one from defence, please f off and f you for now. -possibly some of you wanted to steal his project so as per above big f off and f you. That would be it. Best regards, Pawel kunio
Re: On rms controversy
Thank You Jonathan for your very valuable opinions. I was sure the more far lefty you are the less you will understand me, if my assumptions about your worldviews are correct. If not apologies. Ill review your previous stance on rms mess and explain. Ill reply with a quote from one of my tee shirts: "Your story has truly touched my heart. Never before have i met a person with as many problems as you. Now [edited] go away and stop bothering me." Aka i value your opinion but instead of critique you say "youre stupid" awaiting for me to say "no, you are stupid" which i wont do as im not as low clown as kindly you. Enough toying with unlogical clown of you as you were kind to call me. Best regards, Kunio Ps i share some trait with rms if that mattered to a clown in a clown show. śr., 14.04.2021, 15:51 użytkownik Jonathan Wakely napisał: > On Wed, 14 Apr 2021 at 13:38, David Malcolm wrote: > > > > On Wed, 2021-04-14 at 08:01 +0100, Jonathan Wakely via Gcc wrote: > > > On Wed, 14 Apr 2021, 07:50 pawel k. via Gcc, wrote: > > > > > > > > > > [...snip...] > > > > > Very logical argument, thanks for sharing. > > > > Jonathan, it's clear to me that you're being sarcastic, but it might > > not be clear to others. Please avoid sarcasm - it amplifies > > misunderstanding on the internet, and it seems to me that that's > > counterproductive when discussing a sensitive topic. > > For the avoidance of doubt, I was being sarcastic. I didn't think it > was a logical argument, I thought it was one of the worst so far in > this whole clownshow. > > > I disagree with much of what Pawel wrote, but this discussion has left > > me feeling drained. I don't have the mental energy to do a point-by- > > point response, and I don't think it would be a productive thing to > > post to this mailing list. > > Which is why I went for sarcasm instead. >
Re: On rms controversy
Ok i might have to retract on some of those i unnevessaily got personal. F course i didnt intend to put not your words into your mouth. As on your politics for sure it matters though as snowflakes got so diverged off into murky partition of world where they no longer understand basic wording and respect most basic values that used to be bipartisan so to say. I hope this one reached the target and rightly so. Read parasitic mind if you wanna get less stupid than me on leftism/rightism spectrum. On this one: sorry but not sorry. Regards, Kunio śr., 14.04.2021, 16:17 użytkownik Jonathan Wakely napisał: > On Wed, 14 Apr 2021 at 15:10, pawel k. wrote: > > > > Thank You Jonathan for your very valuable opinions. I was sure the more > far lefty you are the less you will understand me, if my assumptions about > your worldviews are correct. If not apologies. Ill review your previous > stance on rms mess and explain. > > I'm not sure what my politics have to do with this. > > > > Ill reply with a quote from one of my tee shirts: > > > > "Your story has truly touched my heart. Never before have i met a person > with as many problems as you. Now [edited] go away and stop bothering me." > > > > Aka i value your opinion but instead of critique you say "youre stupid" > > No, I said your email made weak arguments. I did not make any > statement about you personally, only your email. > > > > awaiting for me to say "no, you are stupid" which i wont do as im not as > low clown as kindly you. Enough toying with unlogical clown of you as you > were kind to call me. > > I described the past few weeks as "this whole clownshow". That is also > not a personal statement about you. > > Get offended if you want, but don't put words in my mouth. >
Fsf decision
Hello, I somehow got the feeling the truth and reason have won although there were many odds against them. https://www.fsf.org/news/statement-of-fsf-board-on-election-of-richard-stallman Big thanks and congratulations to fsf board and rms himself. Wonder what wokistanis gonna do now. Wonder whether there will be some action against organizers of open letter with no opt out option a hutzpah plus supporters of initial motion. I honestly hope so. Best regards, Pk
Re: Fsf decision
Hello, Sorry for lags but im across the pond. Thanks for bearing with me. Spot on emphasis. Yes agree with you fully BOTH rms and his opponents should watch the tongues a little more possibly if goodwilled towards fsf to make my point weakest. Albeit the weight of guilt of theirs looks slightly bigger than his imho but i may be biased. Id say if i was to advice if anyone some all half whatever are weak in discussions or get triggered good style would be non discussion of politics like we treat religion. On other hand i dream of and will die fighting fir it albeit out of fsf and gnu etc fir a world where anyone and everyone can sit diwn calmly exchange the ideas learn from each other where can be and close the topic. Although my understanding of reality is reality is not ideal. Cheers, Pk pt., 16.04.2021, 14:54 użytkownik Aaron Gyes napisał: > This is not new, this was what his FSF put out four or five days ago that > that a lot of people found unacceptable. > > Get a load of this, emphasis mine: > > > RMS acknowledges that he has made mistakes. He has sincere regrets, > **especially at how anger toward him personally has negatively impacted the > reputation**and mission of FSF. While *his personal style remains troubling > for some*, a majority of the board feel his behavior has moderated and > believe that **his thinking strengthens the work** of the FSF in pursuit of > its mission. > > Aaron >
