Re: analyzer: implement five new warnings for misuse of POSIX

 > check for double "close" of a FD (CWE-1341).  > check for read/write of a closed file descriptor    These sound good but kinda non general or incomplete to me.  I mean, isn't the "right" thing, to disallow passing  a closed fd to "almost any" function?    But I realize "almost any" is diffic

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 bi

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 whet

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 r

Re: On rms controversy

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 a

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. Addit

Re: My 2nd attempt to devel for gcc

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

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 av

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 20

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

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.

Re: Can help with task of language frontend cleanup

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

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

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

reuse them. -Aditya From: Jakub Jelinek Sent: Monday, March 16, 2020 5:19:16 PM To: Aditya K Cc: Jan Hubicka ; gcc@gcc.gnu.org Subject: Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level On Mon, Mar 16, 2020 at 11:11:14PM +, Aditya K via Gcc

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

> > 2) ipa-split is very simplistic and only splits when there is no value >computed in header of function used in the tail. We should support > adding extra parameters for values computed and do more general SESE >outlining > Note that we do SESE outlining for openMP but this code is

dJqkhS

aXuWtpaAdglWmht JLLghLREjZWVRnjhBGKL