Prev: gcc4.4: f951: warning: command line option "-MM" is valid for C/C++/Java/ObjC/ObjC++ but not for Fortran
Next: Bad dependency relation for "gfortran"
From: Uno on 11 Aug 2010 18:00 steve wrote: > The C standard specifies both the compiler and the C library. > GCC's only concern is the compiler. The developers of glibc > are worried about the library. > > http://gcc.gnu.org/c99status.html > > Note, the only item marked broken for the compiler is > near and dear to your heart. IEC 60559, a.k.a. IEEE 754 floating point. > http://gcc.gnu.org/onlinedocs/ > If I wanted to find the source that goes into glibc, is it in any of the manuals above? I have glibc but no decompiler.:-) -- Uno
From: Nick Maclaren on 11 Aug 2010 18:30 In article <81562ad7-fc56-43e4-90ed-80e10f69290b(a)l25g2000prn.googlegroups.com>, steve <kargls(a)comcast.net> wrote: >> >> I am unconvinced that Linux branding means anything, but let that >> pass. =A0However, gcc is NOT a C99 conforming compiler, though it has >> several C99 features, and the last I heard was that there was no >> intent to make it one. =A0As I said, there is no customer interest. >> That's documented, somewhere. > >The C standard specifies both the compiler and the C library. >GCC's only concern is the compiler. The developers of glibc >are worried about the library. That is a distinction that doesn't make a lot of sense, not least because the boundary between the two in the standard isn't implementable in a conventional compiler/library model. Several of the headers are primarily compiler aspects (e.g. <stdarg.h>, <limits.h>, <float.h>, <fenv.h> and <tgmath.h>). More importantly, it's not a distinction that is acceptable in terms of the standard, except insofar that gcc might be a freestanding system on its own. Yes, I was referring to gcc+glibc, which is what makes sense in terms of C99. >http://gcc.gnu.org/c99status.html Interesting. There clearly has been a change of intent. As I said above, the last I heard - I do not track this lunacy on a regular basis. >Note, the only item marked broken for the compiler is >near and dear to your heart. You have got that spectacularly wrong! I thought that I had made it clear that I regarded the IEEE 754 support as demented. I will try to remember what the issue was where C99 was incompatible with gcc, and there was a definite intent to maintain compatibility at the expense of C99, and check what has happened to it. But it's a long time ago now, and I may not be able to. Regards, Nick Maclaren.
From: steve on 11 Aug 2010 18:24 On Aug 11, 3:00 pm, Uno <merrilljen...(a)q.com> wrote: > steve wrote: > > The C standard specifies both the compiler and the C library. > > GCC's only concern is the compiler. The developers of glibc > > are worried about the library. > > >http://gcc.gnu.org/c99status.html > > > Note, the only item marked broken for the compiler is > > near and dear to your heart. > > IEC 60559, a.k.a. IEEE 754 floating point. > > >http://gcc.gnu.org/onlinedocs/ > > If I wanted to find the source that goes into glibc, is it in any of the > manuals above? > > I have glibc but no decompiler.:-) If I wanted the source to glibc, I would more than likely use my favorite search engine with the profoundly obvious search term 'glibc'. -- steve
From: steve on 11 Aug 2010 18:31 On Aug 11, 3:30 pm, n...(a)gosset.csi.cam.ac.uk (Nick Maclaren) wrote: > In article <81562ad7-fc56-43e4-90ed-80e10f692...(a)l25g2000prn.googlegroups..com>, > > steve <kar...(a)comcast.net> wrote: > > >Note, the only item marked broken for the compiler is > >near and dear to your heart. > > You have got that spectacularly wrong! I thought that I had made > it clear that I regarded the IEEE 754 support as demented. I suppose I should have used a 'smiley' to denote sarcasm. Yes, I'm well aware of your views concerning ieee754. -- steve
From: JB on 12 Aug 2010 02:06
On 2010-08-11, Nick Maclaren <nmm(a)gosset.csi.cam.ac.uk> wrote: > In article <81562ad7-fc56-43e4-90ed-80e10f69290b(a)l25g2000prn.googlegroups.com>, > steve <kargls(a)comcast.net> wrote: >>> >>> I am unconvinced that Linux branding means anything, but let that >>> pass. =A0However, gcc is NOT a C99 conforming compiler, though it has >>> several C99 features, and the last I heard was that there was no >>> intent to make it one. =A0As I said, there is no customer interest. >>> That's documented, somewhere. >> >>The C standard specifies both the compiler and the C library. >>GCC's only concern is the compiler. The developers of glibc >>are worried about the library. > > That is a distinction that doesn't make a lot of sense, not least > because the boundary between the two in the standard isn't > implementable in a conventional compiler/library model. Several > of the headers are primarily compiler aspects (e.g. <stdarg.h>, ><limits.h>, <float.h>, <fenv.h> and <tgmath.h>). > > More importantly, it's not a distinction that is acceptable in > terms of the standard, except insofar that gcc might be a > freestanding system on its own. Yes, I was referring to gcc+glibc, > which is what makes sense in terms of C99. Well, gcc can be used with other C libraries than glibc. glibc is used only on Linux, AFAICT. That being said, you're right, and this split has caused some problems in the past (an obvious one in the context of this discussion being that the level of C99 support is different on targets using different C libraries), and IMHO it would make sense if the C standard library would be part of gcc, and then glibc could be more like some "libposix" are whatever one might call it. But, anyways, that's not how things are done in reality, largely for historical reasons I suppose. > I will try to remember what the issue was where C99 was incompatible > with gcc, and there was a definite intent to maintain compatibility > at the expense of C99, and check what has happened to it. But it's > a long time ago now, and I may not be able to. The only thing I can recall right away is that there was an incompatibility with the C99 "inline" and the GCC extension "inline". IIRC something like the GCC "extern inline" meant the same thing as just "inline" in C99, and vice versa. But, this issue was fixed a few years ago, and GCC nowadays by default follows the C99 semantics. -- JB |