* Need someone to look at a regression @ 1998-08-13 23:20 Jeffrey A Law 1998-08-14 3:44 ` Andreas Schwab 1998-08-14 16:55 ` Carlo Wood 0 siblings, 2 replies; 17+ messages in thread From: Jeffrey A Law @ 1998-08-13 23:20 UTC (permalink / raw) To: egcs gcc.dg/980626-1.c is consistently showing up as a regression when comparing the egcs-1.1 against egcs-1.0.3a and gcc-2.8.1. This is a test for a bogus warning. Can someone look into why egcs-1.1 is behaving differently for this test? Compile with -Wimplicit-int. gcc-2.8.1 and egcs-1.0.3 will probably not issue any warnings (which is the correct behavior IMHO). egcs-1.1 will issue a bogus warning. Thanks! int main() { typedef SFtype __attribute__ ((mode (SF))); typedef DFtype __attribute__ ((mode (DF))); typedef HItype __attribute__ ((mode (HI))); typedef SItype __attribute__ ((mode (SI))); typedef DItype __attribute__ ((mode (DI))); typedef UHItype __attribute__ ((mode (HI))); typedef USItype __attribute__ ((mode (SI))); typedef UDItype __attribute__ ((mode (DI))); return 0; } ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-13 23:20 Need someone to look at a regression Jeffrey A Law @ 1998-08-14 3:44 ` Andreas Schwab 1998-08-14 8:28 ` Jeffrey A Law [not found] ` <899.903108402.cygnus.egcs@hurl.cygnus.com> 1998-08-14 16:55 ` Carlo Wood 1 sibling, 2 replies; 17+ messages in thread From: Andreas Schwab @ 1998-08-14 3:44 UTC (permalink / raw) To: law; +Cc: egcs Jeffrey A Law <law@cygnus.com> writes: |> gcc.dg/980626-1.c is consistently showing up as a regression when |> comparing the egcs-1.1 against egcs-1.0.3a and gcc-2.8.1. |> |> This is a test for a bogus warning. |> |> Can someone look into why egcs-1.1 is behaving differently for this |> test? Compile with -Wimplicit-int. |> |> gcc-2.8.1 and egcs-1.0.3 will probably not issue any warnings (which |> is the correct behavior IMHO). egcs-1.1 will issue a bogus warning. |> |> Thanks! |> |> |> int main() |> { |> typedef SFtype __attribute__ ((mode (SF))); |> typedef DFtype __attribute__ ((mode (DF))); |> typedef HItype __attribute__ ((mode (HI))); |> typedef SItype __attribute__ ((mode (SI))); |> typedef DItype __attribute__ ((mode (DI))); |> typedef UHItype __attribute__ ((mode (HI))); |> typedef USItype __attribute__ ((mode (SI))); |> typedef UDItype __attribute__ ((mode (DI))); |> return 0; |> } I can't check it out currently, but egcs-1.1 is correct if it warns about implicit int. Use `typedef int SFtype __attribute__ ((mode (SF)))' instead. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-14 3:44 ` Andreas Schwab @ 1998-08-14 8:28 ` Jeffrey A Law [not found] ` <899.903108402.cygnus.egcs@hurl.cygnus.com> 1 sibling, 0 replies; 17+ messages in thread From: Jeffrey A Law @ 1998-08-14 8:28 UTC (permalink / raw) To: Andreas Schwab; +Cc: egcs In message < vyz1zqjhmgj.fsf@issan.informatik.uni-dortmund.de >you write: > I can't check it out currently, but egcs-1.1 is correct if it warns about > implicit int. Use `typedef int SFtype __attribute__ ((mode (SF)))' > instead. I think the warning is wrong. Given: typedef SFtype __attribute__ ((mode (SF))); We have an explicit type (SFmode), why in the hell would we ever want/need typedef int ....? eff ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <899.903108402.cygnus.egcs@hurl.cygnus.com>]
* Re: Need someone to look at a regression [not found] ` <899.903108402.cygnus.egcs@hurl.cygnus.com> @ 1998-08-15 0:17 ` Ulrich Drepper 1998-08-15 21:09 ` Jeffrey A Law [not found] ` <5044.903227080.cygnus.egcs@hurl.cygnus.com> 0 siblings, 2 replies; 17+ messages in thread From: Ulrich Drepper @ 1998-08-15 0:17 UTC (permalink / raw) To: egcs law@cygnus.com (Jeffrey A Law) writes: > typedef SFtype __attribute__ ((mode (SF))); > > We have an explicit type (SFmode), why in the hell would we ever > want/need typedef int ....? Isn't it that the __attribute__ stuff is, well, an attribute and it should be possible to drop it? Then yu would get typedef SFtype; which clearly is wrong. You simply cannot leave out the base type. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-15 0:17 ` Ulrich Drepper @ 1998-08-15 21:09 ` Jeffrey A Law 1998-08-16 8:18 ` Carlo Wood 1998-08-17 19:53 ` Kamil Iskra [not found] ` <5044.903227080.cygnus.egcs@hurl.cygnus.com> 1 sibling, 2 replies; 17+ messages in thread From: Jeffrey A Law @ 1998-08-15 21:09 UTC (permalink / raw) To: Ulrich Drepper; +Cc: egcs In message < r2ww8bx9uq.fsf@happy.cygnus.com >you write: > law@cygnus.com (Jeffrey A Law) writes: > > > typedef SFtype __attribute__ ((mode (SF))); > > > > We have an explicit type (SFmode), why in the hell would we ever > > want/need typedef int ....? > > Isn't it that the __attribute__ stuff is, well, an attribute and it > should be possible to drop it? Then yu would get > > typedef SFtype; > > which clearly is wrong. You simply cannot leave out the base type. I don't see that the "int" is a base type in this case. How can you have an integer base type for a floating point mode? This is one of those areas where someone familiar with language design should have been involved in specifying exactly what is supposed to happen. My simplistic viewpoint is typedef int SFtype __attribute__ ((mode (SF))); Is bogus -- the type is actually specified by the attribute and the "int" is neither used nor wanted. Frankly, I don't really care about this problem all that much, we're talking about a possible bogus warning. The only reason this came up at all is because libgcc2.c uses attributes like that and egcs complained about the implicit int. IMHO a case of warning elimination going too far. I'm more than willing to go with whatever group decision we come up with on this one. If we decide the int is needed, then the testcase is bogus. If the int is not needed, then the testcase is valid and we've got a bug in the compiler (since it shouldn't have given the warning). jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-15 21:09 ` Jeffrey A Law @ 1998-08-16 8:18 ` Carlo Wood 1998-08-16 20:59 ` Jeffrey A Law 1998-08-17 19:53 ` Kamil Iskra 1 sibling, 1 reply; 17+ messages in thread From: Carlo Wood @ 1998-08-16 8:18 UTC (permalink / raw) To: law; +Cc: egcs | I'm more than willing to go with whatever group decision we come up | with on this one. If we decide the int is needed, then the testcase | is bogus. If the int is not needed, then the testcase is valid and | we've got a bug in the compiler (since it shouldn't have given the | warning). | | jeff I think there are two possibilities: 1) The use of a mode() makes this code only ever make sense when compiled with gcc. Then suppression of the warning would be the best because when the warning is not suppressed people will add 'int' and then no warning will occur when compiling the code with another compiler which uses: #define __attribute__ 2) It *does* make sense to compile code like this with other compilers (ie, using "#define __attribute__" somewhere). In that case you want a 'backup' type to be added that will be used when the __attribute__ is #defined away. We need a NEW warning then however, when the overridden type doesn't match the mode() somehow. I am not sure if that is possible since I don't know the mode() types :/ But, for example, I can imagine that we'd like to have a warning when with typedef int XXtype __attribute__ ((mode (XX))); sizeof(XXtype) != sizeof(int). -- Carlo Wood <carlo@runaway.xs4all.nl> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-16 8:18 ` Carlo Wood @ 1998-08-16 20:59 ` Jeffrey A Law 0 siblings, 0 replies; 17+ messages in thread From: Jeffrey A Law @ 1998-08-16 20:59 UTC (permalink / raw) To: Carlo Wood; +Cc: egcs In message < 199808161324.PAA10943@jolan.ppro >you write: > 1) The use of a mode() makes this code only ever make sense when > compiled with gcc. The whole construct only makes sense when compiled with gcc. It should (IMHO) give an error instead of trying to do the right thing if you're not compiling with gcc. Why? If you try to "fake it", odds are you're not going to get it right consistently and you'll end up silently generating incorrect code. IMHO, it's better to get a compile time error in this case. > Then suppression of the warning would be the best because when > the warning is not suppressed people will add 'int' and then > no warning will occur when compiling the code with another > compiler which uses: > #define __attribute__ Right. > 2) It *does* make sense to compile code like this with other > compilers (ie, using "#define __attribute__" somewhere). > > In that case you want a 'backup' type to be added that will > be used when the __attribute__ is #defined away. > We need a NEW warning then however, when the overridden > type doesn't match the mode() somehow. I am not sure if > that is possible since I don't know the mode() types :/ Many of the attributes make no sense when building with other compilers; I think the mode attribute is one of them. I don't see how to get the additional warning since the size of the C data types is implementation specific, whereas the size of most modes is fixed. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-15 21:09 ` Jeffrey A Law 1998-08-16 8:18 ` Carlo Wood @ 1998-08-17 19:53 ` Kamil Iskra 1998-08-17 17:41 ` Jeffrey A Law 1 sibling, 1 reply; 17+ messages in thread From: Kamil Iskra @ 1998-08-17 19:53 UTC (permalink / raw) To: Jeffrey A Law; +Cc: egcs On Sat, 15 Aug 1998, Jeffrey A Law wrote: > My simplistic viewpoint is > > typedef int SFtype __attribute__ ((mode (SF))); > > > Is bogus -- the type is actually specified by the attribute and the > "int" is neither used nor wanted. Definitely "int" and "__attribute__ ((mode (SF)))" on the same typedef clash. However, "float" and "__attribute__ ((mode (SF)))" certainly do not. IMHO, saying that: typedef SFtype __attribute__ ((mode (SF))); gives all the type information it needs is wrong. Sure, in case of floating type there is no much else you can do with it apart from storing a floating pointer number, but compare it with: typedef SItype __attribute__ ((mode (SI))); Now, what do I want? An integer? A pointer? Or perhaps a 4-byte structure? GCC will use SImode for all of them on my machine. Modes provide only a subset of information than types do. Just compare the mode-based alias analysis vs. the type-based one. Therefore, I think that GCC should warn when the mode has been specified, but the type has not. Such a new type is simply incomplete. / Kamil Iskra AmigaOS Linux/i386 Linux/m68k \ | GeekGadgets GCC maintainer UNIX system administrator | | iskra@student.uci.agh.edu.pl kiskra@ernie.icslab.agh.edu.pl | \ kamil@dwd.interkom.pl http://student.uci.agh.edu.pl/~iskra / ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-17 19:53 ` Kamil Iskra @ 1998-08-17 17:41 ` Jeffrey A Law 1998-08-19 19:04 ` Ken Raeburn 0 siblings, 1 reply; 17+ messages in thread From: Jeffrey A Law @ 1998-08-17 17:41 UTC (permalink / raw) To: Kamil Iskra; +Cc: egcs In message < Pine.LNX.3.95.980817115257.25384E-100000@plum.dwd.interkom.pl >you write: > > Definitely "int" and "__attribute__ ((mode (SF)))" on the same typedef > clash. > > However, "float" and "__attribute__ ((mode (SF)))" certainly do not. Yes, float and SFmode clash since there is no guarantee that a float has the same size as SFmode. > Now, what do I want? An integer? A pointer? Or perhaps a 4-byte > structure? GCC will use SImode for all of them on my machine. Right. Once you get past the front-end, types are not preserved. You just have mode and size. And this is precisely what the attributes are supposed to provide. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-17 17:41 ` Jeffrey A Law @ 1998-08-19 19:04 ` Ken Raeburn 1998-08-21 19:47 ` Jeffrey A Law 0 siblings, 1 reply; 17+ messages in thread From: Ken Raeburn @ 1998-08-19 19:04 UTC (permalink / raw) To: egcs Jeffrey A Law <law@cygnus.com> writes: > In message < Pine.LNX.3.95.980817115257.25384E-100000@plum.dwd.interkom.pl >you write: > > > > Definitely "int" and "__attribute__ ((mode (SF)))" on the same typedef > > clash. > > > > However, "float" and "__attribute__ ((mode (SF)))" certainly do not. > Yes, float and SFmode clash since there is no guarantee that a float > has the same size as SFmode. I'm inclined to think of it as the type sort of describing the general class of types to be used (FP, int, pointer, complex types), with the mode specifying exactly how big it is. (Though how you'd use pointers of strange sizes, I'm not sure.) Or, to look at it another way, the attributes modify the type described in some ways (size, alignment, internal padding), and produce an error if the modification is invalid (requires different class of base type, making pointer too small). But that's very different from the implementation. The mode-attribute implementation is more like a __typeof__ kind of thing, which given some input, produces a type that you use as is. You don't specify the mode for *your* type; you specify a mode and signedness, and the compiler hands you the type it has decided you will use. IMHO such a thing should fit in syntactically like __typeof__ does, not like an attribute. Maybe "typedef __type_for_mode__ (SF) foo;"... > > Now, what do I want? An integer? A pointer? Or perhaps a 4-byte > > structure? GCC will use SImode for all of them on my machine. > Right. Once you get past the front-end, types are not preserved. You > just have mode and size. And this is precisely what the attributes > are supposed to provide. The mode does not indicate signedness. While this is not an issue for floating point types (you can specify it, but it's ignored), it does indicate that the mode alone is not always sufficient. Here's a random thought: What if someone writes support for fixed-point variables and arithmetic? At least for machines without special support, I'd expect the implementation to use the usual integer modes, with some special front-end type info indicating that some of the HLL arithmetic ops need to be expanded differently. In that case, I could imagine using typedef __fixed(1) int halfstep __attribute__((mode (DI))); where again the type info would be required to give the correct semantics. I'll also note that qualifiers appear to get discarded when the mode attribute is used. So typedef const int foo __attribute__((mode(SI))); results in "foo" type variables going into read-write storage, when they go into read-only storage when the attribute is omitted. And typedef const __complex__ unsigned long long foo __attribute__((mode(SF))); is silently made equivalent to typedef float foo; This too is contrary to how I'd expect such an attribute to work, if I hadn't looked at the implementation. (Actually, this result seems pretty ridiculous to me.) Also, a minor issue, type_for_mode seems completely unaware of any complex modes. And it has support for char* and int* having different modes, though I don't see how that can arise. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-19 19:04 ` Ken Raeburn @ 1998-08-21 19:47 ` Jeffrey A Law 0 siblings, 0 replies; 17+ messages in thread From: Jeffrey A Law @ 1998-08-21 19:47 UTC (permalink / raw) To: Ken Raeburn; +Cc: egcs In message < tx1d89wz9wp.fsf@cygnus.com >you write: > Jeffrey A Law <law@cygnus.com> writes: > > > In message <Pine.LNX.3.95.980817115257.25384E-100000@plum.dwd.interkom. > pl>you write: > > > > > > Definitely "int" and "__attribute__ ((mode (SF)))" on the same typede > f > > > clash. > > > > > > However, "float" and "__attribute__ ((mode (SF)))" certainly do not. > > Yes, float and SFmode clash since there is no guarantee that a float > > has the same size as SFmode. > > I'm inclined to think of it as the type sort of describing the general > class of types to be used (FP, int, pointer, complex types), with the > mode specifying exactly how big it is. So, after all the other issues you raised, what do you think we should do in this specific case? ie, do we keep the warning or is the warning bogus. That's what I really want opinions on right now. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <5044.903227080.cygnus.egcs@hurl.cygnus.com>]
* Re: Need someone to look at a regression [not found] ` <5044.903227080.cygnus.egcs@hurl.cygnus.com> @ 1998-08-17 19:53 ` Jason Merrill 1998-08-18 2:31 ` Richard Earnshaw 0 siblings, 1 reply; 17+ messages in thread From: Jason Merrill @ 1998-08-17 19:53 UTC (permalink / raw) To: egcs >>>>> Jeffrey A Law <law@cygnus.com> writes: > In message < r2ww8bx9uq.fsf@happy.cygnus.com >you write: >> law@cygnus.com (Jeffrey A Law) writes: >> >> > typedef SFtype __attribute__ ((mode (SF))); >> > >> > We have an explicit type (SFmode), why in the hell would we ever >> > want/need typedef int ....? >> >> Isn't it that the __attribute__ stuff is, well, an attribute and it >> should be possible to drop it? Then yu would get >> >> typedef SFtype; >> >> which clearly is wrong. You simply cannot leave out the base type. > I don't see that the "int" is a base type in this case. How can you > have an integer base type for a floating point mode? In C, typedef SFtype; is equivalent to typedef int SFtype; by the implicit int rule. In C++ and C9X, there is no such rule, so the above is ill-formed. Jason ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-17 19:53 ` Jason Merrill @ 1998-08-18 2:31 ` Richard Earnshaw 1998-08-18 12:42 ` Joern Rennecke 0 siblings, 1 reply; 17+ messages in thread From: Richard Earnshaw @ 1998-08-18 2:31 UTC (permalink / raw) To: Jason Merrill; +Cc: rearnsha > >>>>> Jeffrey A Law <law@cygnus.com> writes: > > > In message < r2ww8bx9uq.fsf@happy.cygnus.com >you write: > >> law@cygnus.com (Jeffrey A Law) writes: > >> > >> > typedef SFtype __attribute__ ((mode (SF))); > >> > > >> > We have an explicit type (SFmode), why in the hell would we ever > >> > want/need typedef int ....? > >> > >> Isn't it that the __attribute__ stuff is, well, an attribute and it > >> should be possible to drop it? Then yu would get > >> > >> typedef SFtype; > >> > >> which clearly is wrong. You simply cannot leave out the base type. > > > I don't see that the "int" is a base type in this case. How can you > > have an integer base type for a floating point mode? > > In C, > > typedef SFtype; > > is equivalent to > > typedef int SFtype; > > by the implicit int rule. In C++ and C9X, there is no such rule, so the > above is ill-formed. > It's a pity that the code below doesn't work. typedef struct { unsigned x, y; } foo __attribute__((mode (DF))); foo bar() { foo x; x.x = 0; x.y = 0; return x; } test.c: In function `bar': test.c:9: request for member `x' in something not a structure or union test.c:10: request for member `y' in something not a structure or union This would be an extremely useful way of breaking down a floating point number into its component bit-fields, without having to mess around with a union. It would certainly solve a problem I have at the moment, especially if the struct were passed to and from calls in the same way as a DFmode type. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-18 2:31 ` Richard Earnshaw @ 1998-08-18 12:42 ` Joern Rennecke 1998-08-18 21:50 ` Jeffrey A Law 0 siblings, 1 reply; 17+ messages in thread From: Joern Rennecke @ 1998-08-18 12:42 UTC (permalink / raw) To: richard.earnshaw; +Cc: jason, egcs, rearnsha > It's a pity that the code below doesn't work. > > typedef struct > { > unsigned x, y; > } foo __attribute__((mode (DF))); > > foo bar() > { > foo x; > x.x = 0; > x.y = 0; > return x; > } > > test.c: In function `bar': > test.c:9: request for member `x' in something not a structure or union > test.c:10: request for member `y' in something not a structure or union > > This would be an extremely useful way of breaking down a floating point > number into its component bit-fields, without having to mess around with a > union. It would certainly solve a problem I have at the moment, > especially if the struct were passed to and from calls in the same way as > a DFmode type. You can use the 'transparent union' attribute for that. The floating point member of the union has to be the first one. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-18 12:42 ` Joern Rennecke @ 1998-08-18 21:50 ` Jeffrey A Law 0 siblings, 0 replies; 17+ messages in thread From: Jeffrey A Law @ 1998-08-18 21:50 UTC (permalink / raw) To: Joern Rennecke; +Cc: richard.earnshaw, jason, egcs, rearnsha In message < 199808181702.SAA14402@phal.cygnus.co.uk >you write: > You can use the 'transparent union' attribute for that. The floating > point member of the union has to be the first one. I would not encourage this. "transparent unions" are a bad gcc extension. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-13 23:20 Need someone to look at a regression Jeffrey A Law 1998-08-14 3:44 ` Andreas Schwab @ 1998-08-14 16:55 ` Carlo Wood 1998-08-15 0:17 ` Jeffrey A Law 1 sibling, 1 reply; 17+ messages in thread From: Carlo Wood @ 1998-08-14 16:55 UTC (permalink / raw) To: law; +Cc: egcs Hmm, I used to get a warning for this, because the test is always true (unsigned int is always >= 0): ------------------- #include <stdio.h> int main(int argc, char **argv) { unsigned int j = argc; if (j >= 0) printf("%u > 0\n", j); else printf("%u < 0\n", j); return 0; } ------------------- ~/tmp>gcc -Wall -pedantic -O2 foo.c ~/tmp> The following also worries me a bit: ------------------- #include <stdio.h> int main() { unsigned int j = -1; if (j == -1) printf("%u == -1\n", j); else printf("%u != -1\n", j); return 0; } ------------------- ~/tmp>gcc -Wall -pedantic foo.c ~/tmp>a.out 4294967295 == -1 ~/tmp>gcc -Wall -pedantic -O6 foo.c ~/tmp>a.out 4294967295 == -1 No warnings? I am not sure if that is a bug or a feature, but since it is known that (unsigned int) != -1, it just seemed weird that the optimisation chooses to make j == -1 without a warning. -- Carlo Wood <carlo@runaway.xs4all.nl> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Need someone to look at a regression 1998-08-14 16:55 ` Carlo Wood @ 1998-08-15 0:17 ` Jeffrey A Law 0 siblings, 0 replies; 17+ messages in thread From: Jeffrey A Law @ 1998-08-15 0:17 UTC (permalink / raw) To: Carlo Wood; +Cc: egcs In message < 199808141440.QAA29307@jolan.ppro >you write: > Hmm, I used to get a warning for this, because the > test is always true (unsigned int is always >= 0): > > ------------------- > #include <stdio.h> > > int main(int argc, char **argv) > { > unsigned int j = argc; > > if (j >= 0) > printf("%u > 0\n", j); > else > printf("%u < 0\n", j); > > return 0; > } Add "-W" and you'll get the desired warning. > No warnings? I am not sure if that is a bug or a feature, but > since it is known that (unsigned int) != -1, it just seemed weird > that the optimisation chooses to make j == -1 without a warning. It is valid to compare an unsigned value against -1. jeff ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~1998-08-21 19:47 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-08-13 23:20 Need someone to look at a regression Jeffrey A Law 1998-08-14 3:44 ` Andreas Schwab 1998-08-14 8:28 ` Jeffrey A Law [not found] ` <899.903108402.cygnus.egcs@hurl.cygnus.com> 1998-08-15 0:17 ` Ulrich Drepper 1998-08-15 21:09 ` Jeffrey A Law 1998-08-16 8:18 ` Carlo Wood 1998-08-16 20:59 ` Jeffrey A Law 1998-08-17 19:53 ` Kamil Iskra 1998-08-17 17:41 ` Jeffrey A Law 1998-08-19 19:04 ` Ken Raeburn 1998-08-21 19:47 ` Jeffrey A Law [not found] ` <5044.903227080.cygnus.egcs@hurl.cygnus.com> 1998-08-17 19:53 ` Jason Merrill 1998-08-18 2:31 ` Richard Earnshaw 1998-08-18 12:42 ` Joern Rennecke 1998-08-18 21:50 ` Jeffrey A Law 1998-08-14 16:55 ` Carlo Wood 1998-08-15 0:17 ` Jeffrey A Law
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).