Re: __builtin_cpow((0,0),(0,0))
On Tue, 8 Mar 2005 03:24:35 +0100, Marcin Dalecki <[EMAIL PROTECTED]> wrote: > > On 2005-03-08, at 02:55, Ronny Peine wrote: > > > Maybe i found something: > > > > http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps > > page 9 says: > > Lot's of opinions few hard arguments... I see there. > I wouldn't consider the above mentioned paper authoritative in any way. I guess just because someone wrote _the_ standard programs for testing the quality of floating point support in C and Fortran, and has got a ACM Turing Award for: "For his fundamental contributions to numerical analysis. One of the foremost experts on floating-point computations. Kahan has dedicated himself to 'making the world safe for numerical computations.'" doesn't mean you should actually pay attention to anything they have to say on the subject.
Re: __builtin_cpow((0,0),(0,0))
On Tue, 8 Mar 2005 04:18:44 +0100, Marcin Dalecki <[EMAIL PROTECTED]> wrote: > Are we a bit too obedient today? Look I was talking about the paper > presented > above not about the author there of. Since we're getting personal, you've been terse, hostile and dismissive this entire thread, and it hasn't been helpful. It'd help if you canned the attitude. The author's opinion comes from experience in the field. When someone with a lot of experience talks, wise people listen, if they don't agree in the end. I see no reason to casually dismiss that article.
Decimal Floating-Point
The Wiki only mentions the C front-end. Is this going to require any back-end changes? Is there going to be any work done to make this work well with Ada (which already has decimal floating point), to make decimal floating-point values be passable between C and Ada functions?
Re: fatal error: gnu/stubs-32.h: No such file
I'd like to mention that I too was bit by this one on Debian. I don't have a 32-bit development environment installed; why would I? I'm building primarily for myself, and if I did have to target a 32-bit environment, I'd likely have to mess with more stuff then just the compiler. If you can't find a way to detect this error, I can't imagine many people would have a problem with turning off multilibs on x86-64; it's something of a minority setup. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Wed, Jul 24, 2013 at 1:17 AM, Andrew Haley wrote: > On 07/24/2013 01:48 AM, David Starner wrote: >> I'd like to mention that I too was bit by this one on Debian. I don't >> have a 32-bit development environment installed; why would I? I'm >> building primarily for myself, and if I did have to target a 32-bit >> environment, I'd likely have to mess with more stuff then just the >> compiler. > > No, you probably wouldn't. Just use -m32 and you'd be fine. That's assuming that the hypothetical 32-bit x86 system I was targeting was running GNU libc6 2.17 (as well as whatever libraries I need, with version numbers apropos of Debian Unstable.) Conceivable, but not something I'd bet on. I've got 3 ARM (Android) computers around, and 3 AMD-64 computers, and I can't imagine why I'd need an x86 computer. There is one x86 program I run (zsnes), but if Debian stopped carrying it, it probably wouldn't be worth the time to compile it myself. >> If you can't find a way to detect this error, I can't >> imagine many people would have a problem with turning off multilibs on >> x86-64; it's something of a minority setup. > > I don't think it is, really. Really? Because my impression is that on Unix, the primary use of the C compiler has always been to compile programs for the system the compiler is running on. And x86-32 is a slow, largely obsolete chip; it's certainly useful to emulate, but I suspect any developer who needs to build for it knows that up-front and is prepared to deal for it in the same way that someone who needs an ARM or MIPS compiler is. > Anyone building GCC for themself has a reason for doing so. At the current time, Debian's version of GNAT is built from older sources then the rest of GCC; if I want a 4.8 version of GNAT, I have to build it myself. > Right, so it should be built the right way. The right way? If I don't want to build support for obsolete systems I don't use, I'm building it the wrong way? If I were building ia64-linux-gnu, I wouldn't have to enable support for x86-linux-gnu, but because I'm building amd64-linux-gnu, if I don't, I'm building it the wrong way? I don't see this resistance to making it work with real systems and real workloads. This feature is not useful to many of us, and fails the GCC build in the middle. That's not really acceptable. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Wed, Jul 24, 2013 at 4:14 AM, Andrew Haley wrote: > I would just install GCC's build dependencies and build with the > defaults. I'm glad you have infinite hard-drive space. I rather wish fewer developers did, as well as those infinitely fast computers they seem to have; perhaps they would have more empathy with my day-to-day computing needs. > There is no resistance whatsoever to making it work with real systems > and real workloads. Yes, there is. Both in this thread, and on bugzilla, people with real systems, in my case a well-stocked development system, have said they started compiling gcc and after hours the compile has failed without even an explanation, and people have shrugged, and said what do you want us to do about it? If a feature causes failure on real systems like that, then disabling it by default, even if it's used by a significant minority of users, should be considered. Yes, it would be better to leave multilibs on and give people building without 32-bit libraries a proper error message up front, but leaving it as is is not making it work with real systems; it's causing real people to pull their hair out or give up on trying to build GCC. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley wrote: > Not at all: we're just disagreeing about what a real system with > a real workload looks like. No, we aren't. We're disagreeing about whether it's acceptable to enable a feature by default that breaks the compiler build half way through with an obscure error message. Real systems need features that aren't enabled by default sometimes. > It's a stupid thing to say anyway, because > who is to say their system is more real than mine or yours? By that logic, you've already said that any system needing GNAT is less real then others, because it's not enabled by default. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Thu, Jul 25, 2013 at 1:17 AM, Andrew Haley wrote: > On 07/24/2013 11:51 PM, David Starner wrote: >> On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley wrote: >>> Not at all: we're just disagreeing about what a real system with >>> a real workload looks like. >> >> No, we aren't. We're disagreeing about whether it's acceptable to >> enable a feature by default that breaks the compiler build half way >> through with an obscure error message. > > No we aren't. I want that error message fixed too. A configure- > time warning would be good. The obscurity of the error message is only part of the problem; the fact that it errors out halfway through a multi-hour build is also an issue. The question is if it can't detect a compile time that this will fail, should GCC disable multilibs? -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Fri, Jul 26, 2013 at 2:01 AM, Andrew Haley wrote: > GCC can detect at configure time that it will fail. It is clearly > a computable problem. It's a matter of someone doing it rather than > insisting that the world should change to suit them. GCC 4.8.1 will fail to compile on x86_64-unknown-linux-gnu that has all the programs that Prerequisites in the Installation instructions lists. That I install some random package not needed to build C programs is not listed as a prerequisite in the documentation. I don't regard objecting to that is a matter of the world should change to suit me, rather as GCC not compiling on a system that it lists as a primary platform and is one of the most common targets for it. (It, BTW, does not suffice to add --disable-multilibs.) -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Sat, Jul 27, 2013 at 12:23 PM, Jonathan Wakely wrote: > It's not "some random package" it's the C library, and it is needed to > compile 32-bit C programs. It's not libc6. It's not even libc6-dev. It's libc6-dev-i386. Debian Popularity Contest says that 84315 out of 147631 are AMD64; 99980 systems out of 147631 have libc6-dev installed; and yet only 7712 (presumably all AMD64) have libc6-dev-i386 installed (+740 with the obsolete ia32-libs-dev). Any way I cut it, most people who have the C library development package on AMD64 installed don't have the libc6-dev-i386 package installed. > If the > latter, did you try spelling it correctly, --disable-multilib > (singular)? I'm sorry, I didn't realize I was misspelling it. Again, failing with some random bug in the middle of compilation is not generally a sign of that type of error. > In any case, the point stands: someone needs to do the work, insisting > on it being done doesn't do it. That's not the point. I can send you a patch pretty quickly that changes the default on AMD64 from --enable-multilib to --disable-multilib. I've been told it's impossible to fix it any other way, and saying "It is clearly a computable problem" is quite a distance from saying "oh, we can fix this". If you can fix this without changing the default, that's great, but nobody has even said that's a solvable problem, except in the theoretical sense. I don't care how it's fixed, but if you want me to do it, I'm going to make the simple configuration fix instead of the possibly intractable library detect patch. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote: > On 07/29/2013 02:55 PM, Bruce Korb wrote: >> On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote: >> >>> There should be a better diagnostic. >> >> If you remember, the start of this thread was: >> >>> Why is it that configure worked but stubs-32.h was not found? >> >> That is the correct thing to do. The reply, basically, was: >> >> It's too hard. > > It was "This is possible, but it's tricky, and it's really important > to get it right. We don't want a half-arsed patch." > But we know people are running into this issue and reporting it. >>> Yes. But that on its own is not sufficient to change the default >> >> That's a pretty obnoxious comment. > > Oh dear. > >> I translate it as, "I don't care if people are having trouble. > > That's a mistranslation. It means that there are other criteria > beyond some people having trouble. Such as, we really want multilibs > to be built. > >> It is a nuisance to me to do that and anyone building GCC should >> already know they need -devel for 32 bits." I guess >> I can be obnoxious, too. But slightly more politely put: >> >>> No, we aren't. We're disagreeing about whether it's acceptable to >>> enable a feature by default that breaks the compiler build half way >>> through with an obscure error message. Real systems need features that >>> aren't enabled by default sometimes. >> >> The fundamental issue, to me, is: What do you do when you cannot >> proceed? >> >> I think you should detect the issue as *soon as practical* and then >> *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. > > Yes! Yes! Yes! > > Andrew. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
Sorry about the blank message; I accidentally hit the wrong button. On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote: > It was "This is possible, but it's tricky, and it's really important > to get it right. We don't want a half-arsed patch." We've all seen cases where a quick patch is rejected in favor of a hypothetical patch, and years down the road, the program still has the problem. The people who blocked the quick patch, naturally, never bothered trying to write the patch they wanted. > That's a mistranslation. It means that there are other criteria > beyond some people having trouble. Such as, we really want multilibs > to be built. Who is we here? And why do you really want multilibs built? >> I think you should detect the issue as *soon as practical* and then >> *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. > > Yes! Yes! Yes! Then what are we going to do about it? As per my first comment, nobody has offered to produce a patch in the form you would be happy with, so I'm not going to hold my breath that it's going to appear. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Tue, Jul 30, 2013 at 12:56 AM, Andrew Haley wrote: > "We" is the GCC community. "We" really want multilibs to be built so > they get tested as much as possible. It's in the best interest of > all GCC users that this happens. "We" really want Ada to be built so that it gets tested as much as possible. "We" really want ARM to be built so that it gets tested as much as possible. I don't see the distinction. Those who need multilibs support should be responsible for making sure that it works right. Presumably enough people do need it. Those that don't should have to shoulder the burden for those who do. > So don't write one. Then you're likely to be proved right. So what you're saying is that "we" don't care if people can easily build "our" compiler. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 29, 2013 at 9:58 PM, Andrew Pinski wrote: > On Mon, Jul 29, 2013 at 9:50 PM, David Starner wrote: >> We've all seen cases where a quick patch is rejected in favor of a >> hypothetical patch, and years down the road, the program still has the >> problem. The people who blocked the quick patch, naturally, never >> bothered trying to write the patch they wanted. > > The problem here is a quick patch makes the situation worse rather > than better. That is the reason why the quick patch is rejected. If it were replaced with a better one, that wouldn't be a problem. > The defaults are there for the > majority of users That remains to be seen. As I said, a substantial majority of Debian users on AMD64 who can compile C programs can't compile for 32 bits. > and majority of users of compiling a compiler knows > the risks of not having the current libraries installed. The "current" libraries? Currency has nothing to do with it. The libc development files for a 32-bit system, which are normally not needed for compiling on a pure 64-bit system. In any case, a couple normal developers on this list have said that has bit them. > That is because it is a hard to do and will force extra time in > compiling and might cause incorrect handling of cross builds. > Remember the host compiler does not have to compile for the multi-lib; > only the newly compiled compiler will be able to. Which goes straight to my first point. There is a build-time bug in GCC that will bite many Linux AMD64 users who might be interesting in trying to build a new version of GCC. It apparently will be there for many years. Certainly this reduces any inclination I might have had of actually trying to figure out GCC's build system and find a patch, as Andrew Haley suggests. -- Kie ekzistas vivo, ekzistas espero.
Re: On US corporate influence over Free Software and the GCC Steering Committee
Giacomo Tesio wrote: > And while this is IBM, the other US corporations with affiliations in the Steering Committee are no better: https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html > I can understand that some of you consider working for such corporations "a > joy". > But for the rest of us, and to most people outside the US, their influence over the leadership of GCC is a threat. > Please, do not create a hostile environment for indipendent contributors. What do you mean by independent? If you're independently wealthy and don't need to work, you can avoid this. If you're a cashier or field laborer or in some other poorly paid job, then your employer probably doesn't care. Otherwise, if you work for a company that produces software, even just internally, or for a university, or a company where your name might be associated with the company, then your employer may demand that you cease publicly working on Free Software. I find it a bit hypocritical; there's no objection to the fact that GCC was developed using stuff bought with funds donated by these companies, their creators and their employees, to MIT, including people like Jeffery Epstein, one of the Koch brothers, and Bill Gates. But how dare IBM hire people to work on GCC! We need to preserve our independence! -- The standard is written in English . If you have trouble understanding a particular section, read it again and again and again . . . Sit up straight. Eat your vegetables. Do not mumble. -- _Pascal_, ISO 7185 (1991)
Re: [Request for Comments] Using Rust libraries in the Rust frontend
On Fri, Jan 26, 2024 at 3:40 PM NightStrike via Gcc wrote: > > On Thu, Jan 25, 2024, 11:27 Iain Sandoe wrote: > > > E.g. with Ada it is possible to port to a new platform by first building a > > cross-compiler and then to use that cross-compiler to build a “native > > cross” (build != host == target) to provide an initial compiler on the > > target platform. > > > > And that Ada solution is awful for nontraditional systems. Ditto for D. Why? And what solution would you suggest for compilers written in part in their own languages? How do you get the first C compiler on the platform without building a cross-compiler? -- The standard is written in English . If you have trouble understanding a particular section, read it again and again and again . . . Sit up straight. Eat your vegetables. Do not mumble. -- _Pascal_, ISO 7185 (1991)
