Re: removing toxic emailers
On Thu, 15 Apr 2021 at 21:26, Chris Punches via Gcc wrote: > > What I see here in sum is another high level tightly integrated Red Hat > employee saying the gist of "I'm really not saying it out of my > employer's interest and it has nothing to do with my personal > feelings". > > 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 it here, then? > > I just don't buy it. Please say anything that would not support the > emerging theory that these companies are using integrated employees to > try to emulate justification/pretext for a rift to attack the free > software world. Anything at all. > One reason you might be seeing this is people who (a) are not paid to work on GCC, and (b) found RMS and parts of the GNU community unpleasant to work with, left years ago. Chris
Re: removing toxic emailers
On Wed, 14 Apr 2021 at 21:40, 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 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 with some of the comments that have been made I > > don't think they've risen to the level of wanting/needing to ban those > > individuals from posting. > > I think it's useful to observe that there are a reasonable number of > people who will refuse to participate in a project in which the > mailing list has regular personal attacks and other kinds of abusive > behavior. I know this because I've spoken with such people myself. > They simply say "that project is not for me" and move on. > As a single data point, I used to contribute somewhat to gcc (libstdc++ specifically) -- I did a bunch of work implementing bits of TR1 and C++03. I found the "GCC community" an unpleasant place to be (there were many nice individual nice people), and didn't enjoy being involved. I just moved on to work on several other, open-source non-GNU projects, which I have been happily contributing to for the last 10 years or so. Chris Jefferson
Re: inline-unit-growth trouble
Mike Stump wrote: On Friday, April 15, 2005, at 11:50 AM, Christopher Jefferson wrote: Is it really the job of the linker to choose between different implementations of a function? Yes. Why do you ask? Because I'm not an expert on linkers :) It seems to me that this might lead to very, very difficult to track down bugs Nope. All those bugs are trivial to track down, as once you find the translation unit that contained the compiled code with something called a debugger, OK, it was a silly question, but was it necessary to be that insulting? you submit the -E for it and that flags used to compile it, and because the compiler is deterministic, all such bugs are trivial to track down. I was more thinking a situation like: 1) I write slightly buggy file A, which generates some some function in .gnu.linkonce from a library function. I also have good file B (assume A and B have no real connection), which generates the same library function. My program works. 2) I edit and recompile file B which causes some different inlining to occur in the functions in .gnu.linkonce. B's copy of the library function gets chosen, and this happens to break functions in file A. I assume however the bug has to be in file B, as thats what I just changed, and it has no connection to file A I know of. Of course it's been pointed out that of course exactly the same problem occurs if you compile different files at different optimisation levels, so it's unavoidable anywhere perhaps... Chris
Re: inline-unit-growth trouble
Richard Guenther wrote: On 4/15/05, Andreas Krebbel <[EMAIL PROTECTED]> wrote: Hi, on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. The sizes differ due to different inlining decisions. The problem is that inlining maybe prevented by global limits which maybe exceeded for one file but not for the other. The actual problem occurred with the "inline-unit-growth" limit which may prevent inlining for a function in one file and allow it for the same function in another. I'm not sure how to fix that issue. To my mind the whole concept of per unit limits influencing local inlining decisions seems a bit questionable. Why does the linker not just pick either of the functions? The size difference should not matter. Is it really the job of the linker to choose between different implementations of a function? It seems to me that this might lead to very, very difficult to track down bugs
