* assemble_external on .class files @ 1999-05-20 21:06 Mark Klein 1999-05-22 14:23 ` Jeffrey A Law 1999-05-31 21:36 ` Mark Klein 0 siblings, 2 replies; 268+ messages in thread From: Mark Klein @ 1999-05-20 21:06 UTC (permalink / raw) To: egcs; +Cc: java-discuss I'm having a whale of a time trying to figure out a problem I'm experiencing with gcj: External procedure labels need to be .IMPORTED before they can be used on my platform. Some of these are part of a dispatch table created from classes such as java::lang::Object. My first attempt at resolving this was to place an assemble_external() in layout_class(), but that results in a lot of clutter with .IMPORT statements for a whole bunch of things that really are not referenced. I suppose this could be my brute force method, but I would prefer to only do the .IMPORT for referenced methods/classes. Here's HelloWorld's _vt_: .IMPORT clone__Q34java4lang6Object,CODE .IMPORT hashCode__Q34java4lang6Object,CODE .align 4 HelloWorld virtual table .word _CL_10HelloWorld .word 0 .word P%java::lang::Object::finalize(void) .word P%java::lang::Object::hashCode(void) .word P%java::lang::Object::equals(java::lang::Object *) .word P%java::lang::Object::toString(void) .word P%java::lang::Object::clone(void) Note that clone() and hashCode() have been imported. But finalize(), equals() and tostring() have not. They are referenced in some fashion in order to be in the virtual table when the rest of their brethren are not. But, clone() and hashCode() must be referenced in some other path in order to cause them to be imported. I can't seem to figure out what that path is in order to make the same changes for the other case. I also have not completed by gdb port, so I am debugging this with the native (non-symbolic) debugger, which is also probably leading to some of my confusion as I chase pointers in trees. TIA, M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-20 21:06 assemble_external on .class files Mark Klein @ 1999-05-22 14:23 ` Jeffrey A Law 1999-05-22 15:28 ` Mark Klein ` (2 more replies) 1999-05-31 21:36 ` Mark Klein 1 sibling, 3 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-05-22 14:23 UTC (permalink / raw) To: Mark Klein; +Cc: egcs, java-discuss In message < 4.1.19990520204749.00c7fa90@garfield.dis.com >you write: > External procedure labels need to be .IMPORTED before they can > be used on my platform. Some of these are part of a dispatch table > created from classes such as java::lang::Object. My first attempt at > resolving this was to place an assemble_external() in layout_class(), > but that results in a lot of clutter with .IMPORT statements for a > whole bunch of things that really are not referenced. I suppose this > could be my brute force method, but I would prefer to only do the > .IMPORT for referenced methods/classes. I wouldn't worry about the extra .IMPORTs. In fact, it's a little known aspect of SOM that the assembler is responsible for _not_ adding an imported symbol to the undefined symbols for a module if that symbol is not actually referenced. Jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-22 14:23 ` Jeffrey A Law @ 1999-05-22 15:28 ` Mark Klein 1999-05-31 21:36 ` Mark Klein 1999-05-25 18:33 ` Mark Klein 1999-05-31 21:36 ` Jeffrey A Law 2 siblings, 1 reply; 268+ messages in thread From: Mark Klein @ 1999-05-22 15:28 UTC (permalink / raw) To: law; +Cc: egcs, java-discuss At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote: >I wouldn't worry about the extra .IMPORTs. In fact, it's a little known >aspect of SOM that the assembler is responsible for _not_ adding an imported >symbol to the undefined symbols for a module if that symbol is not actually >referenced. Thanks ... brute force method it is! Just when I was starting to see the _trees_ through the forest. :-) -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-22 15:28 ` Mark Klein @ 1999-05-31 21:36 ` Mark Klein 0 siblings, 0 replies; 268+ messages in thread From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw) To: law; +Cc: egcs, java-discuss At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote: >I wouldn't worry about the extra .IMPORTs. In fact, it's a little known >aspect of SOM that the assembler is responsible for _not_ adding an imported >symbol to the undefined symbols for a module if that symbol is not actually >referenced. Thanks ... brute force method it is! Just when I was starting to see the _trees_ through the forest. :-) -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-22 14:23 ` Jeffrey A Law 1999-05-22 15:28 ` Mark Klein @ 1999-05-25 18:33 ` Mark Klein 1999-05-25 19:41 ` Jeffrey A Law 1999-05-31 21:36 ` Mark Klein 1999-05-31 21:36 ` Jeffrey A Law 2 siblings, 2 replies; 268+ messages in thread From: Mark Klein @ 1999-05-25 18:33 UTC (permalink / raw) To: Jeffrey A Law; +Cc: egcs, java-discuss At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote: > > My first attempt at > > resolving this was to place an assemble_external() in layout_class_method(), > > but that results in a lot of clutter with .IMPORT statements for a > > whole bunch of things that really are not referenced. >I wouldn't worry about the extra .IMPORTs. In fact, it's a little known >aspect of SOM that the assembler is responsible for _not_ adding an imported >symbol to the undefined symbols for a module if that symbol is not actually >referenced. Turns out that this also isn't a complete solution, partially because assemble_external is looking for DECL_EXTERNAL. The tree field used for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also explains why certain .IMPORTs were happening and others were not ... only native methods were getting the .IMPORTs. There may be another problem here in that DECL_EXTERNAL is explicitly set in various places and could ultimately end up in a usage conflict between it and the usage of METHOD_NATIVE elswhere in the code. Suggestions? M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 18:33 ` Mark Klein @ 1999-05-25 19:41 ` Jeffrey A Law 1999-05-25 21:00 ` Per Bothner 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Mark Klein 1 sibling, 2 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-05-25 19:41 UTC (permalink / raw) To: Mark Klein; +Cc: egcs, java-discuss In message < 4.1.19990525180956.00c96100@garfield.dis.com >you write: > Turns out that this also isn't a complete solution, partially because > assemble_external is looking for DECL_EXTERNAL. The tree field used > for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also > explains why certain .IMPORTs were happening and others were not ... > only native methods were getting the .IMPORTs. > > There may be another problem here in that DECL_EXTERNAL is explicitly > set in various places and could ultimately end up in a usage conflict > between it and the usage of METHOD_NATIVE elswhere in the code. > > Suggestions? Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to have them overloaded on the same bit. Can someone from the Java side explain why they're using the same bit? Especially since DECL_EXTERNAL has a well defined meaning already. It seems to me using a lang specific flag would make a lot more sense for METHOD_NATIVE. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 19:41 ` Jeffrey A Law @ 1999-05-25 21:00 ` Per Bothner 1999-05-25 21:50 ` Jeffrey A Law 1999-05-31 21:36 ` Per Bothner 1999-05-31 21:36 ` Jeffrey A Law 1 sibling, 2 replies; 268+ messages in thread From: Per Bothner @ 1999-05-25 21:00 UTC (permalink / raw) To: law; +Cc: Mark Klein, egcs, java-discuss Jeffrey A Law <law@cygnus.com> writes: > Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to > have them overloaded on the same bit. Can someone from the Java side > explain why they're using the same bit? Especially since DECL_EXTERNAL has > a well defined meaning already. It seems to me using a lang specific flag > would make a lot more sense for METHOD_NATIVE. Well, the logic was the assumption that they would always be the same. In a Java class, we have three kinds of methods: (1) Regular methods (static or instance), with method bodies in the class body. These methods are neither native, nor external, since they are declared in the current input (.java or .class) file. (2) Native methods, which do not have bodies. These must be bound to some methods defined in some extenal C++ file. Hence, they need to have DECL_EXTERNAL set - as well as METHOD_NATIVE. (3) Abstract methods - which have no bodies anywhere. If they are ever referenced, it would be a compiler bug. I skimmed the earlier messages in this thread, which may be why I still don't understand why there would be any reason to split up the flags. However, perhaps there should be a comment where METHOD_NATIVE is defined. Something like the following may suffice: /* Only native methods are external (and vice versa). */ or perhaps: /* A method is external if and only if it is native. */ -- --Per Bothner bothner@pacbell.net http://home.pacbell.net/bothner/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 21:00 ` Per Bothner @ 1999-05-25 21:50 ` Jeffrey A Law 1999-05-25 22:19 ` Mark Klein 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Per Bothner 1 sibling, 2 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-05-25 21:50 UTC (permalink / raw) To: Per Bothner; +Cc: Mark Klein, egcs, java-discuss In message < m2n1yseark.fsf@magnus.cygnus.com >you write: > Well, the logic was the assumption that they would always be the same. > > In a Java class, we have three kinds of methods: > > (1) Regular methods (static or instance), with method bodies in the class > body. These methods are neither native, nor external, since they are > declared in the current input (.java or .class) file. > > (2) Native methods, which do not have bodies. These must be bound to some > methods defined in some extenal C++ file. Hence, they need to have > DECL_EXTERNAL set - as well as METHOD_NATIVE. > > (3) Abstract methods - which have no bodies anywhere. If they are ever > referenced, it would be a compiler bug. Thanks. Hmmm, this makes me think that we're find with having them overloaded on the same bit. Mark, I think this is a red herring. > However, perhaps there should be a comment where METHOD_NATIVE is > defined. Something like the following may suffice: > /* Only native methods are external (and vice versa). */ > or perhaps: > /* A method is external if and only if it is native. */ Yea. It would help clarify things for the future. Thanks again! jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 21:50 ` Jeffrey A Law @ 1999-05-25 22:19 ` Mark Klein 1999-05-25 22:24 ` Jeffrey A Law ` (2 more replies) 1999-05-31 21:36 ` Jeffrey A Law 1 sibling, 3 replies; 268+ messages in thread From: Mark Klein @ 1999-05-25 22:19 UTC (permalink / raw) To: law, Per Bothner; +Cc: egcs, java-discuss At 10:44 PM 5/25/99 -0600, Jeffrey A Law wrote: >Thanks. Hmmm, this makes me think that we're find with having them overloaded >on the same bit. Mark, I think this is a red herring. Could be, but then there's a problem with assemble_external vis the usage of DECL_EXTERNAL for the vtable. Recall my earlier example, from java::lang::Object: Method name:"finalize" protected Signature: 4=()void ... Method name:"hashCode" public native Signature: 11=()int and the vtable: __vt_10HelloWorld .word _CL_10HelloWorld .word 0 .word P%finalize__Q34java4lang6Object .IMPORT hashCode__Q34java4lang6Object,CODE .word P%hashCode__Q34java4lang6Object .word P%equals__Q34java4lang6ObjectPQ34java4lang6Object .word P%toString__Q34java4lang6Object .IMPORT clone__Q34java4lang6Object,CODE .word P%clone__Q34java4lang6Object Note that in order to use the plabels, the symbols must first be imported on PA-RISC. In this case, we have finalize, and it isn't native. However, in order for assemble_external to emit the .IMPORT, DECL_EXTERNAL (among others) must be true. But, hashCode is native and is imported, hence the .IMPORT. Since this is in contradiction to usage in jc1 as explained by Per, I've got a problem.... Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a HP9000? Or is this a problem only on the HP3000? G'night, y'all. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 22:19 ` Mark Klein @ 1999-05-25 22:24 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-25 22:49 ` Per Bothner 1999-05-31 21:36 ` Mark Klein 2 siblings, 1 reply; 268+ messages in thread From: Jeffrey A Law @ 1999-05-25 22:24 UTC (permalink / raw) To: Mark Klein; +Cc: Per Bothner, egcs, java-discuss In message < 4.1.19990525220502.00ca56a0@garfield.dis.com >you write: > Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a > HP9000? Nobody that I'm aware of. I talked to Anthony Green a week or two about some of this stuff and it sounds like x86-linux & sparc-solaris are the native platforms that should "just work" out of the box since that's what the Java team is using/testing regularly. So it's not a huge suprise that we've got a few issues to resolve on the PA (and likely other targets). jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 22:24 ` Jeffrey A Law @ 1999-05-31 21:36 ` Jeffrey A Law 0 siblings, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Mark Klein; +Cc: Per Bothner, egcs, java-discuss In message < 4.1.19990525220502.00ca56a0@garfield.dis.com >you write: > Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a > HP9000? Nobody that I'm aware of. I talked to Anthony Green a week or two about some of this stuff and it sounds like x86-linux & sparc-solaris are the native platforms that should "just work" out of the box since that's what the Java team is using/testing regularly. So it's not a huge suprise that we've got a few issues to resolve on the PA (and likely other targets). jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 22:19 ` Mark Klein 1999-05-25 22:24 ` Jeffrey A Law @ 1999-05-25 22:49 ` Per Bothner 1999-05-31 14:53 ` Mark Klein 1999-05-31 21:36 ` Per Bothner 1999-05-31 21:36 ` Mark Klein 2 siblings, 2 replies; 268+ messages in thread From: Per Bothner @ 1999-05-25 22:49 UTC (permalink / raw) To: Mark Klein; +Cc: egcs, java-discuss Mark Klein <mklein@dis.com> writes: > Could be, but then there's a problem with assemble_external vis the usage of > DECL_EXTERNAL for the vtable. Recall my earlier example, from > java::lang::Object: Ah - that was in a message that had expired. My logic only applies to entries in the "method table". It is wrong for entries in the vtable. It is also wrong for calls to static methods in other classes. METHOD_NATIVE does need to be split from DECL_EXTERNAL. There doesn't seem to be any available DECL_LANG_FLAGs, but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs). That means that we need to set DECL_EXTERNAL separately. I think it should be true for any methods that has METHOD_NATIVE, *or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2. --Per Bothner bothner@pacbell.net http://home.pacbell.net/bothner/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 22:49 ` Per Bothner @ 1999-05-31 14:53 ` Mark Klein 1999-05-31 21:36 ` Mark Klein 1999-05-31 21:36 ` Per Bothner 1 sibling, 1 reply; 268+ messages in thread From: Mark Klein @ 1999-05-31 14:53 UTC (permalink / raw) To: Per Bothner; +Cc: egcs, java-discuss At 10:55 PM 5/25/99 -0700, Per Bothner wrote: >METHOD_NATIVE does need to be split from DECL_EXTERNAL. >There doesn't seem to be any available DECL_LANG_FLAGs, >but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs). Grabbed TREE_LANG_FLAG_6. >That means that we need to set DECL_EXTERNAL separately. >I think it should be true for any methods that has METHOD_NATIVE, >*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2. The latter doesn't appear to be complete either since there are certain classes which are external (e.g. java.lang.Object) where is_compiled_class (DECL_CONTEXT (method_decl)) is returning 2. Regards, M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-31 14:53 ` Mark Klein @ 1999-05-31 21:36 ` Mark Klein 0 siblings, 0 replies; 268+ messages in thread From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw) To: Per Bothner; +Cc: egcs, java-discuss At 10:55 PM 5/25/99 -0700, Per Bothner wrote: >METHOD_NATIVE does need to be split from DECL_EXTERNAL. >There doesn't seem to be any available DECL_LANG_FLAGs, >but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs). Grabbed TREE_LANG_FLAG_6. >That means that we need to set DECL_EXTERNAL separately. >I think it should be true for any methods that has METHOD_NATIVE, >*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2. The latter doesn't appear to be complete either since there are certain classes which are external (e.g. java.lang.Object) where is_compiled_class (DECL_CONTEXT (method_decl)) is returning 2. Regards, M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 22:49 ` Per Bothner 1999-05-31 14:53 ` Mark Klein @ 1999-05-31 21:36 ` Per Bothner 1 sibling, 0 replies; 268+ messages in thread From: Per Bothner @ 1999-05-31 21:36 UTC (permalink / raw) To: Mark Klein; +Cc: egcs, java-discuss Mark Klein <mklein@dis.com> writes: > Could be, but then there's a problem with assemble_external vis the usage of > DECL_EXTERNAL for the vtable. Recall my earlier example, from > java::lang::Object: Ah - that was in a message that had expired. My logic only applies to entries in the "method table". It is wrong for entries in the vtable. It is also wrong for calls to static methods in other classes. METHOD_NATIVE does need to be split from DECL_EXTERNAL. There doesn't seem to be any available DECL_LANG_FLAGs, but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs). That means that we need to set DECL_EXTERNAL separately. I think it should be true for any methods that has METHOD_NATIVE, *or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2. --Per Bothner bothner@pacbell.net http://home.pacbell.net/bothner/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 22:19 ` Mark Klein 1999-05-25 22:24 ` Jeffrey A Law 1999-05-25 22:49 ` Per Bothner @ 1999-05-31 21:36 ` Mark Klein 2 siblings, 0 replies; 268+ messages in thread From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw) To: law, Per Bothner; +Cc: egcs, java-discuss At 10:44 PM 5/25/99 -0600, Jeffrey A Law wrote: >Thanks. Hmmm, this makes me think that we're find with having them overloaded >on the same bit. Mark, I think this is a red herring. Could be, but then there's a problem with assemble_external vis the usage of DECL_EXTERNAL for the vtable. Recall my earlier example, from java::lang::Object: Method name:"finalize" protected Signature: 4=()void ... Method name:"hashCode" public native Signature: 11=()int and the vtable: __vt_10HelloWorld .word _CL_10HelloWorld .word 0 .word P%finalize__Q34java4lang6Object .IMPORT hashCode__Q34java4lang6Object,CODE .word P%hashCode__Q34java4lang6Object .word P%equals__Q34java4lang6ObjectPQ34java4lang6Object .word P%toString__Q34java4lang6Object .IMPORT clone__Q34java4lang6Object,CODE .word P%clone__Q34java4lang6Object Note that in order to use the plabels, the symbols must first be imported on PA-RISC. In this case, we have finalize, and it isn't native. However, in order for assemble_external to emit the .IMPORT, DECL_EXTERNAL (among others) must be true. But, hashCode is native and is imported, hence the .IMPORT. Since this is in contradiction to usage in jc1 as explained by Per, I've got a problem.... Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a HP9000? Or is this a problem only on the HP3000? G'night, y'all. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 21:50 ` Jeffrey A Law 1999-05-25 22:19 ` Mark Klein @ 1999-05-31 21:36 ` Jeffrey A Law 1 sibling, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Per Bothner; +Cc: Mark Klein, egcs, java-discuss In message < m2n1yseark.fsf@magnus.cygnus.com >you write: > Well, the logic was the assumption that they would always be the same. > > In a Java class, we have three kinds of methods: > > (1) Regular methods (static or instance), with method bodies in the class > body. These methods are neither native, nor external, since they are > declared in the current input (.java or .class) file. > > (2) Native methods, which do not have bodies. These must be bound to some > methods defined in some extenal C++ file. Hence, they need to have > DECL_EXTERNAL set - as well as METHOD_NATIVE. > > (3) Abstract methods - which have no bodies anywhere. If they are ever > referenced, it would be a compiler bug. Thanks. Hmmm, this makes me think that we're find with having them overloaded on the same bit. Mark, I think this is a red herring. > However, perhaps there should be a comment where METHOD_NATIVE is > defined. Something like the following may suffice: > /* Only native methods are external (and vice versa). */ > or perhaps: > /* A method is external if and only if it is native. */ Yea. It would help clarify things for the future. Thanks again! jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 21:00 ` Per Bothner 1999-05-25 21:50 ` Jeffrey A Law @ 1999-05-31 21:36 ` Per Bothner 1 sibling, 0 replies; 268+ messages in thread From: Per Bothner @ 1999-05-31 21:36 UTC (permalink / raw) To: law; +Cc: Mark Klein, egcs, java-discuss Jeffrey A Law <law@cygnus.com> writes: > Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to > have them overloaded on the same bit. Can someone from the Java side > explain why they're using the same bit? Especially since DECL_EXTERNAL has > a well defined meaning already. It seems to me using a lang specific flag > would make a lot more sense for METHOD_NATIVE. Well, the logic was the assumption that they would always be the same. In a Java class, we have three kinds of methods: (1) Regular methods (static or instance), with method bodies in the class body. These methods are neither native, nor external, since they are declared in the current input (.java or .class) file. (2) Native methods, which do not have bodies. These must be bound to some methods defined in some extenal C++ file. Hence, they need to have DECL_EXTERNAL set - as well as METHOD_NATIVE. (3) Abstract methods - which have no bodies anywhere. If they are ever referenced, it would be a compiler bug. I skimmed the earlier messages in this thread, which may be why I still don't understand why there would be any reason to split up the flags. However, perhaps there should be a comment where METHOD_NATIVE is defined. Something like the following may suffice: /* Only native methods are external (and vice versa). */ or perhaps: /* A method is external if and only if it is native. */ -- --Per Bothner bothner@pacbell.net http://home.pacbell.net/bothner/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 19:41 ` Jeffrey A Law 1999-05-25 21:00 ` Per Bothner @ 1999-05-31 21:36 ` Jeffrey A Law 1 sibling, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Mark Klein; +Cc: egcs, java-discuss In message < 4.1.19990525180956.00c96100@garfield.dis.com >you write: > Turns out that this also isn't a complete solution, partially because > assemble_external is looking for DECL_EXTERNAL. The tree field used > for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also > explains why certain .IMPORTs were happening and others were not ... > only native methods were getting the .IMPORTs. > > There may be another problem here in that DECL_EXTERNAL is explicitly > set in various places and could ultimately end up in a usage conflict > between it and the usage of METHOD_NATIVE elswhere in the code. > > Suggestions? Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to have them overloaded on the same bit. Can someone from the Java side explain why they're using the same bit? Especially since DECL_EXTERNAL has a well defined meaning already. It seems to me using a lang specific flag would make a lot more sense for METHOD_NATIVE. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-25 18:33 ` Mark Klein 1999-05-25 19:41 ` Jeffrey A Law @ 1999-05-31 21:36 ` Mark Klein 1 sibling, 0 replies; 268+ messages in thread From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw) To: Jeffrey A Law; +Cc: egcs, java-discuss At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote: > > My first attempt at > > resolving this was to place an assemble_external() in layout_class_method(), > > but that results in a lot of clutter with .IMPORT statements for a > > whole bunch of things that really are not referenced. >I wouldn't worry about the extra .IMPORTs. In fact, it's a little known >aspect of SOM that the assembler is responsible for _not_ adding an imported >symbol to the undefined symbols for a module if that symbol is not actually >referenced. Turns out that this also isn't a complete solution, partially because assemble_external is looking for DECL_EXTERNAL. The tree field used for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also explains why certain .IMPORTs were happening and others were not ... only native methods were getting the .IMPORTs. There may be another problem here in that DECL_EXTERNAL is explicitly set in various places and could ultimately end up in a usage conflict between it and the usage of METHOD_NATIVE elswhere in the code. Suggestions? M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-22 14:23 ` Jeffrey A Law 1999-05-22 15:28 ` Mark Klein 1999-05-25 18:33 ` Mark Klein @ 1999-05-31 21:36 ` Jeffrey A Law 2 siblings, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Mark Klein; +Cc: egcs, java-discuss In message < 4.1.19990520204749.00c7fa90@garfield.dis.com >you write: > External procedure labels need to be .IMPORTED before they can > be used on my platform. Some of these are part of a dispatch table > created from classes such as java::lang::Object. My first attempt at > resolving this was to place an assemble_external() in layout_class(), > but that results in a lot of clutter with .IMPORT statements for a > whole bunch of things that really are not referenced. I suppose this > could be my brute force method, but I would prefer to only do the > .IMPORT for referenced methods/classes. I wouldn't worry about the extra .IMPORTs. In fact, it's a little known aspect of SOM that the assembler is responsible for _not_ adding an imported symbol to the undefined symbols for a module if that symbol is not actually referenced. Jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* assemble_external on .class files 1999-05-20 21:06 assemble_external on .class files Mark Klein 1999-05-22 14:23 ` Jeffrey A Law @ 1999-05-31 21:36 ` Mark Klein 1 sibling, 0 replies; 268+ messages in thread From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw) To: egcs; +Cc: java-discuss I'm having a whale of a time trying to figure out a problem I'm experiencing with gcj: External procedure labels need to be .IMPORTED before they can be used on my platform. Some of these are part of a dispatch table created from classes such as java::lang::Object. My first attempt at resolving this was to place an assemble_external() in layout_class(), but that results in a lot of clutter with .IMPORT statements for a whole bunch of things that really are not referenced. I suppose this could be my brute force method, but I would prefer to only do the .IMPORT for referenced methods/classes. Here's HelloWorld's _vt_: .IMPORT clone__Q34java4lang6Object,CODE .IMPORT hashCode__Q34java4lang6Object,CODE .align 4 HelloWorld virtual table .word _CL_10HelloWorld .word 0 .word P%java::lang::Object::finalize(void) .word P%java::lang::Object::hashCode(void) .word P%java::lang::Object::equals(java::lang::Object *) .word P%java::lang::Object::toString(void) .word P%java::lang::Object::clone(void) Note that clone() and hashCode() have been imported. But finalize(), equals() and tostring() have not. They are referenced in some fashion in order to be in the virtual table when the rest of their brethren are not. But, clone() and hashCode() must be referenced in some other path in order to cause them to be imported. I can't seem to figure out what that path is in order to make the same changes for the other case. I also have not completed by gdb port, so I am debugging this with the native (non-symbolic) debugger, which is also probably leading to some of my confusion as I chase pointers in trees. TIA, M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <Jeffrey>]
[parent not found: <A>]
[parent not found: <Law's>]
[parent not found: <message>]
[parent not found: <of>]
[parent not found: <"Wed,>]
[parent not found: <5>]
[parent not found: <Fri,>]
[parent not found: <"Thu,>]
[parent not found: <"Sun,>]
[parent not found: <19>]
[parent not found: <"Mon,>]
[parent not found: <01>]
[parent not found: <Mar>]
[parent not found: <99>]
[parent not found: <Feb>]
[parent not found: <1999>]
[parent not found: <02:37:52>]
[parent not found: <12:29:11>]
[parent not found: <-0500>]
* A Lisp compiler? @ 1999-02-01 8:23 ` Matthew X. Economou 1999-02-01 9:29 ` Ken Raeburn 1999-02-28 22:53 ` Matthew X. Economou 0 siblings, 2 replies; 268+ messages in thread From: Matthew X. Economou @ 1999-02-01 8:23 UTC (permalink / raw) To: egcs Would there be any interest in work on a Lisp compiler and run-time system? I've started to hack a parser together, and I have the beginnings of a run-time sketched out. The more I examine the Lisp specs and GCC's back end, the more I become convinced that a Lisp front-end is possible. I'm aiming for conformance with ANSI Common Lisp and possibly IEEE (R4RS) Scheme, including doo-dads like EVAL, DEFMACRO, EXTEND-SYNTAX, and CALL/CC. I just want to see if there'd be any interest in such a beast. If so, I'll continue working on my parser and run-time. -- "When I was a kid, I used to think that Dammit was God's last name, just like Christ is Jesus' last name." - Kimberly Chapman in rec.humor.oracle.d ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: A Lisp compiler? 1999-02-01 8:23 ` A Lisp compiler? Matthew X. Economou @ 1999-02-01 9:29 ` Ken Raeburn 1999-02-02 15:44 ` Matthew X. Economou ` (2 more replies) 1999-02-28 22:53 ` Matthew X. Economou 1 sibling, 3 replies; 268+ messages in thread From: Ken Raeburn @ 1999-02-01 9:29 UTC (permalink / raw) To: Matthew X. Economou; +Cc: egcs Two thoughts: 1) Consider targeting languages that would be helpful to the GNU project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme based. 2) Translating to C would likely be easier; do you gain much by compiling directly? The generated C code can even be platform-independent, meaning it could be shipped along with the original lisp source for those who don't have the lisp compiler. (E.g., in the Emacs or Guile distributions.) I'd suggest guile over elisp because the lexical scoping plays more nicely with such notions as multi-threaded programming. Seems to me with multi-threaded lisp, either you have to have cooperative threading and wind/unwind the local `let' bindings on each thread switch (not consistent with using pre-emptive threading packages and other languages), or each variable reference may have to walk a list of bindings looking for the "most local" value for the variable. With lexical scoping, a `let' binding translates to an automatic variable. This also leaves more room for optimization when calling arbitrary functions. Also, Guile is intended to work as an extension language for multiple programs (a la Tcl), so compiling it would (eventually, in theory) help people maintaining or extending those programs. Though I don't know of many programs using it *yet*, aside from gimp. I believe there's already a Scheme->C translator available for Guile, but I don't know the specifics. But if there is more to be gained by translating directly to assembly, that you couldn't get translating to C (or, say, GNU C with one or two new extensions), then go for it. Certainly the debugging information would be more likely to reflect the original code instead of the intermediate C code. But then you want gdb support too. :-) This is all just MHO; there are minds on this list more wise in the Ways of Many Parentheses than mine. Ken ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: A Lisp compiler? 1999-02-01 9:29 ` Ken Raeburn @ 1999-02-02 15:44 ` Matthew X. Economou [not found] ` < w4ou2x4jrke.fsf@nemesis.irtnog.org > 1999-02-28 22:53 ` Matthew X. Economou 1999-02-19 23:14 ` Matthias Hölzl 1999-02-28 22:53 ` Ken Raeburn 2 siblings, 2 replies; 268+ messages in thread From: Matthew X. Economou @ 1999-02-02 15:44 UTC (permalink / raw) To: egcs >>>>> "KR" == Ken Raeburn <raeburn@cygnus.com> writes: Thanks for the quick reply, Ken. KR> Consider targeting languages that would be helpful to the GNU KR> project, like Emacs Lisp or (better, IMHO) Guile, which is KR> Scheme based. I believe that Common Lisp is a little more featureful than Emacs Lisp. Syntactically, the languages are identical, so building some kind of library/package that implemented those special forms, functions, and macros unique to Elisp is (famous last words) "fairly trivial". In which case, I'd argue it is better to have the more portable Common Lisp environment with which to start. (The same kind of argument goes for GUILE versus R4RS/R5RS Scheme. It'd be preferable to have the standard (and very powerful) Scheme environment to begin with, then build up the extension language from there. Building an extension language out of some kind of base language is something the Lisp language family is VERY good at.) KR> Translating to C would likely be easier; do you gain much by KR> compiling directly? The generated C code can even be KR> platform-independent, meaning it could be shipped along with KR> the original lisp source for those who don't have the lisp KR> compiler. (E.g., in the Emacs or Guile distributions.) You may very well be correct, here. In this case, GNU Common Lisp already does translate to C. (GCL follows CLtL1 pretty closely. It isn't quite ANSI-compliant, but it is pretty close. If you're interested, compiling to C is described in Christian Queinnec's excellent _Lisp in Small Pieces_, chapter 10.) Personally, I think machine code generation would be a much cooler hack, especially since the run-time environment must include facilities for interpretation (aka EVAL). KR> I'd suggest guile over elisp because the lexical scoping plays KR> more nicely with such notions as multi-threaded programming. KR> Seems to me with multi-threaded lisp, either you have to have KR> cooperative threading and wind/unwind the local `let' bindings KR> on each thread switch (not consistent with using pre-emptive KR> threading packages and other languages), or each variable KR> reference may have to walk a list of bindings looking for the KR> "most local" value for the variable. With lexical scoping, a KR> `let' binding translates to an automatic variable. This also KR> leaves more room for optimization when calling arbitrary KR> functions. I didn't understand a word in this paragraph. Would you take a shot at explaining this to me off-list? KR> Also, Guile is intended to work as an extension language for KR> multiple programs (a la Tcl), so compiling it would KR> (eventually, in theory) help people maintaining or extending KR> those programs. No arguments here. Finding a portable way to interface C (or other languages) to Lisp (and vice versa) would be a Good Thing, regardless of the specific Lisp variant being compiled. KR> But if there is more to be gained by translating directly to KR> assembly, that you couldn't get translating to C (or, say, GNU KR> C with one or two new extensions), then go for it. Does hubris count? :) KR> Certainly the debugging information would be more likely to KR> reflect the original code instead of the intermediate C code. KR> But then you want gdb support too. :-) But of course! And exception handling, and run-time type information, and... and... and...! ;) KR> This is all just MHO; there are minds on this list more wise KR> in the Ways of Many Parentheses than mine. Me too. And goddess only knows if this "project" will survive the month; at this point I'm too ignorant to just give up now. *wink* Is there anyone else out there in EGCS-land with comments on yet another GCC front-end (and run-time system), one that will handle Common Lisp? -- "BABYLON 5! A five-mile long cement mixer of truth, pouring out the Concrete of Nice-Nice in a long, grey ribbon into the future, to form a ***SIDE WALK OF JUSTICE!!***" - The Tick on Babylon 5 ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < w4ou2x4jrke.fsf@nemesis.irtnog.org >]
* [Meta] Re: A Lisp compiler? [not found] ` < w4ou2x4jrke.fsf@nemesis.irtnog.org > @ 1999-02-02 16:14 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-02 16:14 UTC (permalink / raw) To: egcs At 06:48 PM 2/2/99 -0500, you wrote: > X-Face: meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow Besides wasting bandwidth, what the devil does this accomplish? > X-Attribution: XF Oh God please tell me you don't use XF Mail. They had that installed on the X workstations at university once. Then one day someone used XF and at some point it hung... was kill()ed and reran. Then it shortly hung the whole X client. Client was killed and restarted and logged back onto server. XF was run again and after a while it hung. Client was frozen again. The guy killed the client, tried to log back on, and found that all 20 of the LANned X servers were now unreachable. They should have used Red Hat. And they should have used another mail client... I still have no idea how an X client app could do something to bring down the X server it was using and then bring down everything connected to that X server. I can only guess that when one server hung it left all the others blocking on access to a shared file system. The hosts were reachable again not too long after; I guess the file server timed out the first hung X server and the others got to resume using it. That still leaves me wondering how the devil the first server went down... -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* [Meta] Re: A Lisp compiler? 1999-02-02 16:14 ` [Meta] " Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 06:48 PM 2/2/99 -0500, you wrote: > X-Face: meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow meow Besides wasting bandwidth, what the devil does this accomplish? > X-Attribution: XF Oh God please tell me you don't use XF Mail. They had that installed on the X workstations at university once. Then one day someone used XF and at some point it hung... was kill()ed and reran. Then it shortly hung the whole X client. Client was killed and restarted and logged back onto server. XF was run again and after a while it hung. Client was frozen again. The guy killed the client, tried to log back on, and found that all 20 of the LANned X servers were now unreachable. They should have used Red Hat. And they should have used another mail client... I still have no idea how an X client app could do something to bring down the X server it was using and then bring down everything connected to that X server. I can only guess that when one server hung it left all the others blocking on access to a shared file system. The hosts were reachable again not too long after; I guess the file server timed out the first hung X server and the others got to resume using it. That still leaves me wondering how the devil the first server went down... -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: A Lisp compiler? 1999-02-02 15:44 ` Matthew X. Economou [not found] ` < w4ou2x4jrke.fsf@nemesis.irtnog.org > @ 1999-02-28 22:53 ` Matthew X. Economou 1 sibling, 0 replies; 268+ messages in thread From: Matthew X. Economou @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >>>>> "KR" == Ken Raeburn <raeburn@cygnus.com> writes: Thanks for the quick reply, Ken. KR> Consider targeting languages that would be helpful to the GNU KR> project, like Emacs Lisp or (better, IMHO) Guile, which is KR> Scheme based. I believe that Common Lisp is a little more featureful than Emacs Lisp. Syntactically, the languages are identical, so building some kind of library/package that implemented those special forms, functions, and macros unique to Elisp is (famous last words) "fairly trivial". In which case, I'd argue it is better to have the more portable Common Lisp environment with which to start. (The same kind of argument goes for GUILE versus R4RS/R5RS Scheme. It'd be preferable to have the standard (and very powerful) Scheme environment to begin with, then build up the extension language from there. Building an extension language out of some kind of base language is something the Lisp language family is VERY good at.) KR> Translating to C would likely be easier; do you gain much by KR> compiling directly? The generated C code can even be KR> platform-independent, meaning it could be shipped along with KR> the original lisp source for those who don't have the lisp KR> compiler. (E.g., in the Emacs or Guile distributions.) You may very well be correct, here. In this case, GNU Common Lisp already does translate to C. (GCL follows CLtL1 pretty closely. It isn't quite ANSI-compliant, but it is pretty close. If you're interested, compiling to C is described in Christian Queinnec's excellent _Lisp in Small Pieces_, chapter 10.) Personally, I think machine code generation would be a much cooler hack, especially since the run-time environment must include facilities for interpretation (aka EVAL). KR> I'd suggest guile over elisp because the lexical scoping plays KR> more nicely with such notions as multi-threaded programming. KR> Seems to me with multi-threaded lisp, either you have to have KR> cooperative threading and wind/unwind the local `let' bindings KR> on each thread switch (not consistent with using pre-emptive KR> threading packages and other languages), or each variable KR> reference may have to walk a list of bindings looking for the KR> "most local" value for the variable. With lexical scoping, a KR> `let' binding translates to an automatic variable. This also KR> leaves more room for optimization when calling arbitrary KR> functions. I didn't understand a word in this paragraph. Would you take a shot at explaining this to me off-list? KR> Also, Guile is intended to work as an extension language for KR> multiple programs (a la Tcl), so compiling it would KR> (eventually, in theory) help people maintaining or extending KR> those programs. No arguments here. Finding a portable way to interface C (or other languages) to Lisp (and vice versa) would be a Good Thing, regardless of the specific Lisp variant being compiled. KR> But if there is more to be gained by translating directly to KR> assembly, that you couldn't get translating to C (or, say, GNU KR> C with one or two new extensions), then go for it. Does hubris count? :) KR> Certainly the debugging information would be more likely to KR> reflect the original code instead of the intermediate C code. KR> But then you want gdb support too. :-) But of course! And exception handling, and run-time type information, and... and... and...! ;) KR> This is all just MHO; there are minds on this list more wise KR> in the Ways of Many Parentheses than mine. Me too. And goddess only knows if this "project" will survive the month; at this point I'm too ignorant to just give up now. *wink* Is there anyone else out there in EGCS-land with comments on yet another GCC front-end (and run-time system), one that will handle Common Lisp? -- "BABYLON 5! A five-mile long cement mixer of truth, pouring out the Concrete of Nice-Nice in a long, grey ribbon into the future, to form a ***SIDE WALK OF JUSTICE!!***" - The Tick on Babylon 5 ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: A Lisp compiler? 1999-02-01 9:29 ` Ken Raeburn 1999-02-02 15:44 ` Matthew X. Economou @ 1999-02-19 23:14 ` Matthias Hölzl 1999-02-28 22:53 ` Matthias Hölzl 1999-02-28 22:53 ` Ken Raeburn 2 siblings, 1 reply; 268+ messages in thread From: Matthias Hölzl @ 1999-02-19 23:14 UTC (permalink / raw) To: Ken Raeburn; +Cc: Matthew X. Economou, egcs Ken Raeburn <raeburn@cygnus.com> writes: > Two thoughts: > > 1) Consider targeting languages that would be helpful to the GNU > project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme > based. I am surely biased since I am one of the maintainers of d2c, but another good choice would be the Dylan language. Dylan is semantically very close to Common Lisp/CLOS, but written in algebraic notation. Unlike CL which pretty much supposes some "image-based" implementation if you want to support the whole language, Dylan was designed to allow efficient batch compilation. This means that the language is slightly less dynamic, but it is much better suited to compile into stand-alone executables. There is a free Dylan to C compiler available and actively maintained, and a lot of libraries exist or are in development (see our site at www.gwydiondylan.org). D2c supports a fairly good C-FFI and is designed to allow for multiple back-ends, so it should not be too hard to write an additional back-end that interfaces d2c to egcs. If you want to write a Common Lisp front-end you should have a look at the code available from www.cons.org; especially the CMUCL compiler is a very well written piece of software and it is in the public domain, so you might be able to reuse a lot of its code. I think that it might be a good idea to use their ICR or maybe even the low level IR as the starting point for a CL egcs front end. If you want to write a Scheme front end you may want to look at the bigloo Scheme to C compiler. It has a very clean internal structure, some nice extension like a built in lexer/parser generator and its author is generally very helpful. > 2) Translating to C would likely be easier; do you gain much by > compiling directly? The generated C code can even be > platform-independent, meaning it could be shipped along with the > original lisp source for those who don't have the lisp compiler. > (E.g., in the Emacs or Guile distributions.) For CL or Dylan compiling to C is an attractive solution for a batch compiler. The main disadvantage seems to be the increased compilation time. However, AFAIK, it is virtually impossible to compile Scheme to C and still be fully conforming to R5RS since Scheme is "properly tail recursive", which means that cycles of function calls like f -> g -> h -> f are not allowed to consume stack space if all the calls are made in tail position. E.g. (define (f x) (g x 1)) (define (g x y) (if (= y 2) x (h 3))) (define (h x) (f 42)) (f 0) has to loop indefinitely without running out of space. All Scheme to C compilers that I am familiar with only guarantee tail call elimination on self tail calls. It seems that in order to provide full tail recursion you'd have to compile the whole program into one large C function and implement function calls via gotos (which makes callbacks from external libraries very hard). Regards, Matthias ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: A Lisp compiler? 1999-02-19 23:14 ` Matthias Hölzl @ 1999-02-28 22:53 ` Matthias Hölzl 0 siblings, 0 replies; 268+ messages in thread From: Matthias Hölzl @ 1999-02-28 22:53 UTC (permalink / raw) To: Ken Raeburn; +Cc: Matthew X. Economou, egcs Ken Raeburn <raeburn@cygnus.com> writes: > Two thoughts: > > 1) Consider targeting languages that would be helpful to the GNU > project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme > based. I am surely biased since I am one of the maintainers of d2c, but another good choice would be the Dylan language. Dylan is semantically very close to Common Lisp/CLOS, but written in algebraic notation. Unlike CL which pretty much supposes some "image-based" implementation if you want to support the whole language, Dylan was designed to allow efficient batch compilation. This means that the language is slightly less dynamic, but it is much better suited to compile into stand-alone executables. There is a free Dylan to C compiler available and actively maintained, and a lot of libraries exist or are in development (see our site at www.gwydiondylan.org). D2c supports a fairly good C-FFI and is designed to allow for multiple back-ends, so it should not be too hard to write an additional back-end that interfaces d2c to egcs. If you want to write a Common Lisp front-end you should have a look at the code available from www.cons.org; especially the CMUCL compiler is a very well written piece of software and it is in the public domain, so you might be able to reuse a lot of its code. I think that it might be a good idea to use their ICR or maybe even the low level IR as the starting point for a CL egcs front end. If you want to write a Scheme front end you may want to look at the bigloo Scheme to C compiler. It has a very clean internal structure, some nice extension like a built in lexer/parser generator and its author is generally very helpful. > 2) Translating to C would likely be easier; do you gain much by > compiling directly? The generated C code can even be > platform-independent, meaning it could be shipped along with the > original lisp source for those who don't have the lisp compiler. > (E.g., in the Emacs or Guile distributions.) For CL or Dylan compiling to C is an attractive solution for a batch compiler. The main disadvantage seems to be the increased compilation time. However, AFAIK, it is virtually impossible to compile Scheme to C and still be fully conforming to R5RS since Scheme is "properly tail recursive", which means that cycles of function calls like f -> g -> h -> f are not allowed to consume stack space if all the calls are made in tail position. E.g. (define (f x) (g x 1)) (define (g x y) (if (= y 2) x (h 3))) (define (h x) (f 42)) (f 0) has to loop indefinitely without running out of space. All Scheme to C compilers that I am familiar with only guarantee tail call elimination on self tail calls. It seems that in order to provide full tail recursion you'd have to compile the whole program into one large C function and implement function calls via gotos (which makes callbacks from external libraries very hard). Regards, Matthias ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: A Lisp compiler? 1999-02-01 9:29 ` Ken Raeburn 1999-02-02 15:44 ` Matthew X. Economou 1999-02-19 23:14 ` Matthias Hölzl @ 1999-02-28 22:53 ` Ken Raeburn 2 siblings, 0 replies; 268+ messages in thread From: Ken Raeburn @ 1999-02-28 22:53 UTC (permalink / raw) To: Matthew X. Economou; +Cc: egcs Two thoughts: 1) Consider targeting languages that would be helpful to the GNU project, like Emacs Lisp or (better, IMHO) Guile, which is Scheme based. 2) Translating to C would likely be easier; do you gain much by compiling directly? The generated C code can even be platform-independent, meaning it could be shipped along with the original lisp source for those who don't have the lisp compiler. (E.g., in the Emacs or Guile distributions.) I'd suggest guile over elisp because the lexical scoping plays more nicely with such notions as multi-threaded programming. Seems to me with multi-threaded lisp, either you have to have cooperative threading and wind/unwind the local `let' bindings on each thread switch (not consistent with using pre-emptive threading packages and other languages), or each variable reference may have to walk a list of bindings looking for the "most local" value for the variable. With lexical scoping, a `let' binding translates to an automatic variable. This also leaves more room for optimization when calling arbitrary functions. Also, Guile is intended to work as an extension language for multiple programs (a la Tcl), so compiling it would (eventually, in theory) help people maintaining or extending those programs. Though I don't know of many programs using it *yet*, aside from gimp. I believe there's already a Scheme->C translator available for Guile, but I don't know the specifics. But if there is more to be gained by translating directly to assembly, that you couldn't get translating to C (or, say, GNU C with one or two new extensions), then go for it. Certainly the debugging information would be more likely to reflect the original code instead of the intermediate C code. But then you want gdb support too. :-) This is all just MHO; there are minds on this list more wise in the Ways of Many Parentheses than mine. Ken ^ permalink raw reply [flat|nested] 268+ messages in thread
* A Lisp compiler? 1999-02-01 8:23 ` A Lisp compiler? Matthew X. Economou 1999-02-01 9:29 ` Ken Raeburn @ 1999-02-28 22:53 ` Matthew X. Economou 1 sibling, 0 replies; 268+ messages in thread From: Matthew X. Economou @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs Would there be any interest in work on a Lisp compiler and run-time system? I've started to hack a parser together, and I have the beginnings of a run-time sketched out. The more I examine the Lisp specs and GCC's back end, the more I become convinced that a Lisp front-end is possible. I'm aiming for conformance with ANSI Common Lisp and possibly IEEE (R4RS) Scheme, including doo-dads like EVAL, DEFMACRO, EXTEND-SYNTAX, and CALL/CC. I just want to see if there'd be any interest in such a beast. If so, I'll continue working on my parser and run-time. -- "When I was a kid, I used to think that Dammit was God's last name, just like Christ is Jesus' last name." - Kimberly Chapman in rec.humor.oracle.d ^ permalink raw reply [flat|nested] 268+ messages in thread
* Confirmed template parsing bug: bug in error message generation. @ 1999-02-27 21:39 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 0:02 ` Alexandre Oliva 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-27 21:39 UTC (permalink / raw) To: egcs, egcs-bugs At 07:07 PM 2/27/99 PST, I wrote: > So there are only two possibilities: > 1. A Mandelbug that causes the compiler to barf on legitimate > template instance names under unspecified and complex > circumstances. Or, > 2. A bug that causes it to output a bogus parse error message instead > of a real undeclared name error message under unspecified and > complex conditions. > Either of these is a parser bug, one in parsing itself and one in the > generating of the correct error message for an error. Well, I checked and it seems in my original code, I forgot to import math_traits from a namespace. So there are actually 2 errors, which was the cause of the confusion: Error #1, in my code, missing using declaration causing math_traits to not be in scope, setting me up to be dinged by: Error #2, in egcs, wrong error message is output. Further testing reveals that extern foo<int> baz; and the like will produce bogus parse errors instead of the correct error, which is that the name 'foo' is undeclared. (Copy the above line and paste it into a blank text docuemnt and save as foo.cc, and type gcc foo.cc -W -Wall -Werror -O1. You get foo.cc:1: syntax error before ';' and the correct error is foo.cc:1: 'foo' undeclared foo.cc:1: (Each undeclared identifier is reported only once etc. etc. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Confirmed template parsing bug: bug in error message generation. 1999-02-27 21:39 ` Confirmed template parsing bug: bug in error message generation Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 0:02 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs, egcs-bugs At 07:07 PM 2/27/99 PST, I wrote: > So there are only two possibilities: > 1. A Mandelbug that causes the compiler to barf on legitimate > template instance names under unspecified and complex > circumstances. Or, > 2. A bug that causes it to output a bogus parse error message instead > of a real undeclared name error message under unspecified and > complex conditions. > Either of these is a parser bug, one in parsing itself and one in the > generating of the correct error message for an error. Well, I checked and it seems in my original code, I forgot to import math_traits from a namespace. So there are actually 2 errors, which was the cause of the confusion: Error #1, in my code, missing using declaration causing math_traits to not be in scope, setting me up to be dinged by: Error #2, in egcs, wrong error message is output. Further testing reveals that extern foo<int> baz; and the like will produce bogus parse errors instead of the correct error, which is that the name 'foo' is undeclared. (Copy the above line and paste it into a blank text docuemnt and save as foo.cc, and type gcc foo.cc -W -Wall -Werror -O1. You get foo.cc:1: syntax error before ';' and the correct error is foo.cc:1: 'foo' undeclared foo.cc:1: (Each undeclared identifier is reported only once etc. etc. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation. 1999-02-27 21:39 ` Confirmed template parsing bug: bug in error message generation Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire @ 1999-03-01 0:02 ` Alexandre Oliva [not found] ` < oriuclljxv.fsf@araguaia.dcc.unicamp.br > 1999-03-31 23:46 ` Alexandre Oliva 1 sibling, 2 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-01 0:02 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs, egcs-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 748 bytes --] On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote: > Well, I checked and it seems in my original code, I forgot to import > math_traits from a namespace. So there are actually 2 errors, Then please post a bug report as recommended in http://egcs.cygnus.com/faq.html#bugreport , i.e., containing a single code snippet that demonstrates the problem and a description of the host in which you have observed the problem, otherwise lots of people may have to spend time re-creating the code snippet you already have. Thanks -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < oriuclljxv.fsf@araguaia.dcc.unicamp.br >]
* Re: Confirmed template parsing bug: bug in error message generation. [not found] ` < oriuclljxv.fsf@araguaia.dcc.unicamp.br > @ 1999-03-02 8:43 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net > ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-03-02 8:43 UTC (permalink / raw) To: egcs, egcs-bugs At 04:59 AM 3/1/99 -0300, you wrote: >Then please post a bug report... I already did! >...containing a single code snippet that demonstrates the problem... "extern foo<int> bar;" Parse error, but line is well-formed; should be undeclared identifier "foo". Caused a 4 hour work stoppage here with people trying to track down obscure aspects of the standard regarding templates thinking they made a subtly ill-formed template declaration, and then throwing "typename" qualifiers around at random half-heartedly, before suspecting it might be a compiler bug, all of it triggered by a simple use of a symbol not imported from its namespace. :-) >...and a description of the host in which you have observed the >problem... x86-MSDOS. Which anyone who has read the original stuff will know. Not that there is a snowball's chance in hell that the target has any influence whatsoever on the *parser* :-) >otherwise lots of people may have to spend time re-creating the code >snippet you already have. Why you believe this is beyond me, since the code snippet (above) was in the very post you quoted IIRC, and the target, even if relevant for parser issues, has been referred to be my in the past also. Copied to egcs-bugs. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net >]
* Re: Confirmed template parsing bug: bug in error message generation. [not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net > @ 1999-03-02 9:26 ` Robert Lipe 1999-03-31 23:46 ` Robert Lipe 0 siblings, 1 reply; 268+ messages in thread From: Robert Lipe @ 1999-03-02 9:26 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs, egcs-bugs > >...containing a single code snippet that demonstrates the problem... > "extern foo<int> bar;" > > Parse error, but line is well-formed; should be undeclared identifier I cannot confirm or deny of the line is well formed, but the (EDGFE-based) UW C++ compiler generates what looks like a more helpful error message. $ CC /tmp/p.cc "/tmp/p.cc", line 1: error: foo is not a class template extern foo<int> bar; ^ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation. 1999-03-02 9:26 ` Robert Lipe @ 1999-03-31 23:46 ` Robert Lipe 0 siblings, 0 replies; 268+ messages in thread From: Robert Lipe @ 1999-03-31 23:46 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs, egcs-bugs > >...containing a single code snippet that demonstrates the problem... > "extern foo<int> bar;" > > Parse error, but line is well-formed; should be undeclared identifier I cannot confirm or deny of the line is well formed, but the (EDGFE-based) UW C++ compiler generates what looks like a more helpful error message. $ CC /tmp/p.cc "/tmp/p.cc", line 1: error: foo is not a class template extern foo<int> bar; ^ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation. 1999-03-02 8:43 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net > @ 1999-03-02 22:22 ` Alexandre Oliva 1999-03-31 23:46 ` Alexandre Oliva 1999-03-31 23:46 ` Paul Derbyshire 2 siblings, 1 reply; 268+ messages in thread From: Alexandre Oliva @ 1999-03-02 22:22 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs, egcs-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1665 bytes --] On Mar 2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote: > At 04:59 AM 3/1/99 -0300, you wrote: >> Then please post a bug report... > I already did! >> ...containing a single code snippet that demonstrates the problem... > "extern foo<int> bar;" > Parse error, but line is well-formed; Without the quotes, I suppose :-) And it is not well-formed if foo is not declared as a template yet, but I agree that the message could be improved. >> ...and a description of the host in which you have observed the >> problem... > x86-MSDOS. Which anyone who has read the original stuff will know. Bug reports are usually kept by developers in mailboxes or such, and it's very good to have all the needed information in a single message, rather than having to collect it from dozens of different messages. That's why I asked for a complete bug report. > Not that there is a snowball's chance in hell that the target has > any influence whatsoever on the *parser* :-) Platform-dependent memory corruption can damage the symbol table, which may lead to parse errors. >> otherwise lots of people may have to spend time re-creating the code >> snippet you already have. > Why you believe this is beyond me, since the code snippet (above) was in > the very post you quoted IIRC Sorry, I did not understand that was the *whole* code snippet. Thanks for re-posting it, anyway. > Copied to egcs-bugs. That's where bug reports belong; thanks :-) -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation. 1999-03-02 22:22 ` Alexandre Oliva @ 1999-03-31 23:46 ` Alexandre Oliva 0 siblings, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs, egcs-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1666 bytes --] On Mar 2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote: > At 04:59 AM 3/1/99 -0300, you wrote: >> Then please post a bug report... > I already did! >> ...containing a single code snippet that demonstrates the problem... > "extern foo<int> bar;" > Parse error, but line is well-formed; Without the quotes, I suppose :-) And it is not well-formed if foo is not declared as a template yet, but I agree that the message could be improved. >> ...and a description of the host in which you have observed the >> problem... > x86-MSDOS. Which anyone who has read the original stuff will know. Bug reports are usually kept by developers in mailboxes or such, and it's very good to have all the needed information in a single message, rather than having to collect it from dozens of different messages. That's why I asked for a complete bug report. > Not that there is a snowball's chance in hell that the target has > any influence whatsoever on the *parser* :-) Platform-dependent memory corruption can damage the symbol table, which may lead to parse errors. >> otherwise lots of people may have to spend time re-creating the code >> snippet you already have. > Why you believe this is beyond me, since the code snippet (above) was in > the very post you quoted IIRC Sorry, I did not understand that was the *whole* code snippet. Thanks for re-posting it, anyway. > Copied to egcs-bugs. That's where bug reports belong; thanks :-) -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation. 1999-03-02 8:43 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net > 1999-03-02 22:22 ` Alexandre Oliva @ 1999-03-31 23:46 ` Paul Derbyshire 2 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-03-31 23:46 UTC (permalink / raw) To: egcs, egcs-bugs At 04:59 AM 3/1/99 -0300, you wrote: >Then please post a bug report... I already did! >...containing a single code snippet that demonstrates the problem... "extern foo<int> bar;" Parse error, but line is well-formed; should be undeclared identifier "foo". Caused a 4 hour work stoppage here with people trying to track down obscure aspects of the standard regarding templates thinking they made a subtly ill-formed template declaration, and then throwing "typename" qualifiers around at random half-heartedly, before suspecting it might be a compiler bug, all of it triggered by a simple use of a symbol not imported from its namespace. :-) >...and a description of the host in which you have observed the >problem... x86-MSDOS. Which anyone who has read the original stuff will know. Not that there is a snowball's chance in hell that the target has any influence whatsoever on the *parser* :-) >otherwise lots of people may have to spend time re-creating the code >snippet you already have. Why you believe this is beyond me, since the code snippet (above) was in the very post you quoted IIRC, and the target, even if relevant for parser issues, has been referred to be my in the past also. Copied to egcs-bugs. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Confirmed template parsing bug: bug in error message generation. 1999-03-01 0:02 ` Alexandre Oliva [not found] ` < oriuclljxv.fsf@araguaia.dcc.unicamp.br > @ 1999-03-31 23:46 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs, egcs-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 749 bytes --] On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote: > Well, I checked and it seems in my original code, I forgot to import > math_traits from a namespace. So there are actually 2 errors, Then please post a bug report as recommended in http://egcs.cygnus.com/faq.html#bugreport , i.e., containing a single code snippet that demonstrates the problem and a description of the host in which you have observed the problem, otherwise lots of people may have to spend time re-creating the code snippet you already have. Thanks -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 @ 1999-02-28 19:05 ` rodneybrown 1999-02-28 22:53 ` rodneybrown ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: rodneybrown @ 1999-02-28 19:05 UTC (permalink / raw) To: egcs Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - the build seems to be running and pre1 worked ok. I tried changing the etc/configure to run using #!/bin/ksh to no avail. Nor did reducing the size of the cat <<EOF which seemed to match the message. Second output is from a captured run with -x turned on. configure is stressing older shells & O/Ses - gdb-4.17 and gcc-2.8.1 won't host on SCO-3.2.4 => COFF because of 4k limits in command line + environment passed to subprocesses, but I haven't seen this before on HP-UX. ../egcs-1.1.2-pre2/configure --with-gnu-as Configuring for a hppa1.1-hp-hpux9.04 host. Created "Makefile" in /user4/vsb/rdb/egcs-1.1.2-pre2.obj using "mh-frag" Links are now set up to build a native compiler for hppa1.1-hp-hpux9.04 ./../egcs-1.1.2-pre2/etc/configure: sh internal 2K buffer overflow $ pre2/configure --with-gnu-as Configuring for a hppa1.1-hp-hpux9.04 host. .. + test -f /usr/local/bin/scoinst + test -f /usr/local/bin/install + test -f /user/p.cocam/bin/ginstall + test -f /user/p.cocam/bin/scoinst + test -f /user/p.cocam/bin/install IFS= + test = set INSTALL=../pre2/etc/../install-sh -c + echo ../pre2/etc/../install-sh -c + test -z INSTALL_PROGRAM=${INSTALL} + test -z INSTALL_DATA=${INSTALL} -m 644 + trap 1 2 15 + cat ./pre2/etc/configure: sh internal 2K buffer overflow + cmp -s ../config.cache confcache + test -w ../config.cache + echo updating cache ../config.cache + cat confcache + rm -f confcache + trap rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1 1 2 15 + test xNONE = xNONE prefix=/usr/local + test xNONE = xNONE exec_prefix=${prefix} + test x../pre2/etc = x. + trap rm -f $CONFIG_STATUS conftest*; exit 1 1 2 15 + cat + + sedtr -f\012 conftest.defs confdefs.h .. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 1999-02-28 19:05 ` Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 rodneybrown @ 1999-02-28 22:53 ` rodneybrown 1999-03-01 9:05 ` Alexandre Oliva 1999-03-01 9:18 ` Jeffrey A Law 2 siblings, 0 replies; 268+ messages in thread From: rodneybrown @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - the build seems to be running and pre1 worked ok. I tried changing the etc/configure to run using #!/bin/ksh to no avail. Nor did reducing the size of the cat <<EOF which seemed to match the message. Second output is from a captured run with -x turned on. configure is stressing older shells & O/Ses - gdb-4.17 and gcc-2.8.1 won't host on SCO-3.2.4 => COFF because of 4k limits in command line + environment passed to subprocesses, but I haven't seen this before on HP-UX. ../egcs-1.1.2-pre2/configure --with-gnu-as Configuring for a hppa1.1-hp-hpux9.04 host. Created "Makefile" in /user4/vsb/rdb/egcs-1.1.2-pre2.obj using "mh-frag" Links are now set up to build a native compiler for hppa1.1-hp-hpux9.04 ./../egcs-1.1.2-pre2/etc/configure: sh internal 2K buffer overflow $ pre2/configure --with-gnu-as Configuring for a hppa1.1-hp-hpux9.04 host. .. + test -f /usr/local/bin/scoinst + test -f /usr/local/bin/install + test -f /user/p.cocam/bin/ginstall + test -f /user/p.cocam/bin/scoinst + test -f /user/p.cocam/bin/install IFS= + test = set INSTALL=../pre2/etc/../install-sh -c + echo ../pre2/etc/../install-sh -c + test -z INSTALL_PROGRAM=${INSTALL} + test -z INSTALL_DATA=${INSTALL} -m 644 + trap 1 2 15 + cat ./pre2/etc/configure: sh internal 2K buffer overflow + cmp -s ../config.cache confcache + test -w ../config.cache + echo updating cache ../config.cache + cat confcache + rm -f confcache + trap rm -fr conftest* confdefs* core core.* *.core $ac_clean_files; exit 1 1 2 15 + test xNONE = xNONE prefix=/usr/local + test xNONE = xNONE exec_prefix=${prefix} + test x../pre2/etc = x. + trap rm -f $CONFIG_STATUS conftest*; exit 1 1 2 15 + cat + + sedtr -f\012 conftest.defs confdefs.h .. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 1999-02-28 19:05 ` Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 rodneybrown 1999-02-28 22:53 ` rodneybrown @ 1999-03-01 9:05 ` Alexandre Oliva [not found] ` < orogmdf8jw.fsf@araguaia.dcc.unicamp.br > 1999-03-31 23:46 ` Alexandre Oliva 1999-03-01 9:18 ` Jeffrey A Law 2 siblings, 2 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-01 9:05 UTC (permalink / raw) To: rodneybrown; +Cc: egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 478 bytes --] On Mar 1, 1999, rodneybrown@pmsc.com wrote: > Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - > the build seems to be running and pre1 worked ok. I tried changing > the etc/configure to run using #!/bin/ksh to no avail. Set CONFIG_SHELL -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < orogmdf8jw.fsf@araguaia.dcc.unicamp.br >]
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 [not found] ` < orogmdf8jw.fsf@araguaia.dcc.unicamp.br > @ 1999-03-01 9:14 ` Franz Sirl 1999-03-01 9:32 ` Alexandre Oliva 1999-03-31 23:46 ` Franz Sirl 0 siblings, 2 replies; 268+ messages in thread From: Franz Sirl @ 1999-03-01 9:14 UTC (permalink / raw) To: Alexandre Oliva; +Cc: rodneybrown, egcs At 18:01 01.03.99 , Alexandre Oliva wrote: >On Mar 1, 1999, rodneybrown@pmsc.com wrote: > >> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - >> the build seems to be running and pre1 worked ok. I tried changing >> the etc/configure to run using #!/bin/ksh to no avail. > >Set CONFIG_SHELL Hmm, will this still work as expected? In the diff from 1.1.1 to 1.1.2pre2 I noticed some entries like below in the texinfo subdir. Franz. Index: texinfo/lib/Makefile.in --- texinfo/lib/Makefile.in 1998/04/02 03:45:22 1.4 +++ texinfo/lib/Makefile.in 1999/02/24 02:45:41 1.4.2.1 @@ -1,4 +1,4 @@ -# Makefile.in generated automatically by automake 1.2e from Makefile.am +# Makefile.in generated automatically by automake 1.3 from Makefile.am # Copyright (C) 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation @@ -11,7 +11,7 @@ # PARTICULAR PURPOSE. -SHELL = @SHELL@ +SHELL = /bin/sh ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 1999-03-01 9:14 ` Franz Sirl @ 1999-03-01 9:32 ` Alexandre Oliva 1999-03-31 23:46 ` Alexandre Oliva 1999-03-31 23:46 ` Franz Sirl 1 sibling, 1 reply; 268+ messages in thread From: Alexandre Oliva @ 1999-03-01 9:32 UTC (permalink / raw) To: Franz Sirl; +Cc: rodneybrown, egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1052 bytes --] On Mar 1, 1999, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote: > At 18:01 01.03.99 , Alexandre Oliva wrote: >> On Mar 1, 1999, rodneybrown@pmsc.com wrote: >> >>> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - >>> the build seems to be running and pre1 worked ok. I tried changing >>> the etc/configure to run using #!/bin/ksh to no avail. >> >> Set CONFIG_SHELL > Hmm, will this still work as expected? Yep, this is only for configure time. > --- texinfo/lib/Makefile.in 1998/04/02 03:45:22 1.4 > +++ texinfo/lib/Makefile.in 1999/02/24 02:45:41 1.4.2.1 > -SHELL = @SHELL@ > +SHELL = /bin/sh I don't think this would be a problem, but it's strange that automake 1.3 does not use @SHELL@ as defined by configure... Well, most commands it runs are so simple that it shouldn't matter. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 1999-03-01 9:32 ` Alexandre Oliva @ 1999-03-31 23:46 ` Alexandre Oliva 0 siblings, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw) To: Franz Sirl; +Cc: rodneybrown, egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1053 bytes --] On Mar 1, 1999, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote: > At 18:01 01.03.99 , Alexandre Oliva wrote: >> On Mar 1, 1999, rodneybrown@pmsc.com wrote: >> >>> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - >>> the build seems to be running and pre1 worked ok. I tried changing >>> the etc/configure to run using #!/bin/ksh to no avail. >> >> Set CONFIG_SHELL > Hmm, will this still work as expected? Yep, this is only for configure time. > --- texinfo/lib/Makefile.in 1998/04/02 03:45:22 1.4 > +++ texinfo/lib/Makefile.in 1999/02/24 02:45:41 1.4.2.1 > -SHELL = @SHELL@ > +SHELL = /bin/sh I don't think this would be a problem, but it's strange that automake 1.3 does not use @SHELL@ as defined by configure... Well, most commands it runs are so simple that it shouldn't matter. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 1999-03-01 9:14 ` Franz Sirl 1999-03-01 9:32 ` Alexandre Oliva @ 1999-03-31 23:46 ` Franz Sirl 1 sibling, 0 replies; 268+ messages in thread From: Franz Sirl @ 1999-03-31 23:46 UTC (permalink / raw) To: Alexandre Oliva; +Cc: rodneybrown, egcs At 18:01 01.03.99 , Alexandre Oliva wrote: >On Mar 1, 1999, rodneybrown@pmsc.com wrote: > >> Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - >> the build seems to be running and pre1 worked ok. I tried changing >> the etc/configure to run using #!/bin/ksh to no avail. > >Set CONFIG_SHELL Hmm, will this still work as expected? In the diff from 1.1.1 to 1.1.2pre2 I noticed some entries like below in the texinfo subdir. Franz. Index: texinfo/lib/Makefile.in --- texinfo/lib/Makefile.in 1998/04/02 03:45:22 1.4 +++ texinfo/lib/Makefile.in 1999/02/24 02:45:41 1.4.2.1 @@ -1,4 +1,4 @@ -# Makefile.in generated automatically by automake 1.2e from Makefile.am +# Makefile.in generated automatically by automake 1.3 from Makefile.am # Copyright (C) 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation @@ -11,7 +11,7 @@ # PARTICULAR PURPOSE. -SHELL = @SHELL@ +SHELL = /bin/sh ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 1999-03-01 9:05 ` Alexandre Oliva [not found] ` < orogmdf8jw.fsf@araguaia.dcc.unicamp.br > @ 1999-03-31 23:46 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw) To: rodneybrown; +Cc: egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 479 bytes --] On Mar 1, 1999, rodneybrown@pmsc.com wrote: > Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - > the build seems to be running and pre1 worked ok. I tried changing > the etc/configure to run using #!/bin/ksh to no avail. Set CONFIG_SHELL -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 1999-02-28 19:05 ` Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 rodneybrown 1999-02-28 22:53 ` rodneybrown 1999-03-01 9:05 ` Alexandre Oliva @ 1999-03-01 9:18 ` Jeffrey A Law 1999-03-31 23:46 ` Jeffrey A Law 2 siblings, 1 reply; 268+ messages in thread From: Jeffrey A Law @ 1999-03-01 9:18 UTC (permalink / raw) To: rodneybrown; +Cc: egcs In message <9902289202.AA920257535@cc.pmsc.com>you write: > > Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - > the build seems to be running and pre1 worked ok. This is a bug in the hpux shell. It only effects building of the config.cache file. I believe if you set CONFIG_SHELL and/or SHELL in your environment will work around this bug. See the hpux entries at http://egcs.cygnus.com/install/specific.html jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 1999-03-01 9:18 ` Jeffrey A Law @ 1999-03-31 23:46 ` Jeffrey A Law 0 siblings, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-03-31 23:46 UTC (permalink / raw) To: rodneybrown; +Cc: egcs In message <9902289202.AA920257535@cc.pmsc.com>you write: > > Configuring on HP-UX 9.04 gave a 'sh internal 2K buffer overflow' - > the build seems to be running and pre1 worked ok. This is a bug in the hpux shell. It only effects building of the config.cache file. I believe if you set CONFIG_SHELL and/or SHELL in your environment will work around this bug. See the hpux entries at http://egcs.cygnus.com/install/specific.html jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <(EST)>]
* Occasional use of GNU ld problems @ 1999-06-25 17:54 ` Brad Lucier 1999-06-29 2:06 ` Alexandre Oliva 1999-06-30 15:43 ` Brad Lucier 0 siblings, 2 replies; 268+ messages in thread From: Brad Lucier @ 1999-06-25 17:54 UTC (permalink / raw) To: egcs; +Cc: lucier I'm trying to compile Cilk (a parallel language based on C from theory.lcs.mit.edu), which requires GNU ld, which I usually don't use, so I installed it in /opt/binutils-2.9.1 on my Solaris 2.5.1 box. So now I want egcs to see it and I find the FAQ advice: GCC can not find GNU as/GNU ld To ensure that EGCS finds the GNU assembler (the GNU loader), which are required by some configurations, you should configure these with the same --prefix option as you used for EGCS. Then build & install GNU as (GNU ld) and proceed with building EGCS. Another alternative is to create links to GNU as and ld in any of the directories printed by the command `gcc -print-search-dirs | grep '^programs:''. The link to `ld' should be named `real-ld' if `ld' already exists. Pre-1.2 snapshots of egcs allow you to specify the full pathname of the assembler and the linker to use. The configure flags are `--with-as=/path/to/as' and `--with-ld=/path/to/ld'. EGCS will try to use these pathnames before looking for `as' or `(real-)ld' in the standard search dirs. If, at configure-time, the specified programs are found to be GNU utilities, `--with-gnu-as' and `--with-gnu-ld' need not be used; these flags will be auto-detected. <end of faq advice> Alternative 2 is a real pain (although I suppose I could write a script to do), and I'm working on the first alternative now, which I don't really want to do, because I'm going to be building a series of temporary snapshots of egcs in a directory (binutils) that otherwise I don't want to fool around with. But first I tried adding the '-B /opt/binutils-2.9.1/bin' option to LDFLAGS in the makefiles for Cilk, which seemed to allow egcs to see GNU ld, but then I had to rerun configure for some reason, and configure uses 'gcc -print-prog-name=ld' to find out which ld gcc uses, and the -B option doesn't seem to affect which load program is printed: bessel-125% gcc -B /opt/binutils-2.9.1/bin -print-prog-name=ld /usr/ccs/bin/ld So the configure for Cilk bombs and says I need to use GNU ld. So, I really think there should be an easier way for egcs to use the GNU linker for occasional packages that need it. Brad Lucier lucier@math.purdue.edu ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Occasional use of GNU ld problems 1999-06-25 17:54 ` Occasional use of GNU ld problems Brad Lucier @ 1999-06-29 2:06 ` Alexandre Oliva 1999-06-29 2:20 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva 1999-06-30 15:43 ` Brad Lucier 1 sibling, 2 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-06-29 2:06 UTC (permalink / raw) To: Brad Lucier; +Cc: egcs On Jun 25, 1999, Brad Lucier <lucier@math.purdue.edu> wrote: > But first I tried adding the '-B /opt/binutils-2.9.1/bin' It should end with a slash, and I'm not sure a space after the `B' is supported: -B/opt/binutils-2.9.1/bin/ -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Occasional use of GNU ld problems 1999-06-29 2:06 ` Alexandre Oliva @ 1999-06-29 2:20 ` Franz Sirl 1999-06-30 15:43 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva 1 sibling, 1 reply; 268+ messages in thread From: Franz Sirl @ 1999-06-29 2:20 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Brad Lucier, egcs At 11:06 29.06.99 , Alexandre Oliva wrote: >On Jun 25, 1999, Brad Lucier <lucier@math.purdue.edu> wrote: > > > But first I tried adding the '-B /opt/binutils-2.9.1/bin' > >It should end with a slash, and I'm not sure a space after the `B' is >supported: -B/opt/binutils-2.9.1/bin/ JFYI, the space is supported. I use everyday, cause otherwise commandline completion with TAB and using ~ as an abbreviation don't work. Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Occasional use of GNU ld problems 1999-06-29 2:20 ` Franz Sirl @ 1999-06-30 15:43 ` Franz Sirl 0 siblings, 0 replies; 268+ messages in thread From: Franz Sirl @ 1999-06-30 15:43 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Brad Lucier, egcs At 11:06 29.06.99 , Alexandre Oliva wrote: >On Jun 25, 1999, Brad Lucier <lucier@math.purdue.edu> wrote: > > > But first I tried adding the '-B /opt/binutils-2.9.1/bin' > >It should end with a slash, and I'm not sure a space after the `B' is >supported: -B/opt/binutils-2.9.1/bin/ JFYI, the space is supported. I use everyday, cause otherwise commandline completion with TAB and using ~ as an abbreviation don't work. Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Occasional use of GNU ld problems 1999-06-29 2:06 ` Alexandre Oliva 1999-06-29 2:20 ` Franz Sirl @ 1999-06-30 15:43 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-06-30 15:43 UTC (permalink / raw) To: Brad Lucier; +Cc: egcs On Jun 25, 1999, Brad Lucier <lucier@math.purdue.edu> wrote: > But first I tried adding the '-B /opt/binutils-2.9.1/bin' It should end with a slash, and I'm not sure a space after the `B' is supported: -B/opt/binutils-2.9.1/bin/ -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 268+ messages in thread
* Occasional use of GNU ld problems 1999-06-25 17:54 ` Occasional use of GNU ld problems Brad Lucier 1999-06-29 2:06 ` Alexandre Oliva @ 1999-06-30 15:43 ` Brad Lucier 1 sibling, 0 replies; 268+ messages in thread From: Brad Lucier @ 1999-06-30 15:43 UTC (permalink / raw) To: egcs; +Cc: lucier I'm trying to compile Cilk (a parallel language based on C from theory.lcs.mit.edu), which requires GNU ld, which I usually don't use, so I installed it in /opt/binutils-2.9.1 on my Solaris 2.5.1 box. So now I want egcs to see it and I find the FAQ advice: GCC can not find GNU as/GNU ld To ensure that EGCS finds the GNU assembler (the GNU loader), which are required by some configurations, you should configure these with the same --prefix option as you used for EGCS. Then build & install GNU as (GNU ld) and proceed with building EGCS. Another alternative is to create links to GNU as and ld in any of the directories printed by the command `gcc -print-search-dirs | grep '^programs:''. The link to `ld' should be named `real-ld' if `ld' already exists. Pre-1.2 snapshots of egcs allow you to specify the full pathname of the assembler and the linker to use. The configure flags are `--with-as=/path/to/as' and `--with-ld=/path/to/ld'. EGCS will try to use these pathnames before looking for `as' or `(real-)ld' in the standard search dirs. If, at configure-time, the specified programs are found to be GNU utilities, `--with-gnu-as' and `--with-gnu-ld' need not be used; these flags will be auto-detected. <end of faq advice> Alternative 2 is a real pain (although I suppose I could write a script to do), and I'm working on the first alternative now, which I don't really want to do, because I'm going to be building a series of temporary snapshots of egcs in a directory (binutils) that otherwise I don't want to fool around with. But first I tried adding the '-B /opt/binutils-2.9.1/bin' option to LDFLAGS in the makefiles for Cilk, which seemed to allow egcs to see GNU ld, but then I had to rerun configure for some reason, and configure uses 'gcc -print-prog-name=ld' to find out which ld gcc uses, and the -B option doesn't seem to affect which load program is printed: bessel-125% gcc -B /opt/binutils-2.9.1/bin -print-prog-name=ld /usr/ccs/bin/ld So the configure for Cilk bombs and says I need to use GNU ld. So, I really think there should be an easier way for egcs to use the GNU linker for occasional packages that need it. Brad Lucier lucier@math.purdue.edu ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <04:47:24>]
[parent not found: <-0800>]
* C++ default copy ctor not optimal @ 1999-02-12 3:00 ` Sylvain Pion [not found] ` < 19990212120037.C13091@rigel.inria.fr > ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Sylvain Pion @ 1999-02-12 3:00 UTC (permalink / raw) To: EGCS list Hi, I've got a class with 2 "double" data members (like a complex). The default copy ctor should be a memberwise copy, but it is slower (on x86) than when I declare it explicitly. In fact, mine generates copies using the FPU, whereas the default does something like a memcopy, using more 32bits "mov"s, and thus is slower. It's not a big problem, but is there a way to "fix" this, or is it considered not safe enough, or too hard ? -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 19990212120037.C13091@rigel.inria.fr >]
* Re: C++ default copy ctor not optimal [not found] ` < 19990212120037.C13091@rigel.inria.fr > @ 1999-02-12 4:46 ` Sylvain Pion 1999-02-28 22:53 ` Sylvain Pion 0 siblings, 1 reply; 268+ messages in thread From: Sylvain Pion @ 1999-02-12 4:46 UTC (permalink / raw) To: EGCS list On Fri, Feb 12, 1999 at 12:00:37PM +0100, Sylvain Pion wrote: > I've got a class with 2 "double" data members (like a complex). > The default copy ctor should be a memberwise copy, but it is slower (on x86) > than when I declare it explicitly. In fact, mine generates copies using the > FPU, whereas the default does something like a memcopy, using more 32bits > "mov"s, and thus is slower. In case I was not explicit enough, the test case is the following C++ program: ---------------- struct IA { double i,s; #ifdef TEST IA () {} IA (const IA & d) : i(d.i), s(d.s) {} IA & operator=(const IA & d) {i = d.i; s = d.s; return *this; } #endif }; int main() { IA a; IA b = a; } ---------------- If you compile with "g++ -O2", you get: main: .LFB1: pushl %ebp .LCFI0: movl %esp,%ebp .LCFI1: subl $32,%esp .LCFI2: movl -16(%ebp),%eax movl %eax,-32(%ebp) movl -12(%ebp),%eax movl %eax,-28(%ebp) movl -8(%ebp),%eax movl %eax,-24(%ebp) movl -4(%ebp),%eax movl %eax,-20(%ebp) xorl %eax,%eax movl %ebp,%esp popl %ebp ret And if you compile with "g++ -DTEST -O2": main: .LFB1: pushl %ebp .LCFI0: movl %esp,%ebp .LCFI1: subl $32,%esp .LCFI2: fldl -16(%ebp) fstpl -32(%ebp) fldl -8(%ebp) fstpl -24(%ebp) xorl %eax,%eax movl %ebp,%esp popl %ebp ret It is clearly the second one I prefer :). It is tested with the 19990208 snapshot, but it's basically the same with all versions I've tried so far. G++ 2.8.1 doesn't use the FPU even in the second case. And it's on Linux-2.0/libc5/x86. I've not tested other archs. I can understand that it's maybe not safe to copy a 64bits memory area via the FPU, when it's precision mode is set to single float (maybe it might trunc it, or raise an exception if it's a NaN or anything ?). However, if we are allowed to copy doubles via the FPU, then it might be a valid "optimisation" to propagate it in such cases. However, I can live with the 2 additionnal lines of code in my class to get this optimisation. I was just curious why it's done this way. -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-12 4:46 ` Sylvain Pion @ 1999-02-28 22:53 ` Sylvain Pion 0 siblings, 0 replies; 268+ messages in thread From: Sylvain Pion @ 1999-02-28 22:53 UTC (permalink / raw) To: EGCS list On Fri, Feb 12, 1999 at 12:00:37PM +0100, Sylvain Pion wrote: > I've got a class with 2 "double" data members (like a complex). > The default copy ctor should be a memberwise copy, but it is slower (on x86) > than when I declare it explicitly. In fact, mine generates copies using the > FPU, whereas the default does something like a memcopy, using more 32bits > "mov"s, and thus is slower. In case I was not explicit enough, the test case is the following C++ program: ---------------- struct IA { double i,s; #ifdef TEST IA () {} IA (const IA & d) : i(d.i), s(d.s) {} IA & operator=(const IA & d) {i = d.i; s = d.s; return *this; } #endif }; int main() { IA a; IA b = a; } ---------------- If you compile with "g++ -O2", you get: main: .LFB1: pushl %ebp .LCFI0: movl %esp,%ebp .LCFI1: subl $32,%esp .LCFI2: movl -16(%ebp),%eax movl %eax,-32(%ebp) movl -12(%ebp),%eax movl %eax,-28(%ebp) movl -8(%ebp),%eax movl %eax,-24(%ebp) movl -4(%ebp),%eax movl %eax,-20(%ebp) xorl %eax,%eax movl %ebp,%esp popl %ebp ret And if you compile with "g++ -DTEST -O2": main: .LFB1: pushl %ebp .LCFI0: movl %esp,%ebp .LCFI1: subl $32,%esp .LCFI2: fldl -16(%ebp) fstpl -32(%ebp) fldl -8(%ebp) fstpl -24(%ebp) xorl %eax,%eax movl %ebp,%esp popl %ebp ret It is clearly the second one I prefer :). It is tested with the 19990208 snapshot, but it's basically the same with all versions I've tried so far. G++ 2.8.1 doesn't use the FPU even in the second case. And it's on Linux-2.0/libc5/x86. I've not tested other archs. I can understand that it's maybe not safe to copy a 64bits memory area via the FPU, when it's precision mode is set to single float (maybe it might trunc it, or raise an exception if it's a NaN or anything ?). However, if we are allowed to copy doubles via the FPU, then it might be a valid "optimisation" to propagate it in such cases. However, I can live with the 2 additionnal lines of code in my class to get this optimisation. I was just curious why it's done this way. -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <19990212134607.F13091.cygnus.egcs@rigel.inria.fr>]
* Re: C++ default copy ctor not optimal [not found] ` <19990212134607.F13091.cygnus.egcs@rigel.inria.fr> @ 1999-02-12 13:41 ` Jason Merrill [not found] ` <3.0.6.32.19990212172607.00844860.cygnus.egcs@pop.netaddress.com> ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-12 13:41 UTC (permalink / raw) To: Sylvain Pion; +Cc: egcs This is a backend issue; the frontend just tells the backend "copy this struct". The insns used are up to the backend. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <3.0.6.32.19990212172607.00844860.cygnus.egcs@pop.netaddress.com>]
* Re: C++ default copy ctor not optimal [not found] ` <3.0.6.32.19990212172607.00844860.cygnus.egcs@pop.netaddress.com> @ 1999-02-12 15:27 ` Jason Merrill 1999-02-28 22:53 ` Jason Merrill 0 siblings, 1 reply; 268+ messages in thread From: Jason Merrill @ 1999-02-12 15:27 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs >>>>> Paul Derbyshire <pderbysh@usa.net> writes: > At 01:41 PM 2/12/99 -0800, you wrote: >> This is a backend issue; the frontend just tells the backend "copy this >> struct". The insns used are up to the backend. > Was he disputing that? No, my mail was more for the benefit of other compiler engineers who might be listening. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-12 15:27 ` Jason Merrill @ 1999-02-28 22:53 ` Jason Merrill 0 siblings, 0 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs >>>>> Paul Derbyshire <pderbysh@usa.net> writes: > At 01:41 PM 2/12/99 -0800, you wrote: >> This is a backend issue; the frontend just tells the backend "copy this >> struct". The insns used are up to the backend. > Was he disputing that? No, my mail was more for the benefit of other compiler engineers who might be listening. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < u9d83fl2q8.fsf@yorick.cygnus.com >]
* Re: C++ default copy ctor not optimal [not found] ` < u9d83fl2q8.fsf@yorick.cygnus.com > @ 1999-02-12 14:26 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-14 10:57 ` Sylvain Pion 1 sibling, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-12 14:26 UTC (permalink / raw) To: egcs At 01:41 PM 2/12/99 -0800, you wrote: >This is a backend issue; the frontend just tells the backend "copy this >struct". The insns used are up to the backend. Was he disputing that? -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-12 14:26 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 01:41 PM 2/12/99 -0800, you wrote: >This is a backend issue; the frontend just tells the backend "copy this >struct". The insns used are up to the backend. Was he disputing that? -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal [not found] ` < u9d83fl2q8.fsf@yorick.cygnus.com > 1999-02-12 14:26 ` Paul Derbyshire @ 1999-02-14 10:57 ` Sylvain Pion 1999-02-14 21:01 ` Jason Merrill 1999-02-28 22:53 ` Sylvain Pion 1 sibling, 2 replies; 268+ messages in thread From: Sylvain Pion @ 1999-02-14 10:57 UTC (permalink / raw) To: Jason Merrill; +Cc: egcs On Fri, Feb 12, 1999 at 01:41:03PM -0800, Jason Merrill wrote: > This is a backend issue; the frontend just tells the backend "copy this > struct". The insns used are up to the backend. Ok, then is it possible to have the backend do some kind of memcpy using the FP registers (this reminds me some old linux kernel patch never included...) ? What are the problems with this approach ? -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-14 10:57 ` Sylvain Pion @ 1999-02-14 21:01 ` Jason Merrill [not found] ` < u9iud4jm52.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Sylvain Pion 1 sibling, 2 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-14 21:01 UTC (permalink / raw) To: Sylvain Pion; +Cc: egcs >>>>> Sylvain Pion <Sylvain.Pion@sophia.inria.fr> writes: > On Fri, Feb 12, 1999 at 01:41:03PM -0800, Jason Merrill wrote: >> This is a backend issue; the frontend just tells the backend "copy this >> struct". The insns used are up to the backend. > Ok, then is it possible to have the backend do some kind of memcpy using > the FP registers (this reminds me some old linux kernel patch never > included...) ? What are the problems with this approach ? The backend should be able to determine that the struct it's copying is composed of FP values and use FP instructions for the copy. I don't think we can do that in general on the x86 because the FPU faults if you try to load an invalid FP value, but I may be remembering wrong. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < u9iud4jm52.fsf@yorick.cygnus.com >]
* Re: C++ default copy ctor not optimal [not found] ` < u9iud4jm52.fsf@yorick.cygnus.com > @ 1999-02-15 17:15 ` Richard Henderson [not found] ` < 19990215171524.A19063@cygnus.com > 1999-02-28 22:53 ` Richard Henderson 0 siblings, 2 replies; 268+ messages in thread From: Richard Henderson @ 1999-02-15 17:15 UTC (permalink / raw) To: Jason Merrill, Sylvain Pion; +Cc: egcs On Sun, Feb 14, 1999 at 09:01:29PM -0800, Jason Merrill wrote: > The backend should be able to determine that the struct it's copying is > composed of FP values and use FP instructions for the copy. I don't think > we can do that in general on the x86 because the FPU faults if you try to > load an invalid FP value, but I may be remembering wrong. The x86 fpu can load DImode values without faulting, and since the frational part of the extended double register is 64-bits wide, we don't lose bits. r~ ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 19990215171524.A19063@cygnus.com >]
* Re: C++ default copy ctor not optimal [not found] ` < 19990215171524.A19063@cygnus.com > @ 1999-02-15 20:14 ` Jeffrey A Law [not found] ` < 14555.919137968@upchuck > 1999-02-28 22:53 ` Jeffrey A Law 1999-02-16 10:08 ` Joe Buck 1 sibling, 2 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-15 20:14 UTC (permalink / raw) To: Richard Henderson; +Cc: Jason Merrill, Sylvain Pion, egcs In message < 19990215171524.A19063@cygnus.com >you write: > On Sun, Feb 14, 1999 at 09:01:29PM -0800, Jason Merrill wrote: > > The backend should be able to determine that the struct it's copying is > > composed of FP values and use FP instructions for the copy. I don't thin > k > > we can do that in general on the x86 because the FPU faults if you try to > > load an invalid FP value, but I may be remembering wrong. > > The x86 fpu can load DImode values without faulting, and since > the frational part of the extended double register is 64-bits > wide, we don't lose bits. But is it profitable? Particularly in cases where the addresses are not 64bit aligned? jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 14555.919137968@upchuck >]
* Re: C++ default copy ctor not optimal [not found] ` < 14555.919137968@upchuck > @ 1999-02-15 21:39 ` Richard Henderson [not found] ` < 19990215213927.A19254@cygnus.com > 1999-02-28 22:53 ` Richard Henderson 0 siblings, 2 replies; 268+ messages in thread From: Richard Henderson @ 1999-02-15 21:39 UTC (permalink / raw) To: law; +Cc: Jason Merrill, Sylvain Pion, egcs On Mon, Feb 15, 1999 at 09:06:08PM -0700, Jeffrey A Law wrote: > > The x86 fpu can load DImode values without faulting, and since > > the frational part of the extended double register is 64-bits > > wide, we don't lose bits. > But is it profitable? Particularly in cases where the addresses are > not 64bit aligned? Certainly not when alignment is not to be had. But on Pentiums, it can speed things up quite a bit. I'm not sure what effect it has on p2. Probably still a good thing in small doses. Larger copies should use rep movsl, as the microcode does neat cache tricks. r~ ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 19990215213927.A19254@cygnus.com >]
* Re: C++ default copy ctor not optimal [not found] ` < 19990215213927.A19254@cygnus.com > @ 1999-02-16 0:10 ` Sylvain Pion 1999-02-28 22:53 ` Sylvain Pion 0 siblings, 1 reply; 268+ messages in thread From: Sylvain Pion @ 1999-02-16 0:10 UTC (permalink / raw) To: Richard Henderson; +Cc: law, Jason Merrill, egcs On Mon, Feb 15, 1999 at 09:39:27PM -0800, Richard Henderson wrote: > On Mon, Feb 15, 1999 at 09:06:08PM -0700, Jeffrey A Law wrote: > > > The x86 fpu can load DImode values without faulting, and since > > > the frational part of the extended double register is 64-bits > > > wide, we don't lose bits. "can" ? Does it mean it depends on some flags in the FPCW ? What about if the FPU is in MMX mode ? I guess it won't work, will it ? In MMX mode, we can use MMX insns, but the compiler doesn't know in which mode we are. > > But is it profitable? Particularly in cases where the addresses are > > not 64bit aligned? > > Certainly not when alignment is not to be had. But on Pentiums, > it can speed things up quite a bit. Yes. The speed up is noticable for my stuff, so I guess that using it more widely is a good idea, if it's feasible. The speed difference is also very important in case the alignement is not correct. > I'm not sure what effect it has on p2. Probably still a good thing > in small doses. Larger copies should use rep movsl, as the microcode > does neat cache tricks. I don't know, but the FP memcpy() patch for the linux kernel worked very well (at least on pentiums), and it was for large areas. -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-16 0:10 ` Sylvain Pion @ 1999-02-28 22:53 ` Sylvain Pion 0 siblings, 0 replies; 268+ messages in thread From: Sylvain Pion @ 1999-02-28 22:53 UTC (permalink / raw) To: Richard Henderson; +Cc: law, Jason Merrill, egcs On Mon, Feb 15, 1999 at 09:39:27PM -0800, Richard Henderson wrote: > On Mon, Feb 15, 1999 at 09:06:08PM -0700, Jeffrey A Law wrote: > > > The x86 fpu can load DImode values without faulting, and since > > > the frational part of the extended double register is 64-bits > > > wide, we don't lose bits. "can" ? Does it mean it depends on some flags in the FPCW ? What about if the FPU is in MMX mode ? I guess it won't work, will it ? In MMX mode, we can use MMX insns, but the compiler doesn't know in which mode we are. > > But is it profitable? Particularly in cases where the addresses are > > not 64bit aligned? > > Certainly not when alignment is not to be had. But on Pentiums, > it can speed things up quite a bit. Yes. The speed up is noticable for my stuff, so I guess that using it more widely is a good idea, if it's feasible. The speed difference is also very important in case the alignement is not correct. > I'm not sure what effect it has on p2. Probably still a good thing > in small doses. Larger copies should use rep movsl, as the microcode > does neat cache tricks. I don't know, but the FP memcpy() patch for the linux kernel worked very well (at least on pentiums), and it was for large areas. -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-15 21:39 ` Richard Henderson [not found] ` < 19990215213927.A19254@cygnus.com > @ 1999-02-28 22:53 ` Richard Henderson 1 sibling, 0 replies; 268+ messages in thread From: Richard Henderson @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: Jason Merrill, Sylvain Pion, egcs On Mon, Feb 15, 1999 at 09:06:08PM -0700, Jeffrey A Law wrote: > > The x86 fpu can load DImode values without faulting, and since > > the frational part of the extended double register is 64-bits > > wide, we don't lose bits. > But is it profitable? Particularly in cases where the addresses are > not 64bit aligned? Certainly not when alignment is not to be had. But on Pentiums, it can speed things up quite a bit. I'm not sure what effect it has on p2. Probably still a good thing in small doses. Larger copies should use rep movsl, as the microcode does neat cache tricks. r~ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-15 20:14 ` Jeffrey A Law [not found] ` < 14555.919137968@upchuck > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Richard Henderson; +Cc: Jason Merrill, Sylvain Pion, egcs In message < 19990215171524.A19063@cygnus.com >you write: > On Sun, Feb 14, 1999 at 09:01:29PM -0800, Jason Merrill wrote: > > The backend should be able to determine that the struct it's copying is > > composed of FP values and use FP instructions for the copy. I don't thin > k > > we can do that in general on the x86 because the FPU faults if you try to > > load an invalid FP value, but I may be remembering wrong. > > The x86 fpu can load DImode values without faulting, and since > the frational part of the extended double register is 64-bits > wide, we don't lose bits. But is it profitable? Particularly in cases where the addresses are not 64bit aligned? jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal [not found] ` < 19990215171524.A19063@cygnus.com > 1999-02-15 20:14 ` Jeffrey A Law @ 1999-02-16 10:08 ` Joe Buck [not found] ` < 199902161807.KAA19010@atrus.synopsys.com > 1999-02-28 22:53 ` Joe Buck 1 sibling, 2 replies; 268+ messages in thread From: Joe Buck @ 1999-02-16 10:08 UTC (permalink / raw) To: Richard Henderson; +Cc: jason, Sylvain.Pion, egcs Richard Henderson writes: > The x86 fpu can load DImode values without faulting, and since > the frational part of the extended double register is 64-bits > wide, we don't lose bits. But doesn't that assume certain settings of IEEE modes? (I'm not an expert on IEEE signalling, so I'm not sure about the answer to this question). ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 199902161807.KAA19010@atrus.synopsys.com >]
* Re: C++ default copy ctor not optimal [not found] ` < 199902161807.KAA19010@atrus.synopsys.com > @ 1999-02-16 10:18 ` Richard Henderson [not found] ` < 19990216101811.A19900@cygnus.com > 1999-02-28 22:53 ` Richard Henderson 0 siblings, 2 replies; 268+ messages in thread From: Richard Henderson @ 1999-02-16 10:18 UTC (permalink / raw) To: Joe Buck; +Cc: jason, Sylvain.Pion, egcs On Tue, Feb 16, 1999 at 10:07:26AM -0800, Joe Buck wrote: > But doesn't that assume certain settings of IEEE modes? (I'm not an > expert on IEEE signalling, so I'm not sure about the answer to this > question). No. You're not loading a double, you're loading a long long. Moreover, no rounding occurs with just the load, so you can safely move around 64-bit hunks. r~ ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 19990216101811.A19900@cygnus.com >]
* Re: C++ default copy ctor not optimal [not found] ` < 19990216101811.A19900@cygnus.com > @ 1999-02-16 10:33 ` Sylvain Pion 1999-02-28 22:53 ` Sylvain Pion 0 siblings, 1 reply; 268+ messages in thread From: Sylvain Pion @ 1999-02-16 10:33 UTC (permalink / raw) To: Richard Henderson; +Cc: Joe Buck, jason, egcs On Tue, Feb 16, 1999 at 10:18:11AM -0800, Richard Henderson wrote: > On Tue, Feb 16, 1999 at 10:07:26AM -0800, Joe Buck wrote: > > But doesn't that assume certain settings of IEEE modes? (I'm not an > > expert on IEEE signalling, so I'm not sure about the answer to this > > question). > > No. You're not loading a double, you're loading a long long. > Moreover, no rounding occurs with just the load, so you can > safely move around 64-bit hunks. I get it ! You mean using fild/fist and not fld/fst. -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-16 10:33 ` Sylvain Pion @ 1999-02-28 22:53 ` Sylvain Pion 0 siblings, 0 replies; 268+ messages in thread From: Sylvain Pion @ 1999-02-28 22:53 UTC (permalink / raw) To: Richard Henderson; +Cc: Joe Buck, jason, egcs On Tue, Feb 16, 1999 at 10:18:11AM -0800, Richard Henderson wrote: > On Tue, Feb 16, 1999 at 10:07:26AM -0800, Joe Buck wrote: > > But doesn't that assume certain settings of IEEE modes? (I'm not an > > expert on IEEE signalling, so I'm not sure about the answer to this > > question). > > No. You're not loading a double, you're loading a long long. > Moreover, no rounding occurs with just the load, so you can > safely move around 64-bit hunks. I get it ! You mean using fild/fist and not fld/fst. -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-16 10:18 ` Richard Henderson [not found] ` < 19990216101811.A19900@cygnus.com > @ 1999-02-28 22:53 ` Richard Henderson 1 sibling, 0 replies; 268+ messages in thread From: Richard Henderson @ 1999-02-28 22:53 UTC (permalink / raw) To: Joe Buck; +Cc: jason, Sylvain.Pion, egcs On Tue, Feb 16, 1999 at 10:07:26AM -0800, Joe Buck wrote: > But doesn't that assume certain settings of IEEE modes? (I'm not an > expert on IEEE signalling, so I'm not sure about the answer to this > question). No. You're not loading a double, you're loading a long long. Moreover, no rounding occurs with just the load, so you can safely move around 64-bit hunks. r~ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-16 10:08 ` Joe Buck [not found] ` < 199902161807.KAA19010@atrus.synopsys.com > @ 1999-02-28 22:53 ` Joe Buck 1 sibling, 0 replies; 268+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: Richard Henderson; +Cc: jason, Sylvain.Pion, egcs Richard Henderson writes: > The x86 fpu can load DImode values without faulting, and since > the frational part of the extended double register is 64-bits > wide, we don't lose bits. But doesn't that assume certain settings of IEEE modes? (I'm not an expert on IEEE signalling, so I'm not sure about the answer to this question). ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-15 17:15 ` Richard Henderson [not found] ` < 19990215171524.A19063@cygnus.com > @ 1999-02-28 22:53 ` Richard Henderson 1 sibling, 0 replies; 268+ messages in thread From: Richard Henderson @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill, Sylvain Pion; +Cc: egcs On Sun, Feb 14, 1999 at 09:01:29PM -0800, Jason Merrill wrote: > The backend should be able to determine that the struct it's copying is > composed of FP values and use FP instructions for the copy. I don't think > we can do that in general on the x86 because the FPU faults if you try to > load an invalid FP value, but I may be remembering wrong. The x86 fpu can load DImode values without faulting, and since the frational part of the extended double register is 64-bits wide, we don't lose bits. r~ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-14 21:01 ` Jason Merrill [not found] ` < u9iud4jm52.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: Sylvain Pion; +Cc: egcs >>>>> Sylvain Pion <Sylvain.Pion@sophia.inria.fr> writes: > On Fri, Feb 12, 1999 at 01:41:03PM -0800, Jason Merrill wrote: >> This is a backend issue; the frontend just tells the backend "copy this >> struct". The insns used are up to the backend. > Ok, then is it possible to have the backend do some kind of memcpy using > the FP registers (this reminds me some old linux kernel patch never > included...) ? What are the problems with this approach ? The backend should be able to determine that the struct it's copying is composed of FP values and use FP instructions for the copy. I don't think we can do that in general on the x86 because the FPU faults if you try to load an invalid FP value, but I may be remembering wrong. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-14 10:57 ` Sylvain Pion 1999-02-14 21:01 ` Jason Merrill @ 1999-02-28 22:53 ` Sylvain Pion 1 sibling, 0 replies; 268+ messages in thread From: Sylvain Pion @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: egcs On Fri, Feb 12, 1999 at 01:41:03PM -0800, Jason Merrill wrote: > This is a backend issue; the frontend just tells the backend "copy this > struct". The insns used are up to the backend. Ok, then is it possible to have the backend do some kind of memcpy using the FP registers (this reminds me some old linux kernel patch never included...) ? What are the problems with this approach ? -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: C++ default copy ctor not optimal 1999-02-12 13:41 ` Jason Merrill [not found] ` <3.0.6.32.19990212172607.00844860.cygnus.egcs@pop.netaddress.com> [not found] ` < u9d83fl2q8.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 2 siblings, 0 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: Sylvain Pion; +Cc: egcs This is a backend issue; the frontend just tells the backend "copy this struct". The insns used are up to the backend. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
* C++ default copy ctor not optimal 1999-02-12 3:00 ` C++ default copy ctor not optimal Sylvain Pion [not found] ` < 19990212120037.C13091@rigel.inria.fr > [not found] ` <19990212134607.F13091.cygnus.egcs@rigel.inria.fr> @ 1999-02-28 22:53 ` Sylvain Pion 2 siblings, 0 replies; 268+ messages in thread From: Sylvain Pion @ 1999-02-28 22:53 UTC (permalink / raw) To: EGCS list Hi, I've got a class with 2 "double" data members (like a complex). The default copy ctor should be a memberwise copy, but it is slower (on x86) than when I declare it explicitly. In fact, mine generates copies using the FPU, whereas the default does something like a memcopy, using more 32bits "mov"s, and thus is slower. It's not a big problem, but is there a way to "fix" this, or is it considered not safe enough, or too hard ? -- Sylvain ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <3.0.6.32.19990212180551.00841100.cygnus.egcs@pop.netaddress.com>]
* Re: Code gen question [not found] ` <3.0.6.32.19990212180551.00841100.cygnus.egcs@pop.netaddress.com> @ 1999-02-12 15:29 ` Jason Merrill [not found] ` < u990e3kxq8.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 0 siblings, 2 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-12 15:29 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs >>>>> Paul Derbyshire <pderbysh@usa.net> writes: > Which will cause cc1plus to generate better code? > inline int myclass::myfunc (int j) { return j*j*j; } > inline int myclass::myfunc (const int &j) { return j*j*j; } > My guess would be the latter, since the latter when inlined won't make a > copy of the argument passed. Neither will the former. The difference is that the latter refers to its arguments address, which impairs optimization (though not as much as it used to). Absolutely pass scalars by value. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < u990e3kxq8.fsf@yorick.cygnus.com >]
* Re: Code gen question [not found] ` < u990e3kxq8.fsf@yorick.cygnus.com > @ 1999-02-12 17:34 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990212203311.0083e6d0@pop.netaddress.com > 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-12 17:34 UTC (permalink / raw) To: egcs At 03:29 PM 2/12/99 -0800, you wrote: >>>>>> Paul Derbyshire <pderbysh@usa.net> writes: > > > Which will cause cc1plus to generate better code? > > inline int myclass::myfunc (int j) { return j*j*j; } > > > inline int myclass::myfunc (const int &j) { return j*j*j; } > > > My guess would be the latter, since the latter when inlined won't make a > > copy of the argument passed. > >Neither will the former. It won't? So it will observe that j is never modified making copying unnecessary? >The difference is that the latter refers to its >arguments address, which impairs optimization (though not as much as it >used to). It does? If the address isn't used except to dereference, I'd expect the compiler to turn int j, k; j = compute_something(); k = myclass::myfunc(j); into something that resembles: compute_something(); ; j is in eax. movl %eax, %ebx ; k is in ebx now. Hmm, it is copied anyways in a ; sense. mul %eax, %ebx ; k == j*j mul %eax, %ebx ; k == j*j*j >Absolutely pass scalars by value. Does this also apply to stock GCC? PGCC? Most of the differences among these three gccs, except for namespace support (and extern inline behavior :-)), are optimization differences. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 3.0.6.32.19990212203311.0083e6d0@pop.netaddress.com >]
* Re: Code gen question [not found] ` < 3.0.6.32.19990212203311.0083e6d0@pop.netaddress.com > @ 1999-02-12 17:39 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 1 reply; 268+ messages in thread From: Jeffrey A Law @ 1999-02-12 17:39 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs In message < 3.0.6.32.19990212203311.0083e6d0@pop.netaddress.com >you write: > It won't? So it will observe that j is never modified making copying > unnecessary? The copy will initially appear, then be optimized away if at all possible by local and global copy propagation. > >The difference is that the latter refers to its > >arguments address, which impairs optimization (though not as much as it > >used to). > > It does? If the address isn't used except to dereference, I'd expect the > compiler to turn It will try, but it may not always succeed. When you take the address of an object you generally make analysis more difficult on the compiler and sometimes it will be unable to decipher the result. In general you are better off writing the code in the most natural and straightforward way instead of trying to micro-optimize too much. Instead spend your time writing goot algorithms. > >Absolutely pass scalars by value. > > Does this also apply to stock GCC? PGCC? Most of the differences among > these three gccs, except for namespace support (and extern inline behavior > :-)), are optimization differences. Yes. This generally applies to any compiler. As a general rule compilers are a lot better at optimizing scalars than pointers to scalars. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Code gen question 1999-02-12 17:39 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs In message < 3.0.6.32.19990212203311.0083e6d0@pop.netaddress.com >you write: > It won't? So it will observe that j is never modified making copying > unnecessary? The copy will initially appear, then be optimized away if at all possible by local and global copy propagation. > >The difference is that the latter refers to its > >arguments address, which impairs optimization (though not as much as it > >used to). > > It does? If the address isn't used except to dereference, I'd expect the > compiler to turn It will try, but it may not always succeed. When you take the address of an object you generally make analysis more difficult on the compiler and sometimes it will be unable to decipher the result. In general you are better off writing the code in the most natural and straightforward way instead of trying to micro-optimize too much. Instead spend your time writing goot algorithms. > >Absolutely pass scalars by value. > > Does this also apply to stock GCC? PGCC? Most of the differences among > these three gccs, except for namespace support (and extern inline behavior > :-)), are optimization differences. Yes. This generally applies to any compiler. As a general rule compilers are a lot better at optimizing scalars than pointers to scalars. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Code gen question 1999-02-12 17:34 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990212203311.0083e6d0@pop.netaddress.com > @ 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 03:29 PM 2/12/99 -0800, you wrote: >>>>>> Paul Derbyshire <pderbysh@usa.net> writes: > > > Which will cause cc1plus to generate better code? > > inline int myclass::myfunc (int j) { return j*j*j; } > > > inline int myclass::myfunc (const int &j) { return j*j*j; } > > > My guess would be the latter, since the latter when inlined won't make a > > copy of the argument passed. > >Neither will the former. It won't? So it will observe that j is never modified making copying unnecessary? >The difference is that the latter refers to its >arguments address, which impairs optimization (though not as much as it >used to). It does? If the address isn't used except to dereference, I'd expect the compiler to turn int j, k; j = compute_something(); k = myclass::myfunc(j); into something that resembles: compute_something(); ; j is in eax. movl %eax, %ebx ; k is in ebx now. Hmm, it is copied anyways in a ; sense. mul %eax, %ebx ; k == j*j mul %eax, %ebx ; k == j*j*j >Absolutely pass scalars by value. Does this also apply to stock GCC? PGCC? Most of the differences among these three gccs, except for namespace support (and extern inline behavior :-)), are optimization differences. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Code gen question 1999-02-12 15:29 ` Code gen question Jason Merrill [not found] ` < u990e3kxq8.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs >>>>> Paul Derbyshire <pderbysh@usa.net> writes: > Which will cause cc1plus to generate better code? > inline int myclass::myfunc (int j) { return j*j*j; } > inline int myclass::myfunc (const int &j) { return j*j*j; } > My guess would be the latter, since the latter when inlined won't make a > copy of the argument passed. Neither will the former. The difference is that the latter refers to its arguments address, which impairs optimization (though not as much as it used to). Absolutely pass scalars by value. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. @ 1999-02-24 16:27 ` Mike Stump [not found] ` < 199902250026.QAA04615@kankakee.wrs.com > ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Mike Stump @ 1999-02-24 16:27 UTC (permalink / raw) To: egcs, pderbysh > Date: Wed, 24 Feb 1999 06:19:53 -0500 > To: egcs@egcs.cygnus.com > From: Paul Derbyshire <pderbysh@usa.net> > Q: If egcs is allowed to supply the assignment operator and copy > constructor for a "plain old data" type, will they be generally more > efficient than user supplied versions? This is a reasonable assumption. If it is ever false, I think a performance enhancement request is reasonable. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 199902250026.QAA04615@kankakee.wrs.com >]
* Re: Question about compiler-supplied assignment and copy with egcs. [not found] ` < 199902250026.QAA04615@kankakee.wrs.com > @ 1999-02-25 22:31 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-25 22:31 UTC (permalink / raw) To: egcs At 04:26 PM 2/24/99 -0800, you wrote: >> Date: Wed, 24 Feb 1999 06:19:53 -0500 >> To: egcs@egcs.cygnus.com >> From: Paul Derbyshire <pderbysh@usa.net> > >> Q: If egcs is allowed to supply the assignment operator and copy >> constructor for a "plain old data" type, will they be generally more >> efficient than user supplied versions? > >This is a reasonable assumption. If it is ever false, I think a >performance enhancement request is reasonable. With that in mind, I could probably supply a draft of a working valarray header that will do as the standard requests and avoid some temporaries with argument passing and return. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-25 22:31 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 04:26 PM 2/24/99 -0800, you wrote: >> Date: Wed, 24 Feb 1999 06:19:53 -0500 >> To: egcs@egcs.cygnus.com >> From: Paul Derbyshire <pderbysh@usa.net> > >> Q: If egcs is allowed to supply the assignment operator and copy >> constructor for a "plain old data" type, will they be generally more >> efficient than user supplied versions? > >This is a reasonable assumption. If it is ever false, I think a >performance enhancement request is reasonable. With that in mind, I could probably supply a draft of a working valarray header that will do as the standard requests and avoid some temporaries with argument passing and return. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <3.0.6.32.19990226013110.0083c530.cygnus.egcs@pop.globalserve.net>]
* Re: Question about compiler-supplied assignment and copy with egcs. [not found] ` <3.0.6.32.19990226013110.0083c530.cygnus.egcs@pop.globalserve.net> @ 1999-02-25 22:45 ` Jason Merrill [not found] ` < u91zjdirxx.fsf@yorick.cygnus.com > ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-25 22:45 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs >>>>> Paul Derbyshire <pderbysh@usa.net> writes: > With that in mind, I could probably supply a draft of a working valarray > header that will do as the standard requests and avoid some temporaries > with argument passing and return. The libstdc++ rewrite already has a version of valarray, so it might be more useful for you to work on improving that one. If you're interested in helping with the library, you should join the libstdc++ v3 mailing list. See http://sourceware.cygnus.com/libstdc++/ for more info. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < u91zjdirxx.fsf@yorick.cygnus.com >]
* Re: Question about compiler-supplied assignment and copy with egcs. [not found] ` < u91zjdirxx.fsf@yorick.cygnus.com > @ 1999-02-27 21:01 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990228000118.00923340@pop.globalserve.net > 1999-02-28 22:53 ` Question about compiler-supplied assignment and copy with egcs Paul Derbyshire 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-27 21:01 UTC (permalink / raw) To: egcs At 10:45 PM 2/25/99 -0800, you wrote: >The libstdc++ rewrite already has a version of valarray... That's strange, because the egcs zip I got from the Simtel DJGPP tree in v2beta contains no such file as lang/cxx/valarray. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 3.0.6.32.19990228000118.00923340@pop.globalserve.net >]
* Re: Question about compiler-supplied assignment and copy with [not found] ` < 3.0.6.32.19990228000118.00923340@pop.globalserve.net > @ 1999-02-27 21:58 ` Joe Buck [not found] ` < 199902280557.VAA14849@atrus.synopsys.com > 1999-02-28 22:53 ` Joe Buck 0 siblings, 2 replies; 268+ messages in thread From: Joe Buck @ 1999-02-27 21:58 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs > At 10:45 PM 2/25/99 -0800, you wrote: > >The libstdc++ rewrite already has a version of valarray... > > That's strange, because the egcs zip I got from the Simtel DJGPP tree in > v2beta contains no such file as lang/cxx/valarray. egcs contains libstdc++ v2. The rewrite is libstdc++ v3. v3 is still not usable, since important functionality is missing, though parts of it work. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 199902280557.VAA14849@atrus.synopsys.com >]
* Re: Question about compiler-supplied assignment and copy with [not found] ` < 199902280557.VAA14849@atrus.synopsys.com > @ 1999-02-27 23:29 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-27 23:29 UTC (permalink / raw) To: egcs At 09:57 PM 2/27/99 PST, you wrote: > >> At 10:45 PM 2/25/99 -0800, you wrote: >> >The libstdc++ rewrite already has a version of valarray... >> >> That's strange, because the egcs zip I got from the Simtel DJGPP tree in >> v2beta contains no such file as lang/cxx/valarray. > >egcs contains libstdc++ v2. The rewrite is libstdc++ v3. v3 is still >not usable, since important functionality is missing, though parts of >it work. Parts that work in v2? How can that possibly happen, since v3 is presumably v2 with bugs fixed and more stuff implemented. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with 1999-02-27 23:29 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 09:57 PM 2/27/99 PST, you wrote: > >> At 10:45 PM 2/25/99 -0800, you wrote: >> >The libstdc++ rewrite already has a version of valarray... >> >> That's strange, because the egcs zip I got from the Simtel DJGPP tree in >> v2beta contains no such file as lang/cxx/valarray. > >egcs contains libstdc++ v2. The rewrite is libstdc++ v3. v3 is still >not usable, since important functionality is missing, though parts of >it work. Parts that work in v2? How can that possibly happen, since v3 is presumably v2 with bugs fixed and more stuff implemented. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with 1999-02-27 21:58 ` Question about compiler-supplied assignment and copy with Joe Buck [not found] ` < 199902280557.VAA14849@atrus.synopsys.com > @ 1999-02-28 22:53 ` Joe Buck 1 sibling, 0 replies; 268+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs > At 10:45 PM 2/25/99 -0800, you wrote: > >The libstdc++ rewrite already has a version of valarray... > > That's strange, because the egcs zip I got from the Simtel DJGPP tree in > v2beta contains no such file as lang/cxx/valarray. egcs contains libstdc++ v2. The rewrite is libstdc++ v3. v3 is still not usable, since important functionality is missing, though parts of it work. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-27 21:01 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990228000118.00923340@pop.globalserve.net > @ 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 10:45 PM 2/25/99 -0800, you wrote: >The libstdc++ rewrite already has a version of valarray... That's strange, because the egcs zip I got from the Simtel DJGPP tree in v2beta contains no such file as lang/cxx/valarray. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <3.0.6.32.19990228000118.00923340.cygnus.egcs@pop.globalserve.net>]
* Re: Question about compiler-supplied assignment and copy with egcs. [not found] ` <3.0.6.32.19990228000118.00923340.cygnus.egcs@pop.globalserve.net> @ 1999-02-27 23:55 ` Jason Merrill [not found] ` < u9yalj7yin.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 0 siblings, 2 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-27 23:55 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs >>>>> Paul Derbyshire <pderbysh@usa.net> writes: > At 10:45 PM 2/25/99 -0800, you wrote: >> The libstdc++ rewrite already has a version of valarray... > That's strange, because the egcs zip I got from the Simtel DJGPP tree in > v2beta contains no such file as lang/cxx/valarray. That's because the libstdc++ rewrite isn't part of egcs yet, and won't be until it's complete. Please refer to the URL I sent you before. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < u9yalj7yin.fsf@yorick.cygnus.com >]
* Re: Question about compiler-supplied assignment and copy with egcs. [not found] ` < u9yalj7yin.fsf@yorick.cygnus.com > @ 1999-02-28 1:10 ` Paul Derbyshire 1999-02-28 2:51 ` Tudor Hulubei ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 1:10 UTC (permalink / raw) To: egcs At 11:55 PM 2/27/99 -0800, you wrote: >That's because the libstdc++ rewrite isn't part of egcs yet, and won't be >until it's complete. Please refer to the URL I sent you before. Why don't they merge each new feature in as they get it finished, instead of making everyone wait until they can get their Webcams set up and have a ribbon-cutting ceremony in live video streaming? :P As for the URL, I found the mailing list address there and (because I can potentially help out) sent a subscribe request, but the list server failed to respond in any way whatsoever. All I did was put "subscribe Paul Derbyshire" in the subject and in the first line of the body (since list servers vary a great deal and sometimes expect a command in the subject, sometimes in the body). There should have been SOME response, even if only a bounce of some kind or a list server error message. As near as I can tell, I've either 1. Been silently subscribed to a low volume mailing list, with no welcome message, and where even the submit addresses and ways to filter the messages to their own folder will have to wait until I actually receive a posting through it, or else 2. Something was wrong with my request and the list server error message bounced or otherwise failed to get through, which is highly improbable since as always I used valid From: and Reply-To: addresses, no munging, or else 3. The list server has a bug, or else 4. The list server is down. Does anyone have any information about which of these is the case? I need to know to tailor my course of action; 1 invovles waiting and seeing, 2 involves cajoling list server syntax information out of somebody, and 3 and 4 involve the list server's Someone In Charge being notified about the error so they can Fix It and possibly resubmitting the subscription request. Note: I have allowed adequate time for a response to be generated and received, namely over 4 hours. Since I don't live in Upper Moldovia or anywhere similarly exotic, that should be plenty of time to receive either a response or a 4-hour-warning bounce if Something Went Wrong. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-28 1:10 ` Paul Derbyshire @ 1999-02-28 2:51 ` Tudor Hulubei [not found] ` < 14041.8114.947193.298212@hal.ttlc.net > 1999-02-28 22:53 ` Tudor Hulubei 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 2:28 ` Gerald Pfeifer 2 siblings, 2 replies; 268+ messages in thread From: Tudor Hulubei @ 1999-02-28 2:51 UTC (permalink / raw) To: Paul Derbyshire, egcs On Sunday, 28 February 1999, Paul Derbyshire wrote: > Why don't they merge each new feature in as they get it finished, instead > of making everyone wait until they can get their Webcams set up and have a > ribbon-cutting ceremony in live video streaming? :P Maybe because we need stable compilers/libraries? Maybe because the old and new versions of libstdc++ cannot be mixed at will? [A few other obvious maybes deleted...]. Why don't you use your brain before bothering this list with such dumb questions? This list used to be of very high quality before you came. Call me a fascist, but if I were the administrator of this list, I would ban you access to it. You are annoying too many people. > As for the URL, I found the mailing list address there and (because I can > potentially help out) sent a subscribe request, but the list server failed > to respond in any way whatsoever. All I did was put "subscribe Paul > Derbyshire" in the subject and in the first line of the body (since list > servers vary a great deal and sometimes expect a command in the subject, > sometimes in the body). There should have been SOME response, even if only > a bounce of some kind or a list server error message. > > As near as I can tell, I've either > 1. Been silently subscribed to a low volume mailing list, with no > welcome message, and where even the submit addresses and ways to > filter the messages to their own folder will have to wait until I > actually receive a posting through it, or else > 2. Something was wrong with my request and the list server error > message bounced or otherwise failed to get through, which is > highly improbable since as always I used valid From: and Reply-To: > addresses, no munging, or else > 3. The list server has a bug, or else > 4. The list server is down. > > Does anyone have any information about which of these is the case? I need > to know to tailor my course of action; 1 invovles waiting and seeing, 2 > involves cajoling list server syntax information out of somebody, and 3 and > 4 involve the list server's Someone In Charge being notified about the > error so they can Fix It and possibly resubmitting the subscription request. Is this the Introduction of your PhD thesis in "Mailing Lists Behavior"? Could you please describe in greate detail the topology of your kitchen or other useless crap nobody on this list cares to know? > Note: I have allowed adequate time for a response to be generated and > received, namely over 4 hours. Since I don't live in Upper Moldovia or > anywhere similarly exotic, I happen to be a Romanian, and I find your comment about Moldavia offending (yes, it is spelled Moldavia, not Moldovia, but I won't insist - you have more serious problems than that). If you didn't realise by now that there is a good chance of someone taking offence at this kind of comment then you don't deserve to be on the net in the first place. > that should be plenty of time to receive either a response or a > 4-hour-warning bounce if Something Went Wrong. Have you notified the White House? Tudor ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 14041.8114.947193.298212@hal.ttlc.net >]
* Re: Question about compiler-supplied assignment and copy with egcs. [not found] ` < 14041.8114.947193.298212@hal.ttlc.net > @ 1999-02-28 4:36 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 4:36 UTC (permalink / raw) To: egcs At 05:51 AM 2/28/99 -0500, you wrote: >Maybe because we need stable compilers/libraries? Maybe because the >old and new versions of libstdc++ cannot be mixed at will? [A few >other obvious maybes deleted...]. So much for using the language features of C++ to build a modular and flexible design where, because of encapsulation and interfaces and implementation-hiding, you can upgrade in a modular way, hm? >Is this the Introduction of your PhD thesis in "Mailing Lists >Behavior"? [Additional excessive sarcastic verbiage deleted] No, it's my request to know what the devil is going on with that particular list server so that I know whether I need to resubmit the request or not, or whatever. And so that if the list server is misbehaving, someone becomes aware of this fact that can do something about it. [More garbage deleted] Well, ex-CUUSE-me. I invented a name and it happened to resemble that of a real place. Big whup. What's more, it's a fact that in less developed areas internet connectivity tends to be slow and iffy, which isn't to be taken as an insult against a region and certainly not as an insult against a culture, but merely a statement of fact about the infrastructure quality in certain places. Say, is it just my imagination or is there an uncommonly large concentration of thin-skinned, humor and sarcasm impaired individuals in this forum? >Have you notified the White House? What the hell would they have to do with anything? Nothing, as long as the problem with the mail server doesn't impair their ability to eavesdrop on every email sent on Earth significantly... -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-28 4:36 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 05:51 AM 2/28/99 -0500, you wrote: >Maybe because we need stable compilers/libraries? Maybe because the >old and new versions of libstdc++ cannot be mixed at will? [A few >other obvious maybes deleted...]. So much for using the language features of C++ to build a modular and flexible design where, because of encapsulation and interfaces and implementation-hiding, you can upgrade in a modular way, hm? >Is this the Introduction of your PhD thesis in "Mailing Lists >Behavior"? [Additional excessive sarcastic verbiage deleted] No, it's my request to know what the devil is going on with that particular list server so that I know whether I need to resubmit the request or not, or whatever. And so that if the list server is misbehaving, someone becomes aware of this fact that can do something about it. [More garbage deleted] Well, ex-CUUSE-me. I invented a name and it happened to resemble that of a real place. Big whup. What's more, it's a fact that in less developed areas internet connectivity tends to be slow and iffy, which isn't to be taken as an insult against a region and certainly not as an insult against a culture, but merely a statement of fact about the infrastructure quality in certain places. Say, is it just my imagination or is there an uncommonly large concentration of thin-skinned, humor and sarcasm impaired individuals in this forum? >Have you notified the White House? What the hell would they have to do with anything? Nothing, as long as the problem with the mail server doesn't impair their ability to eavesdrop on every email sent on Earth significantly... -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-28 2:51 ` Tudor Hulubei [not found] ` < 14041.8114.947193.298212@hal.ttlc.net > @ 1999-02-28 22:53 ` Tudor Hulubei 1 sibling, 0 replies; 268+ messages in thread From: Tudor Hulubei @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire, egcs On Sunday, 28 February 1999, Paul Derbyshire wrote: > Why don't they merge each new feature in as they get it finished, instead > of making everyone wait until they can get their Webcams set up and have a > ribbon-cutting ceremony in live video streaming? :P Maybe because we need stable compilers/libraries? Maybe because the old and new versions of libstdc++ cannot be mixed at will? [A few other obvious maybes deleted...]. Why don't you use your brain before bothering this list with such dumb questions? This list used to be of very high quality before you came. Call me a fascist, but if I were the administrator of this list, I would ban you access to it. You are annoying too many people. > As for the URL, I found the mailing list address there and (because I can > potentially help out) sent a subscribe request, but the list server failed > to respond in any way whatsoever. All I did was put "subscribe Paul > Derbyshire" in the subject and in the first line of the body (since list > servers vary a great deal and sometimes expect a command in the subject, > sometimes in the body). There should have been SOME response, even if only > a bounce of some kind or a list server error message. > > As near as I can tell, I've either > 1. Been silently subscribed to a low volume mailing list, with no > welcome message, and where even the submit addresses and ways to > filter the messages to their own folder will have to wait until I > actually receive a posting through it, or else > 2. Something was wrong with my request and the list server error > message bounced or otherwise failed to get through, which is > highly improbable since as always I used valid From: and Reply-To: > addresses, no munging, or else > 3. The list server has a bug, or else > 4. The list server is down. > > Does anyone have any information about which of these is the case? I need > to know to tailor my course of action; 1 invovles waiting and seeing, 2 > involves cajoling list server syntax information out of somebody, and 3 and > 4 involve the list server's Someone In Charge being notified about the > error so they can Fix It and possibly resubmitting the subscription request. Is this the Introduction of your PhD thesis in "Mailing Lists Behavior"? Could you please describe in greate detail the topology of your kitchen or other useless crap nobody on this list cares to know? > Note: I have allowed adequate time for a response to be generated and > received, namely over 4 hours. Since I don't live in Upper Moldovia or > anywhere similarly exotic, I happen to be a Romanian, and I find your comment about Moldavia offending (yes, it is spelled Moldavia, not Moldovia, but I won't insist - you have more serious problems than that). If you didn't realise by now that there is a good chance of someone taking offence at this kind of comment then you don't deserve to be on the net in the first place. > that should be plenty of time to receive either a response or a > 4-hour-warning bounce if Something Went Wrong. Have you notified the White House? Tudor ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-28 1:10 ` Paul Derbyshire 1999-02-28 2:51 ` Tudor Hulubei @ 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 2:28 ` Gerald Pfeifer 2 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 11:55 PM 2/27/99 -0800, you wrote: >That's because the libstdc++ rewrite isn't part of egcs yet, and won't be >until it's complete. Please refer to the URL I sent you before. Why don't they merge each new feature in as they get it finished, instead of making everyone wait until they can get their Webcams set up and have a ribbon-cutting ceremony in live video streaming? :P As for the URL, I found the mailing list address there and (because I can potentially help out) sent a subscribe request, but the list server failed to respond in any way whatsoever. All I did was put "subscribe Paul Derbyshire" in the subject and in the first line of the body (since list servers vary a great deal and sometimes expect a command in the subject, sometimes in the body). There should have been SOME response, even if only a bounce of some kind or a list server error message. As near as I can tell, I've either 1. Been silently subscribed to a low volume mailing list, with no welcome message, and where even the submit addresses and ways to filter the messages to their own folder will have to wait until I actually receive a posting through it, or else 2. Something was wrong with my request and the list server error message bounced or otherwise failed to get through, which is highly improbable since as always I used valid From: and Reply-To: addresses, no munging, or else 3. The list server has a bug, or else 4. The list server is down. Does anyone have any information about which of these is the case? I need to know to tailor my course of action; 1 invovles waiting and seeing, 2 involves cajoling list server syntax information out of somebody, and 3 and 4 involve the list server's Someone In Charge being notified about the error so they can Fix It and possibly resubmitting the subscription request. Note: I have allowed adequate time for a response to be generated and received, namely over 4 hours. Since I don't live in Upper Moldovia or anywhere similarly exotic, that should be plenty of time to receive either a response or a 4-hour-warning bounce if Something Went Wrong. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-28 1:10 ` Paul Derbyshire 1999-02-28 2:51 ` Tudor Hulubei 1999-02-28 22:53 ` Paul Derbyshire @ 1999-03-01 2:28 ` Gerald Pfeifer 1999-03-31 23:46 ` Gerald Pfeifer 2 siblings, 1 reply; 268+ messages in thread From: Gerald Pfeifer @ 1999-03-01 2:28 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs On Sun, 28 Feb 1999, Paul Derbyshire wrote: > [libstdc++ mailing list] > As near as I can tell, I've either > [...] > Does anyone have any information about which of these is the case? Non of the above. Addition/removal is not automatic. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-03-01 2:28 ` Gerald Pfeifer @ 1999-03-31 23:46 ` Gerald Pfeifer 0 siblings, 0 replies; 268+ messages in thread From: Gerald Pfeifer @ 1999-03-31 23:46 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs On Sun, 28 Feb 1999, Paul Derbyshire wrote: > [libstdc++ mailing list] > As near as I can tell, I've either > [...] > Does anyone have any information about which of these is the case? Non of the above. Addition/removal is not automatic. Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-27 23:55 ` Jason Merrill [not found] ` < u9yalj7yin.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs >>>>> Paul Derbyshire <pderbysh@usa.net> writes: > At 10:45 PM 2/25/99 -0800, you wrote: >> The libstdc++ rewrite already has a version of valarray... > That's strange, because the egcs zip I got from the Simtel DJGPP tree in > v2beta contains no such file as lang/cxx/valarray. That's because the libstdc++ rewrite isn't part of egcs yet, and won't be until it's complete. Please refer to the URL I sent you before. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-25 22:45 ` Jason Merrill [not found] ` < u91zjdirxx.fsf@yorick.cygnus.com > [not found] ` <3.0.6.32.19990228000118.00923340.cygnus.egcs@pop.globalserve.net> @ 1999-02-28 22:53 ` Jason Merrill 2 siblings, 0 replies; 268+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs >>>>> Paul Derbyshire <pderbysh@usa.net> writes: > With that in mind, I could probably supply a draft of a working valarray > header that will do as the standard requests and avoid some temporaries > with argument passing and return. The libstdc++ rewrite already has a version of valarray, so it might be more useful for you to work on improving that one. If you're interested in helping with the library, you should join the libstdc++ v3 mailing list. See http://sourceware.cygnus.com/libstdc++/ for more info. Jason ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Question about compiler-supplied assignment and copy with egcs. 1999-02-24 16:27 ` Question about compiler-supplied assignment and copy with egcs Mike Stump [not found] ` < 199902250026.QAA04615@kankakee.wrs.com > [not found] ` <3.0.6.32.19990226013110.0083c530.cygnus.egcs@pop.globalserve.net> @ 1999-02-28 22:53 ` Mike Stump 2 siblings, 0 replies; 268+ messages in thread From: Mike Stump @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs, pderbysh > Date: Wed, 24 Feb 1999 06:19:53 -0500 > To: egcs@egcs.cygnus.com > From: Paul Derbyshire <pderbysh@usa.net> > Q: If egcs is allowed to supply the assignment operator and copy > constructor for a "plain old data" type, will they be generally more > efficient than user supplied versions? This is a reasonable assumption. If it is ever false, I think a performance enhancement request is reasonable. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Removal of V2 code @ 2000-11-19 13:03 ` Mark Mitchell 2000-11-19 17:10 ` Geoff Keating 2000-11-20 0:41 ` Andrew Cagney 0 siblings, 2 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-19 13:03 UTC (permalink / raw) To: gcc I plan on doing a `cvs remove' on the V2 sources, and removing the configury bits for V2 at the end of next week as things seem to be settling OK with V3. (There are still some AIX issues with V3, but they seem to be well on the path to resolution.) If you have objections to this plan (i.e., you need the V2 sources to continue your work), you should: - Try hard to get V3 working on your platform. - Complain to me. Explain why you can't switch to V3, and what you need in order to make that happen. We can keep V2 in the tree for a bit longer, if we need to, but you'll have to come up with a good reason... :-) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 13:03 ` Removal of V2 code Mark Mitchell @ 2000-11-19 17:10 ` Geoff Keating [not found] ` <Mark> ` (3 more replies) 2000-11-20 0:41 ` Andrew Cagney 1 sibling, 4 replies; 268+ messages in thread From: Geoff Keating @ 2000-11-19 17:10 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc Mark Mitchell <mark@codesourcery.com> writes: > I plan on doing a `cvs remove' on the V2 sources, and removing the > configury bits for V2 at the end of next week as things seem to be > settling OK with V3. (There are still some AIX issues with V3, but > they seem to be well on the path to resolution.) > > If you have objections to this plan (i.e., you need the V2 sources to > continue your work), you should: > > - Try hard to get V3 working on your platform. > > - Complain to me. Explain why you can't switch to V3, and what > you need in order to make that happen. > > We can keep V2 in the tree for a bit longer, if we need to, but you'll > have to come up with a good reason... :-) The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with V3; I don't believe anyone, certainly not at Red Hat, will be able to fix this until next month; we don't have time. I don't know what the vxworks status is, but I'd bet it doesn't work either. I don't know what the Cygwin status is. It may work. Do HPUX, IRIX, BeOS work? Does SunOS (not Solaris) work? I think we still have SunOS customers. At Red Hat we have not switched over to V3, primarily for this reason. Such a change will make it difficult for us to merge patches back into the FSF sources, because we would not be able to test them. We would end up committing patches saying "have tested with C++ only on our internal sources, due to no libstdc++ support in the public tree". Already you can see this effect; you will notice that the automated tester is no longer testing C++ because the platform it tests with is not supported by libstdc++-v3. I believe this schedule is far too quick. We have only had libstdc++-v3 as the default for a few weeks, there are known problems, these problems will take some time to fix. I would wait 6 months and ask again. -- - Geoffrey Keating <geoffk@geoffk.org> ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <Mark>]
* Re: Removal of V2 code 2000-11-19 17:10 ` Geoff Keating [not found] ` <Mark> @ 2000-11-19 17:24 ` Christopher Faylor 2000-11-19 17:56 ` Mark Mitchell 2000-11-20 2:54 ` Franz Sirl 3 siblings, 0 replies; 268+ messages in thread From: Christopher Faylor @ 2000-11-19 17:24 UTC (permalink / raw) To: Geoff Keating; +Cc: Mark Mitchell, gcc On Sun, Nov 19, 2000 at 05:10:33PM -0800, Geoff Keating wrote: >Mark Mitchell <mark@codesourcery.com> writes: >> I plan on doing a `cvs remove' on the V2 sources, and removing the >> configury bits for V2 at the end of next week as things seem to be >> settling OK with V3. (There are still some AIX issues with V3, but >> they seem to be well on the path to resolution.) >> >> If you have objections to this plan (i.e., you need the V2 sources to >> continue your work), you should: >> >> - Try hard to get V3 working on your platform. >> >> - Complain to me. Explain why you can't switch to V3, and what >> you need in order to make that happen. >> >> We can keep V2 in the tree for a bit longer, if we need to, but you'll >> have to come up with a good reason... :-) > >The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with V3; I >don't believe anyone, certainly not at Red Hat, will be able to fix >this until next month; we don't have time. > >I don't know what the vxworks status is, but I'd bet it doesn't work either. > >I don't know what the Cygwin status is. It may work. Cygwin should be ok. cgf ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 17:10 ` Geoff Keating [not found] ` <Mark> 2000-11-19 17:24 ` Christopher Faylor @ 2000-11-19 17:56 ` Mark Mitchell 2000-11-19 20:24 ` Geoff Keating 2000-11-20 2:54 ` Franz Sirl 3 siblings, 1 reply; 268+ messages in thread From: Mark Mitchell @ 2000-11-19 17:56 UTC (permalink / raw) To: geoffk; +Cc: gcc >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes: Geoff> The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't Geoff> work yet with V3; I don't believe anyone, certainly not at Geoff> Red Hat, will be able to fix this until next month; we Geoff> don't have time. Put simply, I don't think that is an issue for the FSF release. None of these platforms are on primary release criteria list. If Red Hat has customers that need support for these platforms, then Red Hat will presumably provide implement support for V3. Geoff> Do HPUX, IRIX, BeOS work? I don't know about HPUX or BeOS. IRIX works. Geoff> Does SunOS (not Solaris) work? I think we still have SunOS Geoff> customers. I don't know about SunOS either. Kaveh? I don't think Red Hat's customer list is relevant, except as some sort of barometer of who's out there. But, we already have release criteria, and I believe that V3 works on all of those platforms except for HPUX (for which we have no target triplet in the critera; I wonder what version we're talking about here) and AIX (being worked on, expected to work soon). Doing the porting work really isn't hard and it's getting easier the more platforms we do. Any ELF platform with a reasonably compliant C library should be a snap. I don't know how conformant newlib is; it might be that you have to tweak some configuration bits to make that work. It's a day or two's work, a week tops. And once it works with newlib somewhere, it will probably work everywhere; the amount of target-specific code in V3 is tiny, and there are generic C versions for everything. Geoff> Such a change will make it difficult for us to merge Geoff> patches back into the FSF sources, because we would not be Geoff> able to test them. I should think that you could find a stock i686-pc-linux-gnu system to test platform-independent changes on. :-) And for most chips (MIPS, PowerPC, etc.) I bet you have non-embedded alternatives to test back-end changes on. There may be rare chips for which this is not possible, but there is likely either no C++ support for those chips at all in the FSF tree, or there is a non-embedded target for which you simply do not have access to appropriate hardware. In that case, I'm sure that either someone will provide you access to the hardware, test your patch themselves, or that you can go ahead and check it in, and let the people with the right hardware check out what happens. Any changes you make in your internal tree need to be tested in the public tree, using the same configuration that everyone else uses, before you check them in anyhow. It would be wrong to test a C++ patch with V2 and check it in without testing it with V3, even if V2 were still in the tree, since V3 is whatever everyone else is using. 99% of all changes coming from Red Hat are to code where there are not likely to be any merge issues depending on whether V2 or V3 is in use. It's going to be `cvs diff' and `patch' independent of the V2 vs. V3 issues. That's the procedure for testing a patch from your internal tree anyhow; how does the absence of V2 in the FSF sources make this harder? Is there some deeper technical issue I'm not seeing? Geoff> Already you can see this effect; you will notice that the Geoff> automated tester is no longer testing C++ because the Geoff> platform it tests with is not supported by libstdc++-v3. The regression tester is something you (quite generously!) decided to set up. It would be great if someone could port V3 to that platform. You could also choose a different target, which would allow us to continue getting the regression-testing reports for C++, at the expense of testing a different chip. Geoff> I believe this schedule is far too quick. We have only had Geoff> libstdc++-v3 as the default for a few weeks, there are Geoff> known problems, these problems will take some time to fix. Geoff> I would wait 6 months and ask again. You make it sound as though the switch was a surprise. :-) The switch to V3, and to the new ABI, and the removal of the previous versions of these things was announced as long as a year ago, and both V3 and the new ABI have been in the tree for many months. If people who build tools based on or around G++ haven't prepared themselves for this transition, that was probably a mistake. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 17:56 ` Mark Mitchell @ 2000-11-19 20:24 ` Geoff Keating 2000-11-19 21:52 ` Mark Mitchell 0 siblings, 1 reply; 268+ messages in thread From: Geoff Keating @ 2000-11-19 20:24 UTC (permalink / raw) To: mark; +Cc: gcc > From: Mark Mitchell <mark@codesourcery.com> > Date: Sun, 19 Nov 2000 17:56:08 -0800 > >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes: > > Geoff> The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't > Geoff> work yet with V3; I don't believe anyone, certainly not at > Geoff> Red Hat, will be able to fix this until next month; we > Geoff> don't have time. > > Put simply, I don't think that is an issue for the FSF release. None > of these platforms are on primary release criteria list. I didn't understand this part, and so I couldn't understand much of the rest of your mail either. What does the release or the release criteria have to do with it? I was objecting to the deletion of libstdc++-v2 from the development tree, on the grounds that this would make it harder to do development. I would have no objection to its deletion from the release branch, if it's not needed for the release. I don't really care. I just wanted to try to avoid a possibly annoying mistake. If you really think you're doing the right thing, go ahead. > I should think that you could find a stock i686-pc-linux-gnu system to > test platform-independent changes on. :-) And for most chips (MIPS, > PowerPC, etc.) I bet you have non-embedded alternatives to test > back-end changes on. There may be rare chips for which this is not > possible, but there is likely either no C++ support for those chips at > all in the FSF tree, or there is a non-embedded target for which you > simply do not have access to appropriate hardware. In that case, I'm > sure that either someone will provide you access to the hardware, test > your patch themselves, or that you can go ahead and check it in, and > let the people with the right hardware check out what happens. The counter-example here is i960; there are no non-embedded alternatives (the choices are -coff, -elf, and -vxworks), and it does have C++ support. -- - Geoffrey Keating <geoffk@geoffk.org> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 20:24 ` Geoff Keating @ 2000-11-19 21:52 ` Mark Mitchell 2000-11-19 22:12 ` Geoff Keating 0 siblings, 1 reply; 268+ messages in thread From: Mark Mitchell @ 2000-11-19 21:52 UTC (permalink / raw) To: geoffk, geoffk; +Cc: gcc >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes: >> Put simply, I don't think that is an issue for the FSF >> release. None of these platforms are on primary release >> criteria list. Geoff> I didn't understand this part, and so I couldn't understand Geoff> much of the rest of your mail either. Sorry. I was referencing the list of platforms that the SC has decided are primary targets for GCC 3.0; none of those targets are embedded systems. Geoff> What does the release or the release criteria have to do Geoff> with it? I was objecting to the deletion of libstdc++-v2 Geoff> from the development tree, on the grounds that this would Geoff> make it harder to do development. I would have no Geoff> objection to its deletion from the release branch, if it's Geoff> doing the right thing, go ahead. The problem is that these things aren't entirely orthogonal. The ABI, the library version, and the performance of the compiler are all intertwined. It's not just the question of dragging the sources around; it's more complex than that. There's also the issue that port maintainers need to invest the effort to switch to V3 because that's what we're going to support going forward. I'd really like to get a handle on whether that porting effort is truly difficult or not. (It wasn't difficult on the platforms I worked on, but, on the other hand, it has been pointed out that those were both SVR4-ish platforms.) Geoff> The counter-example here is i960; there are no non-embedded Geoff> alternatives (the choices are -coff, -elf, and -vxworks), Geoff> and it does have C++ support. OK. But I still don't really understand the scenario you're talking about. It seems to me there are a few cases: - Change to the i960 back-end in your tree. You can test in your tree, and you can test C/Fortran/ObjC in the public tree. By hypothesis, the public tree doesn't have i960 C++ support any more, since the scenario we're talking about is one where we don't have V2 in the public tree, and V3 doesn't work on the i960. So, nobody can complain about your change breaking i960 C++. - Change to the C++ front-end in your tree. Likely this change is not i960-specific. You can test with another chip. If it *is* i960 specific, then you're in the same boat as above: there's no i960 C++ support anyhow. So, I'm afraid I still don't understand the testing argument. Is there anyone out there who is willing to try a newlib port of V3? Is it possible to build newlib on an i686-pc-linux-gnu box, using it natively, instead of glibc? If so, would you tell me how to do this? Or, alternatively, a way to build a cross-compiler plus simulator so that I can test a newlib configuration on my PC? If you will tell me how to build all the pieces, I will try to figure out how to make V3 work in that environment. If I were to make that work, would that reduce your objection to removing the V2 sources? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 21:52 ` Mark Mitchell @ 2000-11-19 22:12 ` Geoff Keating 2000-11-19 22:33 ` Mark Mitchell ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Geoff Keating @ 2000-11-19 22:12 UTC (permalink / raw) To: mark; +Cc: gcc > From: Mark Mitchell <mark@codesourcery.com> > Date: Sun, 19 Nov 2000 21:51:57 -0800 > Or, alternatively, a way to build a cross-compiler plus simulator so > that I can test a newlib configuration on my PC? Sure. I have a script for this, which the automated tester uses. Just change TOPDIR to somewhere on your machine. [The complexity of this script is why people keep agitating for a combined tree.] -- - Geoffrey Keating <geoffk@geoffk.org> ===File ~/buildobjs.sh====================================== #!/usr/unsupported/bin/bash set -x TARGET=powerpc-eabisim CVSROOT_BIN=':pserver:anoncvs@anoncvs.cygnus.com:/cvs/src' CVSROOT_GCC=':pserver:anoncvs@anoncvs.cygnus.com:/cvs/gcc' TOPDIR=/sloth/delay/tbox CVS_DIR=$TOPDIR/cvs-objs SRC_XC=$CVS_DIR/gcc SRC_BIN=$CVS_DIR/binutils SRC_DIR=$TOPDIR/src-objs INSTALL_DIR=$TOPDIR/objs OBJ_DIR=$TOPDIR/build-objs SCRIPT_DIR=$HOME/tbox rm -rf $OBJ_DIR $INSTALL_DIR $SRC_DIR mkdir $OBJ_DIR $INSTALL_DIR $SRC_DIR || exit 1 mkdir $OBJ_DIR/src $OBJ_DIR/test || exit 1 mkdir -p $SRC_XC $SRC_BIN || exit 1 PATH=/bin:/usr/bin PATH=$INSTALL_DIR/bin:$TOPDIR/boot/bin:$PATH export PATH cd $SRC_XC || exit 1 cvs -Q -d $CVSROOT_GCC co egcs-full || exit 1 cd $SRC_BIN || exit 1 cvs -Q -d $CVSROOT_BIN co binutils gdb newlib dejagnu || exit 1 # the order here is important, the GCC files are the master copy. cd $SRC_BIN/src || exit 1 find . -print | cpio -pdlm $SRC_DIR || exit 1 cd $SRC_XC/egcs || exit 1 find . -print | cpio -pdlmu $SRC_DIR || exit 1 cd $SRC_DIR || exit 1 [ -x contrib/gcc_update ] && contrib/gcc_update --touch > /dev/null cd $OBJ_DIR/src || exit 1 $SRC_DIR/configure --prefix=$INSTALL_DIR --target=$TARGET || exit 1 make all || exit 1 make install || exit 1 DEJAGNU=/home/s1/cygnus/dejagnu/site.exp export DEJAGNU cd $OBJ_DIR/test || exit 1 $SRC_XC/egcs/configure --target=$TARGET \ --prefix=$INSTALL_DIR --enable-checking=misc,gc,tree || exit 1 make || exit 1 make -k check-gcc check-target-libio check-target-libstdc++ exit 0 ============================================================ ===File ~/lib/site.exp====================================== # Needed for isnative. load_lib "framework.exp" # Make sure we look in the right place for the board description files. if ![info exists boards_dir] { set boards_dir {} } lappend boards_dir "/home/geoffk/lib/dejagnu" # # If we're testing GCC, G++ or GDB, then we want to run on all the # available targets. Otherwise, just test the first one. # if ![info exists tool] { set run_multiple_targets 0; } elseif { $tool == "g++" || $tool == "gcc" || $tool == "gdb" || $tool == "libg++" || $tool == "libstdc++" || $tool == "libio" || $tool == "binutils" } { set run_multiple_targets 1; } else { set run_multiple_targets 0; } verbose "Global Config File: target_triplet is $target_triplet" 2 global target_list case "$target_triplet" in { { "native" } { set target_list "unix" } { "powerpc-*-eabi" } { set target_list { powerpc-sim } } { "powerpc-*-eabisim" } { set target_list { powerpc-sim } } } # # If the tool under test won't really benefit from running on multiple # targets, then don't do so. # if { ! $run_multiple_targets } { set target_list [list [lindex $target_list 0]]; } ============================================================ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 22:12 ` Geoff Keating @ 2000-11-19 22:33 ` Mark Mitchell 2000-11-20 1:07 ` Mark Mitchell 2000-11-21 10:56 ` Mark Mitchell 2 siblings, 0 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-19 22:33 UTC (permalink / raw) To: geoffk, geoffk; +Cc: gcc Youch! OK, I'll try that script soon. Tomorrow is my wife's birthday, so not until Tuesday at the soonest... Thanks! -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 22:12 ` Geoff Keating 2000-11-19 22:33 ` Mark Mitchell @ 2000-11-20 1:07 ` Mark Mitchell 2000-11-20 2:11 ` Geoff Keating 2000-11-21 10:56 ` Mark Mitchell 2 siblings, 1 reply; 268+ messages in thread From: Mark Mitchell @ 2000-11-20 1:07 UTC (permalink / raw) To: geoffk, geoffk; +Cc: gcc Geoff -- Where do I but the site.exp you sent? In place of the DEJAGNU=/home/s1/cygnus/dejagnu/site.exp file? Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-20 1:07 ` Mark Mitchell @ 2000-11-20 2:11 ` Geoff Keating 0 siblings, 0 replies; 268+ messages in thread From: Geoff Keating @ 2000-11-20 2:11 UTC (permalink / raw) To: mark; +Cc: gcc > From: Mark Mitchell <mark@codesourcery.com> > Date: Mon, 20 Nov 2000 01:07:11 -0800 > Geoff -- > > Where do I but the site.exp you sent? In place of the > > DEJAGNU=/home/s1/cygnus/dejagnu/site.exp > > file? Yes. You only have to do this if you want to do testing and might forget to enter --target_board: make check RUNTESTFLAGS=--target_board=powerpc-sim -- - Geoffrey Keating <geoffk@geoffk.org> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 22:12 ` Geoff Keating 2000-11-19 22:33 ` Mark Mitchell 2000-11-20 1:07 ` Mark Mitchell @ 2000-11-21 10:56 ` Mark Mitchell 2000-11-21 12:20 ` Benjamin Kosnik 2000-11-21 12:37 ` Geoff Keating 2 siblings, 2 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-21 10:56 UTC (permalink / raw) To: geoffk, geoffk; +Cc: gcc, libstdc++ Geoff -- Thanks for the script. It worked great. The rumors of V2 not working with newlib were greatly exaggerated. I made absolutely no changes to the source code or configury bits. Everything built, and most C++ tests passed. Looking at the C++ tests, there were 40 unexpected failures (relative to the 3 we see on GNU/Linux). I randomly sampled 5 of the 37 new failures; all of them had the following problem: /nfs/gandalf/u2/mitchell/dev/powerpc-test/objs/lib/gcc-lib/powerpc-eabisim/2.97/../../../../powerpc-eabisim/lib/libc.a(fdopen.o): In function `_fdopen_r': /nfs/gandalf/u2/mitchell/dev/powerpc-test/src-objs/newlib/libc/stdio/fdopen.c:67: undefined reference to `fcntl' The code in question looks like it calls `_fcntl'; I don't know why the linker reports that as `fcntl'. I don't understand what's causing that, but it's clear that it has nothing to do with V3. I suspect a newlib configury issue. Geoff, would you mind tracking this down? It is possible that there will be runtime issues involving I/O streams once the `fdopen' issue is resolved; I have no way of knowing at this time. There was also one configury oddity in the V3 directory: /nfs/gandalf/u2/mitchell/dev/powerpc-test/cvs-objs/gcc/egcs/libstdc++-v3/configure: test: =: unary operator expected This comes from: AC_DEFUN(AC_LC_MESSAGES, [if test $ac_cv_header_locale_h = yes; then AC_CACHE_CHECK([for LC_MESSAGES], ac_cv_val_LC_MESSAGES, when $ac_cv_header_locale_h is not yet set. I think that the V3 configury bits should check for <locale.h> first. Would a V3 person please confirm that, and make the necessary change? Even without this change, however, the configuration completed, built the library, and mostly worked. The Steering Committee has pretty much forbidden me from spending more time working on getting V3 going with newlib. However, I think it's clear that a volunteer could finish the job with minimal effort. The first step doesn't even involve understanding anything about V3 -- just figure out what's going on with fcntl. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-21 10:56 ` Mark Mitchell @ 2000-11-21 12:20 ` Benjamin Kosnik 2000-11-21 12:45 ` Mark Mitchell 2000-11-21 12:37 ` Geoff Keating 1 sibling, 1 reply; 268+ messages in thread From: Benjamin Kosnik @ 2000-11-21 12:20 UTC (permalink / raw) To: Mark Mitchell; +Cc: geoffk, geoffk, gcc, libstdc++ > The rumors of V2 not working with newlib were greatly exaggerated. Err. I think you mean the rumors of V3 working with newlib have been greatly exaggerated. As a matter of fact, it's been working since about Feb. I did a cross x86-x-powerpc-elf this Sunday, as a matter of fact, and it worked well. > I made absolutely no changes to the source code or configury bits. ...as none should be needed. > There was also one configury oddity in the V3 directory: > > /nfs/gandalf/u2/mitchell/dev/powerpc-test/cvs-objs/gcc/egcs/libstdc++-v3/configure: test: =: unary operator expected > > This comes from: > > AC_DEFUN(AC_LC_MESSAGES, > [if test $ac_cv_header_locale_h = yes; then > AC_CACHE_CHECK([for LC_MESSAGES], ac_cv_val_LC_MESSAGES, > > when $ac_cv_header_locale_h is not yet set. I think that the V3 > configury bits should check for <locale.h> first. Would a V3 person > please confirm that, and make the necessary change? I'll fix this. > Even without this change, however, the configuration completed, > built the library, and mostly worked. ... this has been my experience as well. Nice to see it confirmed. -benjamin ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-21 12:20 ` Benjamin Kosnik @ 2000-11-21 12:45 ` Mark Mitchell 0 siblings, 0 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-21 12:45 UTC (permalink / raw) To: bkoz; +Cc: geoffk, geoffk, gcc, libstdc++ >>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes: >> The rumors of V2 not working with newlib were greatly >> exaggerated. Benjamin> Err. I think you mean the rumors of V3 working with Benjamin> newlib have been greatly exaggerated. Right. >> Even without this change, however, the configuration completed, >> built the library, and mostly worked. Benjamin> ... this has been my experience as well. Nice to see it Benjamin> confirmed. Yup. Nice work setting this stuff up. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-21 10:56 ` Mark Mitchell 2000-11-21 12:20 ` Benjamin Kosnik @ 2000-11-21 12:37 ` Geoff Keating 2000-11-21 12:47 ` Mark Mitchell 1 sibling, 1 reply; 268+ messages in thread From: Geoff Keating @ 2000-11-21 12:37 UTC (permalink / raw) To: mark; +Cc: gcc, libstdc++ > Cc: gcc@gcc.gnu.org, libstdc++@sources.redhat.com > From: Mark Mitchell <mark@codesourcery.com> > Date: Tue, 21 Nov 2000 10:56:13 -0800 > Geoff -- > > Thanks for the script. It worked great. > > The rumors of V2 not working with newlib were greatly exaggerated. Great! (I assume you mean V3). It seems to have changed since I looked at it last. Now the problem is that V3 doesn't cross-configure from Solaris. I get: updating cache ../config.cache /sloth/delay/tbox/cvs-gcc/egcs/libstdc++-v3/configure: test: argument expected and the configuration stops. This is just the usual breakage, though, and probably easily fixed, as compared to the earlier situation where it looked like lots of porting would be required. So, go for it! > The code in question looks like it calls `_fcntl'; I don't know why > the linker reports that as `fcntl'. I don't understand what's causing > that, but it's clear that it has nothing to do with V3. I suspect a > newlib configury issue. Geoff, would you mind tracking this down? I'll look at it. Thank you very much for your work! -- - Geoffrey Keating <geoffk@geoffk.org> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-21 12:37 ` Geoff Keating @ 2000-11-21 12:47 ` Mark Mitchell 0 siblings, 0 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-21 12:47 UTC (permalink / raw) To: geoffk, geoffk; +Cc: gcc, libstdc++ >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes: >> Cc: gcc@gcc.gnu.org, libstdc++@sources.redhat.com From: Mark >> Mitchell <mark@codesourcery.com> Date: Tue, 21 Nov 2000 >> 10:56:13 -0800 >> Geoff -- >> >> Thanks for the script. It worked great. >> >> The rumors of V2 not working with newlib were greatly >> exaggerated. Geoff> Great! (I assume you mean V3). It seems to have changed Yes, sorry, for the confusion. Geoff> since I looked at it last. I think this may be because the V3 folks put some stubs for threading primitives in place that will provide a non thread-safe implementation on all platforms. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 17:10 ` Geoff Keating ` (2 preceding siblings ...) 2000-11-19 17:56 ` Mark Mitchell @ 2000-11-20 2:54 ` Franz Sirl 2000-11-21 6:38 ` Franz Sirl 3 siblings, 1 reply; 268+ messages in thread From: Franz Sirl @ 2000-11-20 2:54 UTC (permalink / raw) To: Geoff Keating; +Cc: Mark Mitchell, gcc At 02:10 20.11.00, Geoff Keating wrote: >Mark Mitchell <mark@codesourcery.com> writes: > > > I plan on doing a `cvs remove' on the V2 sources, and removing the > > configury bits for V2 at the end of next week as things seem to be > > settling OK with V3. (There are still some AIX issues with V3, but > > they seem to be well on the path to resolution.) > > > > If you have objections to this plan (i.e., you need the V2 sources to > > continue your work), you should: > > > > - Try hard to get V3 working on your platform. > > > > - Complain to me. Explain why you can't switch to V3, and what > > you need in order to make that happen. > > > > We can keep V2 in the tree for a bit longer, if we need to, but you'll > > have to come up with a good reason... :-) > >The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with >V3; I >don't believe anyone, certainly not at Red Hat, will be able to fix >this until next month; we don't have time. Well, not only the embedded stuff is non-functional, powerpc-linux-gnu is unusable with libstdc++-v3 too (see my posted testsuite results). I couldn't do too much debugging yet, but it seems most (if not all) of the testcases crash during constructor handling in glibc's malloc/free code. Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-20 2:54 ` Franz Sirl @ 2000-11-21 6:38 ` Franz Sirl 2000-11-21 7:26 ` Daniel Berlin 0 siblings, 1 reply; 268+ messages in thread From: Franz Sirl @ 2000-11-21 6:38 UTC (permalink / raw) To: Mark Mitchell; +Cc: Geoff Keating, gcc At 11:54 20.11.00, Franz Sirl wrote: >At 02:10 20.11.00, Geoff Keating wrote: >>Mark Mitchell <mark@codesourcery.com> writes: >> >> > I plan on doing a `cvs remove' on the V2 sources, and removing the >> > configury bits for V2 at the end of next week as things seem to be >> > settling OK with V3. (There are still some AIX issues with V3, but >> > they seem to be well on the path to resolution.) >> > >> > If you have objections to this plan (i.e., you need the V2 sources to >> > continue your work), you should: >> > >> > - Try hard to get V3 working on your platform. >> > >> > - Complain to me. Explain why you can't switch to V3, and what >> > you need in order to make that happen. >> > >> > We can keep V2 in the tree for a bit longer, if we need to, but you'll >> > have to come up with a good reason... :-) >> >>The embedded platforms (*-elf, powerpc-eabi*, *-coff) don't work yet with >>V3; I >>don't believe anyone, certainly not at Red Hat, will be able to fix >>this until next month; we don't have time. > >Well, not only the embedded stuff is non-functional, powerpc-linux-gnu is >unusable with libstdc++-v3 too (see my posted testsuite results). I >couldn't do too much debugging yet, but it seems most (if not all) of the >testcases crash during constructor handling in glibc's malloc/free code. Replying to my own message, here is a backtrace of what I get as a fail in all cases I looked into so far, this is with todays CVS: [fsirl@entropy:~/obj/gccm/gcc/testsuite]$ LD_LIBRARY_PATH=~/obj/gccm/ppc-redhat-linux/libstdc++-v3/src/.libs/ gdb ./g++-pt-ttp9-C GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ppc-redhat-linux"... (gdb) r Starting program: /home/fsirl/obj/gccm/gcc/testsuite/./g++-pt-ttp9-C Program received signal SIGSEGV, Segmentation fault. 0xfe3893c in chunk_free () at /usr/include/stdlib.h:269 269 return __strtold_internal (__nptr, __endptr, 0); Current language: auto; currently c++ (gdb) bt full #0 0xfe3893c in chunk_free () at /usr/include/stdlib.h:269 __alloc1 = (allocator<char> &) @0x10010a08: {<No data fields>} __b = (istreambuf_iterator<char,std::char_traits<char> > &) @0x2c030001: Cannot access memory at address 0x2c030001 (gdb) bt #0 0xfe3893c in chunk_free () at /usr/include/stdlib.h:269 #1 0xfe388ec in free () at /usr/include/stdlib.h:269 #2 0xffa67b4 in _ZNSs4_Rep10_M_destroyERKSaIcE (this=0x2c030001, __a=@0xffefa08) at /home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/stl_alloc.h:131 #3 0xff98298 in _ZNSt6locale7classicEv () at /home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/basic_string.h:178 #4 0xffadbbc in _ZNSt13basic_filebufIcSt11char_traitsIcEEC1Ev (this=0xffef604) at /home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/localefwd.h:311 #5 0xff8fdc0 in __static_initialization_and_destruction_0 (__initialize_p=268503580, __priority=268368392) at /home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/locale_facets.h:35 #6 0xff90070 in _GLOBAL_.I._ZSt11__cfileinit () at /home/fsirl/cvsx/gccm/libstdc++-v3/include/bits/std_fstream.h:96 #7 0xff8d7a4 in __do_global_ctors_aux () at /home/fsirl/cvsx/gccm/libstdc++-v3/libsupc++/vec.cc:56 #8 0xff89e68 in _init () at /usr/include/stdlib.h:269 #9 0x300106ac in _start () from /lib/ld.so.1 (gdb) This happens on both glibc-2.1.3 and glibc-2.2. Does anyone have an idea what might have gone wrong here? BTW, shouldn't c++filt now default to the V3 mangling style too? Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-21 6:38 ` Franz Sirl @ 2000-11-21 7:26 ` Daniel Berlin 0 siblings, 0 replies; 268+ messages in thread From: Daniel Berlin @ 2000-11-21 7:26 UTC (permalink / raw) To: Franz Sirl; +Cc: Mark Mitchell, Geoff Keating, gcc > BTW, shouldn't c++filt now default to the V3 mangling style too? No. It shoudl dfault to auto, which is what it does now. It should, however, detect V3 mangling style automatically, using the _Z prefix. It's a 10 minute job if someone wants to do it. > > Franz. > ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-19 13:03 ` Removal of V2 code Mark Mitchell 2000-11-19 17:10 ` Geoff Keating @ 2000-11-20 0:41 ` Andrew Cagney 2000-11-20 0:55 ` Mark Mitchell 1 sibling, 1 reply; 268+ messages in thread From: Andrew Cagney @ 2000-11-20 0:41 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc Mark Mitchell wrote: > > I plan on doing a `cvs remove' on the V2 sources, and removing the > configury bits for V2 at the end of next week as things seem to be > settling OK with V3. (There are still some AIX issues with V3, but > they seem to be well on the path to resolution.) > > If you have objections to this plan (i.e., you need the V2 sources to > continue your work), you should: > > - Try hard to get V3 working on your platform. > > - Complain to me. Explain why you can't switch to V3, and what > you need in order to make that happen. Do you really want to do this? Wouldn't it be better to take a more staggered approach? First release a GCC with both v2 and v3 ABI support and then release a successor that only contains v3 support. I expect many people to try to use GCC with pre installed tools (GDB comes to mind). Requiring people to upgrade to some not-yet-even-developed version of random tools is going to raise a few eyebrows. (perhaps I'm misunderstanding the significance of the change) enjoy, Andrew ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-20 0:41 ` Andrew Cagney @ 2000-11-20 0:55 ` Mark Mitchell 2000-11-20 3:32 ` Marc Espie [not found] ` <00112021562300.00259@hallo> 0 siblings, 2 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-20 0:55 UTC (permalink / raw) To: ac131313; +Cc: gcc >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes: Andrew> Mark Mitchell wrote: >> I plan on doing a `cvs remove' on the V2 sources, and removing >> the configury bits for V2 at the end of next week as things >> seem to be settling OK with V3. (There are still some AIX >> issues with V3, but they seem to be well on the path to >> resolution.) >> >> If you have objections to this plan (i.e., you need the V2 >> sources to continue your work), you should: >> >> - Try hard to get V3 working on your platform. >> >> - Complain to me. Explain why you can't switch to V3, and what >> you need in order to make that happen. Andrew> Do you really want to do this? Andrew> Wouldn't it be better to take a more staggered approach? Andrew> First release a GCC with both v2 and v3 ABI support and Andrew> then release a successor that only contains v3 support. We could do that. The SC decided a while back *not* to do that, but it/we could change its/our collective mind. The issue is that the new ABI implies the use of V3; V2 does not work with the new ABI. We want to stop breaking the C++ ABI; that's one major impetus for GCC 3.0. If we provide both ABIs, we're encouraging people to use the old ABI, which is not quite the same as what was in GCC 2.95.x, but is also not what we want to use going forward. The attitude at the time the release criteria were put together was that you could always use GCC 2.95 if you wanted an ABI compatible with GCC 2.95. :-) In other words, there was a conscious decision not to support the old ABI in GCC 3.0, with the hope of never again chaging the C++ ABI. Andrew> I expect many people to try to use GCC with pre installed Andrew> tools (GDB comes to mind). Requiring people to upgrade to Andrew> some not-yet-even-developed version of random tools is Andrew> going to raise a few eyebrows. Nowadays, what tends to happen for GNU/Linux users is that somebody (Debian, Red Hat, etc) puts together a nice package with everyting in it. I wouldn't expect GCC 3.0 to appear in those distributions until other tools are in place. You're correct that users that aren't getting their GNU diet spoon-fed to them (:-)) may have to download development versions of some supporting tools. If we wait until all those tools are ready, though, we'll likely be waiting a long time... -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-20 0:55 ` Mark Mitchell @ 2000-11-20 3:32 ` Marc Espie 2000-11-20 5:53 ` Joseph S. Myers 2000-11-20 8:34 ` Mark Mitchell [not found] ` <00112021562300.00259@hallo> 1 sibling, 2 replies; 268+ messages in thread From: Marc Espie @ 2000-11-20 3:32 UTC (permalink / raw) To: mark; +Cc: gcc In article < 20001120005458Q.mitchell@codesourcery.com > you write: >Nowadays, what tends to happen for GNU/Linux users is that somebody >(Debian, Red Hat, etc) puts together a nice package with everyting in >it. I wouldn't expect GCC 3.0 to appear in those distributions until >other tools are in place. You're correct that users that aren't >getting their GNU diet spoon-fed to them (:-)) may have to download >development versions of some supporting tools. If we wait until all >those tools are ready, though, we'll likely be waiting a long time... Well, some other people take a more conservative approach and don't want to unleash DEVELOPMENT code on the general public. I still think it is completely, utterly WRONG to release development code in a so-called `stable' release. If anything, it gives the impression that free software is put together hastily, and does work slightly better than windows, but with lots of bugs. How about trying to entice the OTHER projects that are maintained by the FSF to keep track and get a somewhat DECENT release schedule ? I could even put forward a majorly NEW concept: how about having RELEASE DATES for RELATED gnu projects ? Namely, you've got what we would call a toolchain (binutils, gcc, gdb...). How about releasing a STABLE version every year (say, 1st of january) ? and ensuring that the current year versions work together ? The one thing I do agree is that this is NOT FUN STUFF AT ALL. Well, ethically, `free software' is not always fun. Having a heck of a good time hacking also means a few hours should be sunk into the not funny parts. Like documenting, or offering a wee little bit of support for stable versions. In my opinion, the reason it does not quite work now is that most people just work on the stuff that's fun for them. There are a few contributors who DO deal with the `unnice' parts of it... (Invariably, they are also the guys who don't really have the time for that) not enough though (for instance, have a look at gcc's info documentation. It's incomplete. Why ? because people want to write code, not documentation). If you are a gcc contributor, ask yourself that question: what have you done for gcc last year ? Was it all a fun hobby, or did you also help with other chores ? If not, WHY NOT ??? ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-20 3:32 ` Marc Espie @ 2000-11-20 5:53 ` Joseph S. Myers 2000-11-20 8:34 ` Mark Mitchell 1 sibling, 0 replies; 268+ messages in thread From: Joseph S. Myers @ 2000-11-20 5:53 UTC (permalink / raw) To: Marc Espie; +Cc: mark, gcc On Mon, 20 Nov 2000, Marc Espie wrote: > (for instance, have > a look at gcc's info documentation. It's incomplete. Why ? because people want > to write code, not documentation). I have proposed in <URL: http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00381.html > that documentation be a mandatory part of patches for which it is applicable. Hopefully this proposal is being considered. -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-20 3:32 ` Marc Espie 2000-11-20 5:53 ` Joseph S. Myers @ 2000-11-20 8:34 ` Mark Mitchell 1 sibling, 0 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-20 8:34 UTC (permalink / raw) To: espie; +Cc: gcc >>>>> "Marc" == Marc Espie <espie@quatramaran.ens.fr> writes: Marc> Well, some other people take a more conservative approach Marc> and don't want to unleash DEVELOPMENT code on the general Marc> public. In at least a narrow interpretation, we're not talking about that. The GCC code will be tested, stable, etc. The issue is whether or not all the supporting tools will have caught up. I hope they will have, and as GCC people, we should encourage those people to catch up. But, everyone has their own priorities, and exactly what the GDB folks (for example) are up to is not something the GCC SC really knows about. This is a weakness is the free software development model: there isn't a global, centralizing authority to make everything happen in a coordinated way. Companies (Red Hat, SuSE, etc.) have sprung up to provide that value add. And that lack of central authority is also the strength of the free software model. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <00112021562300.00259@hallo>]
* Re: Removal of V2 code [not found] ` <00112021562300.00259@hallo> @ 2000-11-20 14:58 ` Mark Mitchell 2000-11-21 14:14 ` Geoff Keating 0 siblings, 1 reply; 268+ messages in thread From: Mark Mitchell @ 2000-11-20 14:58 UTC (permalink / raw) To: hartmut.schirmer; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 642 bytes --] >>>>> "Hartmut" == Hartmut Schirmer <hartmut.schirmer@arcormail.de> writes: Hartmut> On Mon, 20 Nov 2000, Mark Mitchell wrote: >> The attitude at the time the release criteria were put together >> was that you could always use GCC 2.95 if you wanted an ABI >> compatible with GCC 2.95. :-) Hartmut> But we´re waiting for gcc 2.95.3 for more than a year now Hartmut> :(( There aren't currently any plans for such a release, but the Steering Committe is debating such a release even as we speak. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-20 14:58 ` Mark Mitchell @ 2000-11-21 14:14 ` Geoff Keating 2000-11-21 15:06 ` Mark Mitchell 0 siblings, 1 reply; 268+ messages in thread From: Geoff Keating @ 2000-11-21 14:14 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 735 bytes --] Mark Mitchell <mark@codesourcery.com> writes: > >>>>> "Hartmut" == Hartmut Schirmer <hartmut.schirmer@arcormail.de> writes: > > Hartmut> On Mon, 20 Nov 2000, Mark Mitchell wrote: > >> The attitude at the time the release criteria were put together > >> was that you could always use GCC 2.95 if you wanted an ABI > >> compatible with GCC 2.95. :-) > > Hartmut> But we´re waiting for gcc 2.95.3 for more than a year now > Hartmut> :(( > > There aren't currently any plans for such a release, but the Steering > Committe is debating such a release even as we speak. Are there records of such debates anywhere? Minutes of meetings, mailing list archives, etc.? -- - Geoffrey Keating <geoffk@geoffk.org> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-21 14:14 ` Geoff Keating @ 2000-11-21 15:06 ` Mark Mitchell 2000-11-21 16:08 ` Tom Tromey 2000-11-21 20:00 ` SC confidentiality Geoff Keating 0 siblings, 2 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-21 15:06 UTC (permalink / raw) To: geoffk; +Cc: gcc >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes: Geoff> Are there records of such debates anywhere? Minutes of Geoff> meetings, mailing list archives, etc.? Not to my knowledge. I believe that in general the details of SC discussions are considered confidential in order to encourage frank exchanges of ideas among the SC members. I could be wrong about that, but that's how I've always treated other people's SC postings. If I'm right, that would make releasing any such archives inappropriate. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-21 15:06 ` Mark Mitchell @ 2000-11-21 16:08 ` Tom Tromey 2000-11-21 17:21 ` 2.95.3 (was Re: Removal of V2 code) Joe Buck 2000-11-21 21:41 ` Removal of V2 code Mark Mitchell 2000-11-21 20:00 ` SC confidentiality Geoff Keating 1 sibling, 2 replies; 268+ messages in thread From: Tom Tromey @ 2000-11-21 16:08 UTC (permalink / raw) To: Mark Mitchell; +Cc: GCC Hackers Mark> I believe that in general the details of SC discussions are Mark> considered confidential in order to encourage frank exchanges of Mark> ideas among the SC members. I could be wrong about that, but Mark> that's how I've always treated other people's SC postings. If Mark> I'm right, that would make releasing any such archives Mark> inappropriate. What is it about release schedules that makes it important to discuss them secretly? I think having a debate about whether to release 2.95.3 should happen in public. In fact, the debate will probably happen anyway, whether the SC wants it or not. I know we've discussed it several times on the Java list (mostly in terms of "I don't know if there will be one, since it is only discussed in secret"). Tom ^ permalink raw reply [flat|nested] 268+ messages in thread
* 2.95.3 (was Re: Removal of V2 code) 2000-11-21 16:08 ` Tom Tromey @ 2000-11-21 17:21 ` Joe Buck 2000-11-22 13:55 ` Tom Tromey 2000-11-21 21:41 ` Removal of V2 code Mark Mitchell 1 sibling, 1 reply; 268+ messages in thread From: Joe Buck @ 2000-11-21 17:21 UTC (permalink / raw) To: tromey; +Cc: Mark Mitchell, GCC Hackers > Mark> I believe that in general the details of SC discussions are > Mark> considered confidential in order to encourage frank exchanges of > Mark> ideas among the SC members. I could be wrong about that, but > Mark> that's how I've always treated other people's SC postings. If > Mark> I'm right, that would make releasing any such archives > Mark> inappropriate. > What is it about release schedules that makes it important to discuss > them secretly? I think having a debate about whether to release > 2.95.3 should happen in public. In fact, the debate will probably > happen anyway, whether the SC wants it or not. I know we've discussed > it several times on the Java list (mostly in terms of "I don't know if > there will be one, since it is only discussed in secret"). It's OK to discuss 2.95.3 in public as far as I'm concerned. So I'll start it off, and hope I don't offend other SC members too badly. (I'm usually the one who least knows when to shut up ;-). It's also, as far as I'm concerned, OK to talk about what's been discussed in the SC in general terms, as long as the topic isn't sensitive (e.g. once in a while we have to deal with two people not getting along, and after it's settled there's no reason to bring up any name-calling that happened before). The SC is charged with making final decisions, but certainly all developers should have input -- as long as people understand that releases don't happen by magic: we need real volunteers and there are tradeoffs (that is, if we do 2.95.3 it is inevitable that 3.0 will be later). We have a qualified person who has offered to run 2.95.3 if we do it. Before we had that, there wasn't much reason to bring it up in public, as it would just raise false hopes. I'm not naming him here because I didn't ask his permission. We pretty much have consensus that we should at least do "2.95.2.1" -- a very minimal patch to work with glibc 2.2. But the BSD folks and others need a couple of other patches, suggesting that more should be done. It will be no use whipping something out quickly that just embarrasses us all, so if we do more than 2.95.2.1 we need a substantial testing effort to make sure we have no regressions wrt 2.95.2. Inevitably folks will want some patches that can't go in. One issue is that we don't want yet ANOTHER incompatible C++ release out there, which makes it very difficult, though not impossible, to fix the Linux-specific vtable thunks bug without breaking link compatibility (unless someone has a cool trick I don't know about). Another issue that some on the SC have expressed worries about is whether 2.95.3 will cause developers of front ends or back ends that haven't been fixed to work with the planned 3.0 changes (e.g. new C++ ABI, GC) to lose their motivation to quickly fix the problems, meaning that either 3.0 will taken even longer or then we'll be asked to support two parallel chains of development going forward (2.95.4, etc). ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: 2.95.3 (was Re: Removal of V2 code) 2000-11-21 17:21 ` 2.95.3 (was Re: Removal of V2 code) Joe Buck @ 2000-11-22 13:55 ` Tom Tromey 0 siblings, 0 replies; 268+ messages in thread From: Tom Tromey @ 2000-11-22 13:55 UTC (permalink / raw) To: Joe Buck; +Cc: Mark Mitchell, GCC Hackers >>>>> "Joe" == Joe Buck <jbuck@racerx.synopsys.com> writes: Joe> Another issue that some on the SC have expressed worries about is Joe> whether 2.95.3 will cause developers of front ends or back ends Joe> that haven't been fixed to work with the planned 3.0 changes Joe> (e.g. new C++ ABI, GC) to lose their motivation to quickly fix Joe> the problems, meaning that either 3.0 will taken even longer or Joe> then we'll be asked to support two parallel chains of development Joe> going forward (2.95.4, etc). In Java-land we were interested in having 2.95.3 about 6 months ago when the cvs gcc was regularly broken. However we didn't have resources to do a full release :-(. If it came up now I imagine we would just ignore it. We're busy working on getting everything set for gcc 3.0. In some ways this would be bad, because the gcc in Red Hat 7.0 has newer Java support than any hypothetical 2.95.3 would. Tom ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Removal of V2 code 2000-11-21 16:08 ` Tom Tromey 2000-11-21 17:21 ` 2.95.3 (was Re: Removal of V2 code) Joe Buck @ 2000-11-21 21:41 ` Mark Mitchell 1 sibling, 0 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-21 21:41 UTC (permalink / raw) To: tromey; +Cc: gcc >>>>> "Tom" == Tom Tromey <tromey@cygnus.com> writes: Mark> I believe that in general the details of SC discussions are Mark> considered confidential in order to encourage frank Mark> exchanges of ideas among the SC members. I could be wrong Mark> about that, but that's how I've always treated other Mark> people's SC postings. If I'm right, that would make Mark> releasing any such archives inappropriate. Tom> What is it about release schedules that makes it important to Tom> discuss them secretly? Nothing in particular. I was just trying to answer the question as to why there are no mail archives and such. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* SC confidentiality 2000-11-21 15:06 ` Mark Mitchell 2000-11-21 16:08 ` Tom Tromey @ 2000-11-21 20:00 ` Geoff Keating 2000-11-21 21:57 ` Mark Mitchell 1 sibling, 1 reply; 268+ messages in thread From: Geoff Keating @ 2000-11-21 20:00 UTC (permalink / raw) To: mark; +Cc: gcc > From: Mark Mitchell <mark@codesourcery.com> > Date: Tue, 21 Nov 2000 15:06:26 -0800 > >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes: > > Geoff> Are there records of such debates anywhere? Minutes of > Geoff> meetings, mailing list archives, etc.? > > Not to my knowledge. > > I believe that in general the details of SC discussions are considered > confidential in order to encourage frank exchanges of ideas among the > SC members. I could be wrong about that, but that's how I've always > treated other people's SC postings. If I'm right, that would make > releasing any such archives inappropriate. I would strongly argue that this is a bad practise. * The job of the SC is to help the maintainers by setting policy for the future development of gcc. This will be much easier for the maintainers if the reasons behind the policy decisions can be explained and the arguments considered when making those decisions are available. * The members of the SC are representing various facets of the community of GCC users. Unless their positions are public, the community can give no feedback on whether those positions are actually shared by the community. * This is particularly important given the possibilty of a conflict of interest, since many of the SC members are also affiliated with various companies which have their own interests in the development of GCC. A closed discussion allows allegations to be made and heard, even by those with obvious biases, which would be laughed at if the discussion were open. Of course, prior discussions which were made in the belief that they were confidential should not be disclosed, but for the future I urge the SC to make its discussion open. -- - Geoffrey Keating <geoffk@geoffk.org> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: SC confidentiality 2000-11-21 20:00 ` SC confidentiality Geoff Keating @ 2000-11-21 21:57 ` Mark Mitchell 0 siblings, 0 replies; 268+ messages in thread From: Mark Mitchell @ 2000-11-21 21:57 UTC (permalink / raw) To: geoffk, geoffk; +Cc: gcc >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes: Geoff> Of course, prior discussions which were made in the belief Geoff> that they were confidential should not be disclosed, but Geoff> for the future I urge the SC to make its discussion open. I have no strong feelings on this matter. Certainly, the SC should not be (and is not, in my opinion) a secret cabal of puppeteers. :-) On the other hand, there is some value in having the opportunity to discuss delicate issues in confidence. In my experience, which is very limited relative to a lot of the more senior SC members, there are no technical dicussions -- almost all discussions are about things like possible inappropriate behavior on the part of individuals, policies for dealing with copyright assignment paperwork, strategies for handling events that might cause confusion about GCC or the GNU Project, and so forth. It's a tricky balance. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <08:25:39>]
[parent not found: <-0700>]
* Automake and friends and fastjar @ 2001-05-09 9:58 ` Mark Klein 2001-05-09 12:08 ` Tom Tromey 0 siblings, 1 reply; 268+ messages in thread From: Mark Klein @ 2001-05-09 9:58 UTC (permalink / raw) To: gcc Forgive me in advance ... I'm not automake literate. In the current 3.0 build, fastjar/jartool.c uses strdup() which does not exist on all platforms. I was going to submit the patch, but in this case, I'm not sure where to begin. There are two ways to handle this, the easiest is to use libiberty.a as a dependent library. The harder is to include the HAVE_STRDUP stuff into jartool.c. In either case the Makefile.[am|in] need to be modified and this is where I don't have experience. Would someone (either online for educational purposes or offline) walk me through this process so I can better understand it? TIA. Regards, Mark -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Automake and friends and fastjar 2001-05-09 9:58 ` Automake and friends and fastjar Mark Klein @ 2001-05-09 12:08 ` Tom Tromey 2001-05-09 12:15 ` Mark Klein 0 siblings, 1 reply; 268+ messages in thread From: Tom Tromey @ 2001-05-09 12:08 UTC (permalink / raw) To: Mark Klein; +Cc: gcc >>>>> "Mark" == Mark Klein <mklein@dis.com> writes: Mark> Forgive me in advance ... I'm not automake literate. Mark> In the current 3.0 build, fastjar/jartool.c uses strdup() Mark> which does not exist on all platforms. I was going to Mark> submit the patch, but in this case, I'm not sure where to Mark> begin. A patch to do this is already in the trunk. Do we need this on the branch? My impression was that we did not, since as far as I know libgcj hasn't been ported to any system that doesn't have strdup(). fastjar is only needed (and should only be built) if you are building the java support. However if we do need it, it is a relatively simple matter to bring the patch from the trunk to the branch. Mark> There are two ways to handle this, the easiest is to use Mark> libiberty.a as a dependent library. The harder is to include Mark> the HAVE_STRDUP stuff into jartool.c. In either case the Mark> Makefile.[am|in] need to be modified and this is where I Mark> don't have experience. In this case, as there is only one use of strdup(), a different approach was taken: we just use our own (renamed) strdup() implementation all the time. Tom ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Automake and friends and fastjar 2001-05-09 12:08 ` Tom Tromey @ 2001-05-09 12:15 ` Mark Klein 0 siblings, 0 replies; 268+ messages in thread From: Mark Klein @ 2001-05-09 12:15 UTC (permalink / raw) To: tromey; +Cc: gcc At 01:21 PM 5/9/2001 -0600, Tom Tromey wrote: >Do we need this on the branch? My impression was that we did not, >since as far as I know libgcj hasn't been ported to any system that >doesn't have strdup(). fastjar is only needed (and should only be >built) if you are building the java support. I'm about to begin porting libjgc and friends to MPE/iX but haven't yet started (we only just recently got kernel threads and I was waiting for that). Nevertheless, it appears fastjar was being built even though the libgcj tree didn't qualify. Now that I understand what's up, I can deal with this by hand while I'm porting, so there is probably no need to move the fix from the trunk to the branch. Thanks! Regards, M. -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <"Fri,>]
[parent not found: <11>]
[parent not found: <Jun>]
[parent not found: <2000>]
[parent not found: <10:30:29>]
[parent not found: <-0400>]
* SSA implementation @ 2000-06-29 7:30 ` David Dolan 2000-06-29 11:59 ` Geoff Keating 0 siblings, 1 reply; 268+ messages in thread From: David Dolan @ 2000-06-29 7:30 UTC (permalink / raw) To: gcc Has the ssa pass been fully implemented in the most current snapshot? Thanks!! Dave Dolan ddolan@andrew.cmu.edu ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: SSA implementation 2000-06-29 7:30 ` SSA implementation David Dolan @ 2000-06-29 11:59 ` Geoff Keating 2000-06-29 12:07 ` Errors from Gcc Matt Minnis 2000-06-29 12:11 ` SSA implementation Mark Mitchell 0 siblings, 2 replies; 268+ messages in thread From: Geoff Keating @ 2000-06-29 11:59 UTC (permalink / raw) To: David Dolan; +Cc: gcc "David Dolan" <ddolan@andrew.cmu.edu> writes: > Has the ssa pass been fully implemented in the most current snapshot? It does turn the code into SSA form. That's close to everything we want it to do. In the future there will be other things done while the code is in SSA form, but they will be separate passes. -- - Geoffrey Keating <geoffk@cygnus.com> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Errors from Gcc 2000-06-29 11:59 ` Geoff Keating @ 2000-06-29 12:07 ` Matt Minnis 2000-06-29 13:43 ` Martin v. Loewis 2000-06-29 12:11 ` SSA implementation Mark Mitchell 1 sibling, 1 reply; 268+ messages in thread From: Matt Minnis @ 2000-06-29 12:07 UTC (permalink / raw) To: gcc Can someone help me here? I am not sure how to fix these errors. In file included from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3/iterator:38, from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3/std/bastring.h:44, from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3/string:6, from input.cc:47: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3/stl_iterator.h:121: redefinition of `struct iterator_traits<_Tp *>' /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3/stl_iterator.h:118: previous definition here /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3/stl_iterator.h:122: invalid member template declaration `iterator_traits<_Tp *>::iterator_category' What are these trying to tell me to do? These errors sprung up while in the headers of the package I am trying to build. These confuse me. It complains that it is redefining something, but lists the same place for each. Thanks, Matt Cthulhu for President. Why settle for a lesser evil? ========================================================= Preferred Resources (314) 567-7600 phone 701 Emerson rd. (314) 993-6699 fax Suite 475 mminnis@prefres.com St. Louis, MO 63141 ========================================================= ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Errors from Gcc 2000-06-29 12:07 ` Errors from Gcc Matt Minnis @ 2000-06-29 13:43 ` Martin v. Loewis 0 siblings, 0 replies; 268+ messages in thread From: Martin v. Loewis @ 2000-06-29 13:43 UTC (permalink / raw) To: mminnis; +Cc: gcc > What are these trying to tell me to do? These errors sprung up while in > the headers of the package I am trying to build. > > These confuse me. It complains that it is redefining something, but lists > the same place for each. No. First, it lists line 121, which starts the definition template <class _Tp> struct iterator_traits<const _Tp*> { typedef random_access_iterator_tag iterator_category; typedef _Tp value_type; typedef ptrdiff_t difference_type; typedef const _Tp* pointer; typedef const _Tp& reference; }; Then, it lists (as previous definition) line 118, which ends the definition template <class _Tp> struct iterator_traits<_Tp*> { typedef random_access_iterator_tag iterator_category; typedef _Tp value_type; typedef ptrdiff_t difference_type; typedef _Tp* pointer; typedef _Tp& reference; }; Now, these are not the same thing, as one of them is a const specialization. Could it be that there is a #define for const? Please look at the preprocessor output to make sure they still look as they did in the header. Regards, Martin ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: SSA implementation 2000-06-29 11:59 ` Geoff Keating 2000-06-29 12:07 ` Errors from Gcc Matt Minnis @ 2000-06-29 12:11 ` Mark Mitchell 2000-06-29 12:24 ` Gerald Pfeifer 1 sibling, 1 reply; 268+ messages in thread From: Mark Mitchell @ 2000-06-29 12:11 UTC (permalink / raw) To: geoffk; +Cc: ddolan, gcc, oldham >>>>> "Geoff" == Geoff Keating <geoffk@cygnus.com> writes: Geoff> It does turn the code into SSA form. That's close to Geoff> everything we want it to do. In the future there will be Geoff> other things done while the code is in SSA form, but they Geoff> will be separate passes. We will be contributing a dead-code elimination pass in the very near future that operates on the SSA form. One big improvement is that this algorithm is a) very fast and b) can eliminate loops in things like: void f () { int i; for (i = 0; i < 100; ++i) ; } Jeffrey Oldham has a mostly working implementation of this algorithm. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: SSA implementation 2000-06-29 12:11 ` SSA implementation Mark Mitchell @ 2000-06-29 12:24 ` Gerald Pfeifer 0 siblings, 0 replies; 268+ messages in thread From: Gerald Pfeifer @ 2000-06-29 12:24 UTC (permalink / raw) To: Mark Mitchell; +Cc: geoffk, ddolan, gcc, oldham On Thu, 29 Jun 2000, Mark Mitchell wrote: > We will be contributing a dead-code elimination pass in the very near > future that operates on the SSA form. One big improvement is that > this algorithm is a) very fast and b) can eliminate loops in things > like: > > void f () { > int i; > for (i = 0; i < 100; ++i) > ; > } When you do so, please don't also update the "Deleting ``empty'' loops" section in the GCC manual. Some time ago I added a note that in the future the behavior described there will change which apparently is going to happen now. :-) Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ Have a look at http://petition.eurolinux.org -- it's not about Linux, btw! ^ permalink raw reply [flat|nested] 268+ messages in thread
* PowerPC code generation @ 2000-07-05 11:52 ` David J Schinsing 2000-07-05 12:15 ` David Young 2000-07-05 13:26 ` PowerPC code generation Geoff Keating 0 siblings, 2 replies; 268+ messages in thread From: David J Schinsing @ 2000-07-05 11:52 UTC (permalink / raw) To: gcc Hi, What can I do to get gcc to generate byte-reversed loads and stores (like the lwbrx instruction, for example). Perhaps there's a way to define a structure so as to generate them? Thanks, David David J. Schinsing Performance Technologies, Inc. http://www.pt.com/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: PowerPC code generation 2000-07-05 11:52 ` PowerPC code generation David J Schinsing @ 2000-07-05 12:15 ` David Young 2000-07-05 12:57 ` gcc and struct passing in function arguments? David Young 2000-07-05 13:26 ` PowerPC code generation Geoff Keating 1 sibling, 1 reply; 268+ messages in thread From: David Young @ 2000-07-05 12:15 UTC (permalink / raw) To: David J Schinsing; +Cc: gcc You may want to look at: http://www.publicsource.apple.com http://www.publicsource.apple.com/projects/darwin/projects.html http://www.publicsource.apple.com/projects/darwin/source/other/egcs-814.1-1.1.tar.gz It may contain your answer. Thanks A Bunch! David Young; VVI-DCS dyoung@vvi.com Begin forwarded message: Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm List-Archive: < http://gcc.gnu.org/ml/gcc/ > List-Post: < mailto:gcc@gcc.gnu.org > List-Help: < http://egcs.cygnus.com/ml/ > Sender: gcc-owner@gcc.gnu.org Delivered-To: mailing list gcc@gcc.gnu.org Subject: PowerPC code generation To: gcc@gcc.gnu.org From: "David J Schinsing" <dxs@pt.com> Date: Wed, 5 Jul 2000 14:47:53 -0400 X-Mimetrack: Serialize by Router on notes1/PTI(Release 5.0.2c |February 2, 2000) at 07/05/2000 02:47:55 PM Hi, What can I do to get gcc to generate byte-reversed loads and stores (like the lwbrx instruction, for example). Perhaps there's a way to define a structure so as to generate them? Thanks, David David J. Schinsing Performance Technologies, Inc. http://www.pt.com/ ^ permalink raw reply [flat|nested] 268+ messages in thread
* gcc and struct passing in function arguments? 2000-07-05 12:15 ` David Young @ 2000-07-05 12:57 ` David Young 2000-07-05 13:09 ` Michael Meissner 2000-07-05 13:50 ` Alan Lehotsky 0 siblings, 2 replies; 268+ messages in thread From: David Young @ 2000-07-05 12:57 UTC (permalink / raw) To: gcc Hi! Does anyone know if... gcc can do struct passing in arguments and return of functions? (not pointer to struct, but struct by value) Is there a 32 byte limit (or similar) to this? Is this feature ANSI-C compliant? Thanks A Bunch! David Young; VVI-DCS dyoung@vvi.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: gcc and struct passing in function arguments? 2000-07-05 12:57 ` gcc and struct passing in function arguments? David Young @ 2000-07-05 13:09 ` Michael Meissner 2000-07-05 14:00 ` Joern Rennecke 2000-07-05 13:50 ` Alan Lehotsky 1 sibling, 1 reply; 268+ messages in thread From: Michael Meissner @ 2000-07-05 13:09 UTC (permalink / raw) To: David.Young; +Cc: gcc On Wed, Jul 05, 2000 at 04:08:35PM -0400, David Young wrote: > Hi! > > Does anyone know if... > > gcc can do struct passing in arguments and return of functions? > (not pointer to struct, but struct by value) > Is there a 32 byte limit (or similar) to this? > Is this feature ANSI-C compliant? It depends on the ABI. Different ABI's do different things. For example, powerpc-eabi or powerpc-linux always passes structures by copying the structure to a temporary location on the stack and passing the address of the temporary. For AIX, the first 8 words of integral and structure arguments are passed in registers and the remaining elements are passed on the stack. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: meissner@redhat.com phone: +1 978-486-9304 Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482 ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: gcc and struct passing in function arguments? 2000-07-05 13:09 ` Michael Meissner @ 2000-07-05 14:00 ` Joern Rennecke 0 siblings, 0 replies; 268+ messages in thread From: Joern Rennecke @ 2000-07-05 14:00 UTC (permalink / raw) To: Michael Meissner; +Cc: David.Young, gcc > It depends on the ABI. Different ABI's do different things. For example, > powerpc-eabi or powerpc-linux always passes structures by copying the structure > to a temporary location on the stack and passing the address of the temporary. i386-linux has several ABIs. linux-elf uses the SYSV ABI and therefore returns structures and unions in memory. linux-aout returns them in registers if the mode is suitable (i.e. SImode or DImode). You can use -freg-struct-return with linux-elf, but it causes problems if you link with any library function that returns a struct, or call one that gets passed a pointer to a function that returns a struct. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: gcc and struct passing in function arguments? 2000-07-05 12:57 ` gcc and struct passing in function arguments? David Young 2000-07-05 13:09 ` Michael Meissner @ 2000-07-05 13:50 ` Alan Lehotsky 1 sibling, 0 replies; 268+ messages in thread From: Alan Lehotsky @ 2000-07-05 13:50 UTC (permalink / raw) To: David.Young; +Cc: gcc Yes, gcc can pass and return structures by value. It is implementation dependent how this is accomplished and whether the values are returned via a caller-supplied temporary. Many compilers will return structures that are 64 bits or smaller in the result registers (assuming that doubles are returned in a pair of 32 bit registers). All other compilers that I'm aware of pass a hidden extra in-parameter that's the address of a structure temporary. The called-function stores the results into that temporary. -- Al ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: PowerPC code generation 2000-07-05 11:52 ` PowerPC code generation David J Schinsing 2000-07-05 12:15 ` David Young @ 2000-07-05 13:26 ` Geoff Keating 2000-07-05 13:53 ` Franz Sirl 1 sibling, 1 reply; 268+ messages in thread From: Geoff Keating @ 2000-07-05 13:26 UTC (permalink / raw) To: David J Schinsing; +Cc: gcc "David J Schinsing" <dxs@pt.com> writes: > What can I do to get gcc to generate byte-reversed loads and stores > (like the lwbrx instruction, for example). Perhaps there's a way to define > a structure so as to generate them? You can use asm statements, like asm ("lwbrx %0, 0, %1" : "=r"(result) : "r"(&input), "X"(input)); at present, there is no way to have gcc generate such code without using asm statements. -- - Geoffrey Keating <geoffk@cygnus.com> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: PowerPC code generation 2000-07-05 13:26 ` PowerPC code generation Geoff Keating @ 2000-07-05 13:53 ` Franz Sirl 2000-07-05 14:20 ` Michael Meissner 2000-07-05 14:36 ` Geoff Keating 0 siblings, 2 replies; 268+ messages in thread From: Franz Sirl @ 2000-07-05 13:53 UTC (permalink / raw) To: Geoff Keating; +Cc: David J Schinsing, gcc At 22:26 05.07.00, Geoff Keating wrote: >"David J Schinsing" <dxs@pt.com> writes: > > > What can I do to get gcc to generate byte-reversed loads and stores > > (like the lwbrx instruction, for example). Perhaps there's a way to define > > a structure so as to generate them? > >You can use asm statements, like > >asm ("lwbrx %0, 0, %1" : "=r"(result) : "r"(&input), "X"(input)); > >at present, there is no way to have gcc generate such code without >using asm statements. Just out of interest, if I would implement __attribute__((little_endian)) and __attribute__((big_endian)) for MEM's, basically the major work would be to create something like a "revmovsi" pattern in the .md and tell compiler how to use it, or? Which pass of the compiler would be responsible for that? reload? Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: PowerPC code generation 2000-07-05 13:53 ` Franz Sirl @ 2000-07-05 14:20 ` Michael Meissner 2000-07-05 14:36 ` Geoff Keating 1 sibling, 0 replies; 268+ messages in thread From: Michael Meissner @ 2000-07-05 14:20 UTC (permalink / raw) To: Franz Sirl; +Cc: Geoff Keating, David J Schinsing, gcc On Wed, Jul 05, 2000 at 10:52:45PM +0200, Franz Sirl wrote: > At 22:26 05.07.00, Geoff Keating wrote: > >"David J Schinsing" <dxs@pt.com> writes: > > > > > What can I do to get gcc to generate byte-reversed loads and stores > > > (like the lwbrx instruction, for example). Perhaps there's a way to define > > > a structure so as to generate them? > > > >You can use asm statements, like > > > >asm ("lwbrx %0, 0, %1" : "=r"(result) : "r"(&input), "X"(input)); > > > >at present, there is no way to have gcc generate such code without > >using asm statements. > > Just out of interest, if I would implement __attribute__((little_endian)) > and __attribute__((big_endian)) for MEM's, basically the major work would > be to create something like a "revmovsi" pattern in the .md and tell > compiler how to use it, or? Which pass of the compiler would be responsible > for that? reload? The fundamental problem is that __attribute__ type definitions aren't completely types, so for example you can't declare a pointer type to a little_endian or big_endian type. Which also means things get messy for whether judging things are of comparable type.... Jim Wilson, you had a canonical list of problems with __attributes__ the last n times we looked into this -- maybe you could post the list once again. A more feasible approach is to add little_endian{2,4,8} and big_endian{2,4,8} builtin functions, and optimize these on a machine basis. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: meissner@redhat.com phone: +1 978-486-9304 Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482 ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: PowerPC code generation 2000-07-05 13:53 ` Franz Sirl 2000-07-05 14:20 ` Michael Meissner @ 2000-07-05 14:36 ` Geoff Keating 2000-07-05 19:54 ` David Edelsohn 1 sibling, 1 reply; 268+ messages in thread From: Geoff Keating @ 2000-07-05 14:36 UTC (permalink / raw) To: Franz.Sirl-kernel; +Cc: dxs, gcc > Date: Wed, 05 Jul 2000 22:52:45 +0200 > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com> > Just out of interest, if I would implement __attribute__((little_endian)) > and __attribute__((big_endian)) for MEM's, basically the major work would > be to create something like a "revmovsi" pattern in the .md and tell > compiler how to use it, or? Which pass of the compiler would be responsible > for that? reload? You'd probably make the front-end generate code which just does a load followed by a bit-reversal (eg. unsigned tmp1 = foo->x tmp2 = (tmp1 << 24) | (tmp1 >> 24) | (tmp1 >> 8 & 0x0000FF00) | (tmp1 << 8 & 0x00FF0000) and then have combine turn this into a single pattern which does the load and bit reversal simultaneously. So there are two jobs: first, implement the __attribute__ stuff; then, make it use the nifty instructions. The first part is the more tedious, but easier part, and it'd probably be useful to many people. -- - Geoffrey Keating <geoffk@cygnus.com> ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: PowerPC code generation 2000-07-05 14:36 ` Geoff Keating @ 2000-07-05 19:54 ` David Edelsohn 0 siblings, 0 replies; 268+ messages in thread From: David Edelsohn @ 2000-07-05 19:54 UTC (permalink / raw) To: Geoff Keating; +Cc: Franz.Sirl-kernel, dxs, gcc About five years ago, I looked into adding patterns so that combine would recognize bit-reversal shifts and ORs to use the PowerPC byte reversal instruction. It requires a large number of intermediate, valid patterns so that GCC combine pass eventually will combine enough of the pieces so that it discovers the byte-reversal instruction. David ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <25>]
[parent not found: <May>]
[parent not found: <2001>]
[parent not found: <10:06:51>]
[parent not found: <+0300>]
* Another RFC: regex in libiberty @ 2001-06-07 18:27 ` DJ Delorie 2001-06-07 18:31 ` Ian Lance Taylor ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: DJ Delorie @ 2001-06-07 18:27 UTC (permalink / raw) To: gcc, gdb, binutils, cygwin [More lists added to get a wider audience] I didn't get a clear feeling about what people wanted wrt this. I saw three people propose three versions of regex, not much to go on. Is this a big deal? Will it really get used by everyone who currently has their own regex? Is it important to try to use a BSD-licensed regex to minimize future problems? The two contenders seem to be a modified GNU regex and the ever-popular Henry Spencer's regex. Does anyone have any strong opinions for either of these, or against any regex in libiberty at all? ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-07 18:27 ` Another RFC: regex in libiberty DJ Delorie @ 2001-06-07 18:31 ` Ian Lance Taylor 2001-06-07 18:33 ` DJ Delorie 2001-06-08 0:11 ` Eli Zaretskii 2001-06-09 13:34 ` Andrew Cagney 2 siblings, 1 reply; 268+ messages in thread From: Ian Lance Taylor @ 2001-06-07 18:31 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc, gdb, binutils, cygwin DJ Delorie <dj@redhat.com> writes: > [More lists added to get a wider audience] > > I didn't get a clear feeling about what people wanted wrt this. I saw > three people propose three versions of regex, not much to go on. Is > this a big deal? Will it really get used by everyone who currently > has their own regex? Is it important to try to use a BSD-licensed > regex to minimize future problems? > > The two contenders seem to be a modified GNU regex and the > ever-popular Henry Spencer's regex. Does anyone have any strong > opinions for either of these, or against any regex in libiberty at > all? gdb already ships with gnu-regex.c. Why not just move that to libiberty? I can't see any reason for a BSD-licensed regex in libiberty. libiberty already GPL code. Ian ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-07 18:31 ` Ian Lance Taylor @ 2001-06-07 18:33 ` DJ Delorie 2001-06-07 18:43 ` Ian Lance Taylor 0 siblings, 1 reply; 268+ messages in thread From: DJ Delorie @ 2001-06-07 18:33 UTC (permalink / raw) To: ian; +Cc: gcc, gdb, binutils, cygwin > gdb already ships with gnu-regex.c. Why not just move that to > libiberty? Because gdb, tcl, expect, cygwin, and gcc each have a copy of regex, and they're all different. Which to choose? > I can't see any reason for a BSD-licensed regex in libiberty. > libiberty already GPL code. Any regex added to libiberty becomes part of newlib and cygwin as well, and those projects are sensitive to GPL vs non-GPL licensing issues. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-07 18:33 ` DJ Delorie @ 2001-06-07 18:43 ` Ian Lance Taylor 0 siblings, 0 replies; 268+ messages in thread From: Ian Lance Taylor @ 2001-06-07 18:43 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc, gdb, binutils, cygwin DJ Delorie <dj@delorie.com> writes: > > gdb already ships with gnu-regex.c. Why not just move that to > > libiberty? > > Because gdb, tcl, expect, cygwin, and gcc each have a copy of regex, > and they're all different. Which to choose? The ones in gdb and gcc are basically the same. TCL and Expect are not GNU projects, and will continue to have their own regex code. Cygwin has different licensing constraints; cygwin already has its own copy of getopt, for instance. > > I can't see any reason for a BSD-licensed regex in libiberty. > > libiberty already GPL code. > > Any regex added to libiberty becomes part of newlib and cygwin as > well, and those projects are sensitive to GPL vs non-GPL licensing > issues. I see no reason to confuse the regex in libiberty with the regex in newlib and cygwin, any more than there is to confuse the getopt in libiberty. regex in libiberty should satisfy the needs of GNU tools, and as such I think it is appropriate to use the GNU regex. Of course, if the GNU regex is inferior, then it might make sense to choose something else. But I don't think we should avoid using GNU code for GNU tools because of licensing issues for non-GNU tools. Ian ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-07 18:27 ` Another RFC: regex in libiberty DJ Delorie 2001-06-07 18:31 ` Ian Lance Taylor @ 2001-06-08 0:11 ` Eli Zaretskii 2001-06-08 9:18 ` Mark Mitchell ` (2 more replies) 2001-06-09 13:34 ` Andrew Cagney 2 siblings, 3 replies; 268+ messages in thread From: Eli Zaretskii @ 2001-06-08 0:11 UTC (permalink / raw) To: dj; +Cc: gcc, gdb, binutils, cygwin > Date: Thu, 7 Jun 2001 21:27:31 -0400 > From: DJ Delorie <dj@redhat.com> > > I didn't get a clear feeling about what people wanted wrt this. I saw > three people propose three versions of regex, not much to go on. Is > this a big deal? Will it really get used by everyone who currently > has their own regex? Is it important to try to use a BSD-licensed > regex to minimize future problems? > > The two contenders seem to be a modified GNU regex and the > ever-popular Henry Spencer's regex. Does anyone have any strong > opinions for either of these, or against any regex in libiberty at > all? One notorious problem with GNU regex is that it is quite slow for many simple jobs, such as matching a simple regular expression with no backtracking. It seems that the main reason for this slowness is the fact that GNU regex supports null characters in strings. For examnple, Sed 3.02 compiled with GNU regex is about 2-4 times slower on simple jobs than the same Sed compiled with Spencer's regex library. (The DJGPP port of Sed is actually distributed with two executables, one build with GNU regex, the other with Spencer's, for this very reason.) So perhaps it might help to have more than just GNU regex in libiberty, for those applications that don't need to support null characters, and where regular expressions are used a lot, and so need to be fast. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-08 0:11 ` Eli Zaretskii @ 2001-06-08 9:18 ` Mark Mitchell 2001-06-08 9:59 ` Zack Weinberg 2001-06-11 22:50 ` Jim Blandy 2 siblings, 0 replies; 268+ messages in thread From: Mark Mitchell @ 2001-06-08 9:18 UTC (permalink / raw) To: eliz; +Cc: dj, gcc, gdb, binutils, cygwin >>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes: >> The two contenders seem to be a modified GNU regex and the >> ever-popular Henry Spencer's regex. Does anyone have any >> strong opinions for either of these, or against any regex in >> libiberty at all? My opinion may or may not matter on this debate, but here it is. Since libiberty for use in GNU software, we must use GNU regex. If GNU regex is slow, we should make it faster. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-08 0:11 ` Eli Zaretskii 2001-06-08 9:18 ` Mark Mitchell @ 2001-06-08 9:59 ` Zack Weinberg 2001-06-08 10:05 ` H . J . Lu 2001-06-08 10:37 ` Eli Zaretskii 2001-06-11 22:50 ` Jim Blandy 2 siblings, 2 replies; 268+ messages in thread From: Zack Weinberg @ 2001-06-08 9:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dj, gcc, gdb, binutils, cygwin On Fri, Jun 08, 2001 at 10:06:51AM +0300, Eli Zaretskii wrote: > > One notorious problem with GNU regex is that it is quite slow for many > simple jobs, such as matching a simple regular expression with no > backtracking. It seems that the main reason for this slowness is the > fact that GNU regex supports null characters in strings. For > examnple, Sed 3.02 compiled with GNU regex is about 2-4 times slower > on simple jobs than the same Sed compiled with Spencer's regex > library. I think the null characters are a red herring. I looked into GNU regex's performance in the context of GCC's fixincludes program, last year. On a platform that has mostly-okay headers, fixincludes spends most of its time matching regular expressions. The regex.c that came with GDB 4.18, which I think is the one that got spread around widely, had a bug in its implementation of the POSIX regcomp/regexec interface, which caused a major performance hit. That bug has been fixed in GNU libc for a long time. When I replaced fixincludes' copy of regex.c with a more recent version from glibc, fixincludes was sped up by a factor of nine. That same bug affects Sed 3.02 - replace the regex.c it ships with with the one from glibc 2.2.x and I bet you'll see better performance. There's some discussion in these messages: http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00764.html http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00765.html The relevant fix is in there, too, if you want to pull it out and apply it. I did some benchmarking of fixincludes with Spencer's regexp library as well. IIRC, it was about the same as the fixed GNU regex.c. -- zw This is, no doubt, the rational strategy; quite possibly the only one that will work. But it ignores the exigiencies of the tenure system and is therefore impractical. -- Jerry Fodor, _The Mind Doesn't Work That Way_ ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-08 9:59 ` Zack Weinberg @ 2001-06-08 10:05 ` H . J . Lu 2001-06-08 10:31 ` Eli Zaretskii 2001-06-08 10:37 ` Eli Zaretskii 1 sibling, 1 reply; 268+ messages in thread From: H . J . Lu @ 2001-06-08 10:05 UTC (permalink / raw) To: Zack Weinberg; +Cc: Eli Zaretskii, dj, gcc, gdb, binutils, cygwin On Fri, Jun 08, 2001 at 09:59:32AM -0700, Zack Weinberg wrote: > > The regex.c that came with GDB 4.18, which I think is the one that got > spread around widely, had a bug in its implementation of the POSIX > regcomp/regexec interface, which caused a major performance hit. That > bug has been fixed in GNU libc for a long time. When I replaced > fixincludes' copy of regex.c with a more recent version from glibc, > fixincludes was sped up by a factor of nine. That same bug affects > Sed 3.02 - replace the regex.c it ships with with the one from glibc > 2.2.x and I bet you'll see better performance. > I have been telling people that you should use regex.c in glibc if all possible if you are using gnu-regex. Every package which uses gnu-regex should have a configuration option not to use the included gnu-regex. H.J. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-08 10:05 ` H . J . Lu @ 2001-06-08 10:31 ` Eli Zaretskii 2001-06-08 10:39 ` H . J . Lu 0 siblings, 1 reply; 268+ messages in thread From: Eli Zaretskii @ 2001-06-08 10:31 UTC (permalink / raw) To: hjl; +Cc: zackw, dj, gcc, gdb, binutils, cygwin > Date: Fri, 8 Jun 2001 10:05:32 -0700 > From: "H . J . Lu" <hjl@lucon.org> > > On Fri, Jun 08, 2001 at 09:59:32AM -0700, Zack Weinberg wrote: > > > > The regex.c that came with GDB 4.18, which I think is the one that got > > spread around widely, had a bug in its implementation of the POSIX > > regcomp/regexec interface, which caused a major performance hit. That > > bug has been fixed in GNU libc for a long time. When I replaced > > fixincludes' copy of regex.c with a more recent version from glibc, > > fixincludes was sped up by a factor of nine. That same bug affects > > Sed 3.02 - replace the regex.c it ships with with the one from glibc > > 2.2.x and I bet you'll see better performance. > > > > I have been telling people that you should use regex.c in glibc if > all possible if you are using gnu-regex. Every package which uses > gnu-regex should have a configuration option not to use the included > gnu-regex. Sed does have such an option (I used it to build the binary with Spencer's regex which is the standard regex included in the DJGPP library). ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-08 10:31 ` Eli Zaretskii @ 2001-06-08 10:39 ` H . J . Lu 0 siblings, 0 replies; 268+ messages in thread From: H . J . Lu @ 2001-06-08 10:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: zackw, dj, gcc, gdb, binutils, cygwin On Fri, Jun 08, 2001 at 08:26:00PM +0300, Eli Zaretskii wrote: > > > > I have been telling people that you should use regex.c in glibc if > > all possible if you are using gnu-regex. Every package which uses > > gnu-regex should have a configuration option not to use the included > > gnu-regex. > > Sed does have such an option (I used it to build the binary with > Spencer's regex which is the standard regex included in the DJGPP > library). Glad to hear that. It makes even more senses when gnu-regex is the standard regex in the system C library. H.J. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-08 9:59 ` Zack Weinberg 2001-06-08 10:05 ` H . J . Lu @ 2001-06-08 10:37 ` Eli Zaretskii 1 sibling, 0 replies; 268+ messages in thread From: Eli Zaretskii @ 2001-06-08 10:37 UTC (permalink / raw) To: zackw; +Cc: dj, gcc, gdb, binutils, cygwin > From: "Zack Weinberg" <zackw@stanford.edu> > Date: Fri, 8 Jun 2001 09:59:32 -0700 > > On Fri, Jun 08, 2001 at 10:06:51AM +0300, Eli Zaretskii wrote: > > > > One notorious problem with GNU regex is that it is quite slow for many > > simple jobs, such as matching a simple regular expression with no > > backtracking. It seems that the main reason for this slowness is the > > fact that GNU regex supports null characters in strings. For > > examnple, Sed 3.02 compiled with GNU regex is about 2-4 times slower > > on simple jobs than the same Sed compiled with Spencer's regex > > library. > > I think the null characters are a red herring. It's possible; I never had time to look into it far enough to be sure. All I know is that the slow-down happened between two specific versions of GNU regex, and the support for null characters was introduced between those two versions. > The regex.c that came with GDB 4.18, which I think is the one that got > spread around widely, had a bug in its implementation of the POSIX > regcomp/regexec interface, which caused a major performance hit. That > bug has been fixed in GNU libc for a long time. When I replaced > fixincludes' copy of regex.c with a more recent version from glibc, > fixincludes was sped up by a factor of nine. That same bug affects > Sed 3.02 - replace the regex.c it ships with with the one from glibc > 2.2.x and I bet you'll see better performance. > > There's some discussion in these messages: > > http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00764.html > http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00765.html Thanks for the pointers. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-08 0:11 ` Eli Zaretskii 2001-06-08 9:18 ` Mark Mitchell 2001-06-08 9:59 ` Zack Weinberg @ 2001-06-11 22:50 ` Jim Blandy 2001-06-11 23:51 ` Randall R Schulz 2001-06-12 6:48 ` Jim Blandy 2 siblings, 2 replies; 268+ messages in thread From: Jim Blandy @ 2001-06-11 22:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: dj, gcc, gdb, binutils, cygwin "Eli Zaretskii" <eliz@is.elta.co.il> writes: > One notorious problem with GNU regex is that it is quite slow for many > simple jobs, such as matching a simple regular expression with no > backtracking. It seems that the main reason for this slowness is the > fact that GNU regex supports null characters in strings. For > examnple, Sed 3.02 compiled with GNU regex is about 2-4 times slower > on simple jobs than the same Sed compiled with Spencer's regex > library. (The DJGPP port of Sed is actually distributed with two > executables, one build with GNU regex, the other with Spencer's, for > this very reason.) I'm suspicious of this assertion. I've worked on GNU regexp in the past, and I don't see any reason this should be so. However, I was messing around with regexps a lot when GNU regexp suddenly became slow on certain regexps. I looked into the cause, and it turned out that this was because GNU regexp had been made to comply with the POSIX regexp specification. POSIX regexp semantics require that the regexp match the longest possible string (I may have the details wrong, but it's something like that). For backtracking regexp engines (the GNU, Henry Spencer, and Perl regexp matchers are all of this design), that innocent-sounding constraint basically requires insanely slow behavior. GNU regexp has a flag that allows you to turn this behavior off, and get the traditional, faster, non-POSIX-compliant behavior. So I don't see any reason the GNU regexp library couldn't serve all the GPL'd software's needs. ---- The details, for the curious: Suppose you have a regexp like this (assume the obvious metacharacters) (FOObar|FOO)(barbar)+ ---a-- -b- ---c-- <= labels for pieces of the regexp which you're matching against the string FOObarbarbarbar 0 3 6 9 12 and let's suppose you're calling the regexp library in a manner which asks "does a prefix of this string match this regexp?" (That is, you're not asking "does this regexp match this entire string?") The traditional behavior is for the regexp engine to match part ---a-- of the regexp against data[0..5], match one repetition of part ---c-- against data[6..8], and say it's done. The Perl regexp matcher will return this match. But this isn't the behavior POSIX requires. POSIX says you must return the *longest possible* match. So a POSIX-compliant matcher must match -b- against data[0..2], and then two repetitions of ---c-- against data[3..8] and data[9..14]. This is a longer match. To find the longest match, in general, a backtracking matcher has to generate every possible match, and return the longest one it found. This is what GNU regexp does. So, just how bad is this? Well, suppose you're matching a regexp like: .*.*.*.*.*.* against a string like aaaaaaaaaaaaaaaaaaaa To generate every possible match, you have to choose every possible way to divide up those twenty a's amongst six .* patterns. I think this is 20 choose 5, or 1.9 million, matches you have to try. In general, I think the time to match POSIXly can increase exponentially in the length of your regexp, given a long enough data string. If you have a smart regexp compiler (I understand Perl is pretty clever), then you could probably handle this regexp with a bit more aplomb. But I'll bet that I can find a regexp where you really do have to try all matchings, no matter how smart your regexp compiler is. (So think of that the next time you propose some innocent-sounding constraint, like "longest match always"!) Anyway, the outcome is that all the really popular regexp matchers either don't implement the POSIX behavior, or provide options to turn it off. For GNU regexp, you can use the RE_NO_POSIX_BACKTRACKING flag, and you'll get the traditional not-always-the-longest-match nice fast behavior. Perl simply documents the traditional behavior ("The [Perl regexp] engine thinks locally and acts globally," as the Camel book puts it). ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-11 22:50 ` Jim Blandy @ 2001-06-11 23:51 ` Randall R Schulz 2001-06-12 6:48 ` Jim Blandy 1 sibling, 0 replies; 268+ messages in thread From: Randall R Schulz @ 2001-06-11 23:51 UTC (permalink / raw) To: Jim Blandy, Eli Zaretskii; +Cc: dj, gcc, gdb, binutils Jim, [ This isn't cygwin-specific, so I removed it from the recipient list. ] Your analysis is correct, basically, but the requirement for "maximum bite" or "greediness" (as it's variously called) is quite common and has been the behavior of all the Unix-based or -inspired regular expression matchers I've worked with for about 20 years. If there are regular expression matchers out there that do otherwise, I haven't encountered them. The maximum bite requirement really is far from "insane," because without it, there's no other well-defined and meaningful specification of how (much) to match when the regular expression is ambiguous w.r.t. the target text. It would hardly do to just return the first match found, since that would (well, might) depend on implementation details. I'm not sure, but I'd want to think about whether relaxing maximum bite was significant w.r.t. the choice of NFA vs. DFA matcher (I don't know which approach is used by regex). It's fine to have an option to change this, I guess, but regular expression matchers that don't implement maximum bite by default would not be what people expect at all. Actually, I'm not certain how the user would be able to predict what would be matched if maximum bite were disabled. It seems to me that if you have an on / off option for maximum bite, then the only meaningful choice when maximum bite is off would be minimum bite, and for * that would always be zero and for + it would be one, so what's the point of closure? If there's no closure involved, then static examination of the regular expression (when the NFA or DFA is constructed) is enough to determine maximum bite, so there's no need for a performance hit. Implementing that optimization isn't difficult at all. As you suggest, there are other more subtle (but still well defined) optimizations that make some common cases much better behaved (e.g., detecting disjointedness of the sets of characters that can be matched at the boundaries of closed (* and +) or alternated (|) sub-expressions can be used to eliminate backtracking). Differentiating parenthesized sub-expressions that must be tracked for independent extraction from those that only group the sub-expression they enclose to override the normal operator precedence can also be used to advantage (I think). Anyway, I really don't think you should change this behavior--you'd be breaking regex. Maximum bite is specified for a reason--a good reason. Randall Schulz Mountain View, CA USA At 22:49 2001-06-11, Jim Blandy wrote: >"Eli Zaretskii" <eliz@is.elta.co.il> writes: > > One notorious problem with GNU regex is that it is quite slow for many > > simple jobs, such as matching a simple regular expression with no > > backtracking. It seems that the main reason for this slowness is the > > fact that GNU regex supports null characters in strings. For > > examnple, Sed 3.02 compiled with GNU regex is about 2-4 times slower > > on simple jobs than the same Sed compiled with Spencer's regex > > library. (The DJGPP port of Sed is actually distributed with two > > executables, one build with GNU regex, the other with Spencer's, for > > this very reason.) > >I'm suspicious of this assertion. I've worked on GNU regexp in the >past, and I don't see any reason this should be so. > >However, I was messing around with regexps a lot when GNU regexp >suddenly became slow on certain regexps. I looked into the cause, and >it turned out that this was because GNU regexp had been made to comply >with the POSIX regexp specification. POSIX regexp semantics require >that the regexp match the longest possible string (I may have the >details wrong, but it's something like that). For backtracking regexp >engines (the GNU, Henry Spencer, and Perl regexp matchers are all of >this design), that innocent-sounding constraint basically requires >insanely slow behavior. > >GNU regexp has a flag that allows you to turn this behavior off, and >get the traditional, faster, non-POSIX-compliant behavior. So I don't >see any reason the GNU regexp library couldn't serve all the GPL'd >software's needs. > >---- > >The details, for the curious: > >Suppose you have a regexp like this (assume the obvious >metacharacters) > > (FOObar|FOO)(barbar)+ > ---a-- -b- ---c-- <= labels for pieces of the regexp > >which you're matching against the string > > FOObarbarbarbar > 0 3 6 9 12 > >and let's suppose you're calling the regexp library in a manner which >asks "does a prefix of this string match this regexp?" (That is, >you're not asking "does this regexp match this entire string?") > >The traditional behavior is for the regexp engine to match part ---a-- >of the regexp against data[0..5], match one repetition of part ---c-- >against data[6..8], and say it's done. The Perl regexp matcher will >return this match. > >But this isn't the behavior POSIX requires. POSIX says you must >return the *longest possible* match. So a POSIX-compliant matcher >must match -b- against data[0..2], and then two repetitions of ---c-- >against data[3..8] and data[9..14]. This is a longer match. > >To find the longest match, in general, a backtracking matcher has to >generate every possible match, and return the longest one it found. >This is what GNU regexp does. > >So, just how bad is this? Well, suppose you're matching a regexp like: > > .*.*.*.*.*.* > >against a string like > > aaaaaaaaaaaaaaaaaaaa > >To generate every possible match, you have to choose every possible >way to divide up those twenty a's amongst six .* patterns. I think >this is 20 choose 5, or 1.9 million, matches you have to try. In >general, I think the time to match POSIXly can increase exponentially >in the length of your regexp, given a long enough data string. > >If you have a smart regexp compiler (I understand Perl is pretty >clever), then you could probably handle this regexp with a bit more >aplomb. But I'll bet that I can find a regexp where you really do >have to try all matchings, no matter how smart your regexp compiler >is. > >(So think of that the next time you propose some innocent-sounding >constraint, like "longest match always"!) > >Anyway, the outcome is that all the really popular regexp matchers >either don't implement the POSIX behavior, or provide options to turn >it off. For GNU regexp, you can use the RE_NO_POSIX_BACKTRACKING >flag, and you'll get the traditional not-always-the-longest-match nice >fast behavior. Perl simply documents the traditional behavior ("The >[Perl regexp] engine thinks locally and acts globally," as the Camel >book puts it). > >-- >Want to unsubscribe from this list? >Check out: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-11 22:50 ` Jim Blandy 2001-06-11 23:51 ` Randall R Schulz @ 2001-06-12 6:48 ` Jim Blandy 1 sibling, 0 replies; 268+ messages in thread From: Jim Blandy @ 2001-06-12 6:48 UTC (permalink / raw) To: Jim Blandy; +Cc: Eli Zaretskii, dj, gcc, gdb, binutils, cygwin Jim Blandy <jimb@cygnus.com> writes: > To generate every possible match, you have to choose every possible > way to divide up those twenty a's amongst six .* patterns. I think > this is 20 choose 5, or 1.9 million, matches you have to try. In > general, I think the time to match POSIXly can increase exponentially > in the length of your regexp, given a long enough data string. 20 choose 5 is, of course, only 15504, not 1.9 million. Oops. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Another RFC: regex in libiberty 2001-06-07 18:27 ` Another RFC: regex in libiberty DJ Delorie 2001-06-07 18:31 ` Ian Lance Taylor 2001-06-08 0:11 ` Eli Zaretskii @ 2001-06-09 13:34 ` Andrew Cagney 2 siblings, 0 replies; 268+ messages in thread From: Andrew Cagney @ 2001-06-09 13:34 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc, gdb, binutils, cygwin For GDB: For 5.0 it included its own REGEXP *but* if so configured and if the system GNU REGEXP is > version xyz, it could use that. For 5.1 (if someone remembers to do it) the logic was going to be switched. Use the system REGEXP provided it is > version XYZ. Well I think that is what we decided. Given GDB is GNU code, it shall use GNU regex. enjoy, Andrew ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <19990608202201.F17154@admin3.jump.net>]
[parent not found: <org142xios.fsf@saci.lsd.dcc.unicamp.br>]
[parent not found: <3761d206.15532319@mailer.gwdg.de>]
[parent not found: <oru2sg6sd1.fsf@saci.lsd.dcc.unicamp.br>]
[parent not found: <3762cfb6.8581897@mailer.gwdg.de>]
[parent not found: <oru2sf6hst.fsf@saci.lsd.dcc.unicamp.br>]
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. [not found] ` <oru2sf6hst.fsf@saci.lsd.dcc.unicamp.br> @ 1999-06-10 16:01 ` Philipp Thomas 1999-06-30 15:43 ` Philipp Thomas [not found] ` <376b1082.25172596@mailer.gwdg.de> 1 sibling, 1 reply; 268+ messages in thread From: Philipp Thomas @ 1999-06-10 16:01 UTC (permalink / raw) To: Alexandre Oliva; +Cc: egcs [Just a short explanation: I already had started an exchange with Alexandre on how to get to a good gccbug script to minimize those bug postings that are useless because the user either can't read or because he completely ignored gcc's message. As Alexandre stated that in his opinion we should have started the discussion on the list right away and I agree, I'm reposting this mail to egcs] On 10 Jun 1999 15:18:10 -0300, you wrote: >That's exactly why I'm suggesting a wrapper script. It would have to >get all the options passed to gcc, and it would even test whether the >compilation really failed. Well this gets complicated. Following your scenario, the script would have to do: - check for a Makefile, ask the user if this is the correct one to call (it could be a sub level makefile that can only be called by the toplevel one). - call make - capture the output - find the failing gcc call - parse the gcc call for all options - filter out any -o or -pipe option - do the call - record gcc's error messages - compress the preprocessed source - do mime64 or uuencoding - generate the message with all the info and attach the source - mail that to egcs-bugs. What do we do on BSD systems where no makefile needs to be present (i.e. using system default makefiles) ? I guess in that case the script could only ask if it should run make. What if the user want's to report (in his opinion) false warnings ? Seems that a script like that needs a shell wizard to write which I'm most definitely not. Otherwise I would try to come up with something that could at least serve as a starting point. Given that Nathan is setting up a gnats site for testing and given that we all agree that we definitely need some kind of bug tracking system, it seems we have to think about a proper gccbug script. I'd suggest we hash out the ideas a bit and then go to the list to (hopefully) get others interested. Good idea ? >If the user will have to figure out the compilation command to get the >preprocessed source, he could certainly figure it out to run gccbug on >it. That's what I thought ;) And it would be *much* easier to implement :) >> I can't think of a portable way to do mime (but I admit I've never >> dealt with questions like that before). So I think uuencode would be >> the simplest solution. > >But not as convenient :-( I *knew* that answer would come (it would have been mine too) :-) >We could generate MIME base64 on our own; it's not that hard, and >there must be some perl package to do it already :-) I guess so, but I don't know of any. I guess you don't have any hints at hand, do you ? >And then, we could run sendmail to deliver the message, or connect to >the egcs.cygnus.com smtp server directly, or, if everything else >fails, just create a file that the user should feed to `sendmail >egcs-bugs@egcs.cygnus.com'. Much too much hassle. I'd say lets store the file, ask the user if this should be sent directly (could be a Windows system with no directly callable mailer) , call mail to send it otherwise store it where the user wants it to be. That way you don't have to bother what mailer the user actually uses and you don't have to do direct mail transfer. Philipp -- You have moved your mouse. Windows must be rebooted for the changes to take effect. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-10 16:01 ` libs/csengine/basic/polyset.cpp:46: Internal compiler error 191 Philipp Thomas @ 1999-06-30 15:43 ` Philipp Thomas 0 siblings, 0 replies; 268+ messages in thread From: Philipp Thomas @ 1999-06-30 15:43 UTC (permalink / raw) To: Alexandre Oliva; +Cc: egcs [Just a short explanation: I already had started an exchange with Alexandre on how to get to a good gccbug script to minimize those bug postings that are useless because the user either can't read or because he completely ignored gcc's message. As Alexandre stated that in his opinion we should have started the discussion on the list right away and I agree, I'm reposting this mail to egcs] On 10 Jun 1999 15:18:10 -0300, you wrote: >That's exactly why I'm suggesting a wrapper script. It would have to >get all the options passed to gcc, and it would even test whether the >compilation really failed. Well this gets complicated. Following your scenario, the script would have to do: - check for a Makefile, ask the user if this is the correct one to call (it could be a sub level makefile that can only be called by the toplevel one). - call make - capture the output - find the failing gcc call - parse the gcc call for all options - filter out any -o or -pipe option - do the call - record gcc's error messages - compress the preprocessed source - do mime64 or uuencoding - generate the message with all the info and attach the source - mail that to egcs-bugs. What do we do on BSD systems where no makefile needs to be present (i.e. using system default makefiles) ? I guess in that case the script could only ask if it should run make. What if the user want's to report (in his opinion) false warnings ? Seems that a script like that needs a shell wizard to write which I'm most definitely not. Otherwise I would try to come up with something that could at least serve as a starting point. Given that Nathan is setting up a gnats site for testing and given that we all agree that we definitely need some kind of bug tracking system, it seems we have to think about a proper gccbug script. I'd suggest we hash out the ideas a bit and then go to the list to (hopefully) get others interested. Good idea ? >If the user will have to figure out the compilation command to get the >preprocessed source, he could certainly figure it out to run gccbug on >it. That's what I thought ;) And it would be *much* easier to implement :) >> I can't think of a portable way to do mime (but I admit I've never >> dealt with questions like that before). So I think uuencode would be >> the simplest solution. > >But not as convenient :-( I *knew* that answer would come (it would have been mine too) :-) >We could generate MIME base64 on our own; it's not that hard, and >there must be some perl package to do it already :-) I guess so, but I don't know of any. I guess you don't have any hints at hand, do you ? >And then, we could run sendmail to deliver the message, or connect to >the egcs.cygnus.com smtp server directly, or, if everything else >fails, just create a file that the user should feed to `sendmail >egcs-bugs@egcs.cygnus.com'. Much too much hassle. I'd say lets store the file, ask the user if this should be sent directly (could be a Windows system with no directly callable mailer) , call mail to send it otherwise store it where the user wants it to be. That way you don't have to bother what mailer the user actually uses and you don't have to do direct mail transfer. Philipp -- You have moved your mouse. Windows must be rebooted for the changes to take effect. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <376b1082.25172596@mailer.gwdg.de>]
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. [not found] ` <376b1082.25172596@mailer.gwdg.de> @ 1999-06-10 17:18 ` Alexandre Oliva 1999-06-10 17:50 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva 0 siblings, 2 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-06-10 17:18 UTC (permalink / raw) To: Philipp Thomas; +Cc: egcs On Jun 10, 1999, kthomas@gwdg.de (Philipp Thomas) wrote: > - check for a Makefile, ask the user if this is the correct one to call > (it could be a sublevel makefile that can only be called by the toplevel > one). > - call make > - capture the output > - find the failing gcc call > - parse the gcc call for all options Nope, I'm suggesting that the user should do this and call `gccbug gcc options', or make CC=`gccbug gcc'. > I'd suggest we hash out the ideas a bit and then go to the list to > (hopefully) get others interested. Good idea ? I had failed to notice that the discussion was going on in private :-) IMO, we should have already gone to the list... >> We could generate MIME base64 on our own; it's not that hard, and >> there must be some perl package to do it already :-) > I guess so, but I don't know of any. I guess you don't have any > hints at hand, do you ? Unfortunately not :-( > (could be a Windows system with no directly callable mailer) That's why I was suggesting to connect directly to the egcs MX. > That way you don't have to bother what mailer the user actually uses > and you don't have to do direct mail transfer. We do, because we have to make sure that MIME headers are properly introduced, otherwise the message will be useless. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-10 17:18 ` Alexandre Oliva @ 1999-06-10 17:50 ` Franz Sirl 1999-06-12 16:02 ` Alexandre Oliva 1999-06-30 15:43 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva 1 sibling, 2 replies; 268+ messages in thread From: Franz Sirl @ 1999-06-10 17:50 UTC (permalink / raw) To: Alexandre Oliva, Philipp Thomas; +Cc: egcs Am Thu, 10 Jun 1999 schrieb Alexandre Oliva: >On Jun 10, 1999, kthomas@gwdg.de (Philipp Thomas) wrote: >>> We could generate MIME base64 on our own; it's not that hard, and >>> there must be some perl package to do it already :-) > >> I guess so, but I don't know of any. I guess you don't have any >> hints at hand, do you ? > >Unfortunately not :-( MIME-Base64 MIME-Tools >> (could be a Windows system with no directly callable mailer) > >That's why I was suggesting to connect directly to the egcs MX. That's rubbish, a lot of people are behind firewalls and can't send mail directly. And dial-up users will probably be blocked by the egcs-server itself due to spam protection. Why not use http POST and respect http_proxy like lynx? Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-10 17:50 ` Franz Sirl @ 1999-06-12 16:02 ` Alexandre Oliva 1999-06-15 4:11 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva 1999-06-30 15:43 ` Franz Sirl 1 sibling, 2 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-06-12 16:02 UTC (permalink / raw) To: Franz Sirl; +Cc: Philipp Thomas, egcs On Jun 10, 1999, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote: > Am Thu, 10 Jun 1999 schrieb Alexandre Oliva: >> On Jun 10, 1999, kthomas@gwdg.de (Philipp Thomas) wrote: >>> (could be a Windows system with no directly callable mailer) >> >> That's why I was suggesting to connect directly to the egcs MX. > That's rubbish, a lot of people are behind firewalls and can't send > mail directly. It would only be used if there's no local mailer. And then, if we cannot contact the egcs MX, we'd have to fallback to file anyway. > Why not use http POST and respect http_proxy like lynx? Sounds good. What kind of infra-structure would we need at the egcs http server? -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-12 16:02 ` Alexandre Oliva @ 1999-06-15 4:11 ` Franz Sirl 1999-06-15 4:54 ` Alexandre Oliva 1999-06-30 15:43 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva 1 sibling, 2 replies; 268+ messages in thread From: Franz Sirl @ 1999-06-15 4:11 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Philipp Thomas, egcs At 01:01 13.06.99 , Alexandre Oliva wrote: > > Why not use http POST and respect http_proxy like lynx? > >Sounds good. What kind of infra-structure would we need at the egcs >http server? A cgi program? Shouldn't be to hard. Franz. PS. Would you mind updating the test_summary script in the branch too? I have an update for faq.html in my queue mentioning the script. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-15 4:11 ` Franz Sirl @ 1999-06-15 4:54 ` Alexandre Oliva 1999-06-30 15:43 ` Alexandre Oliva 1999-06-30 15:43 ` Franz Sirl 1 sibling, 1 reply; 268+ messages in thread From: Alexandre Oliva @ 1999-06-15 4:54 UTC (permalink / raw) To: Franz Sirl; +Cc: Philipp Thomas, egcs On Jun 15, 1999, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote: > Would you mind updating the test_summary script in the branch too? Absolutely! In fact, I had already updated it. :-) -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-15 4:54 ` Alexandre Oliva @ 1999-06-30 15:43 ` Alexandre Oliva 0 siblings, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-06-30 15:43 UTC (permalink / raw) To: Franz Sirl; +Cc: Philipp Thomas, egcs On Jun 15, 1999, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote: > Would you mind updating the test_summary script in the branch too? Absolutely! In fact, I had already updated it. :-) -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-15 4:11 ` Franz Sirl 1999-06-15 4:54 ` Alexandre Oliva @ 1999-06-30 15:43 ` Franz Sirl 1 sibling, 0 replies; 268+ messages in thread From: Franz Sirl @ 1999-06-30 15:43 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Philipp Thomas, egcs At 01:01 13.06.99 , Alexandre Oliva wrote: > > Why not use http POST and respect http_proxy like lynx? > >Sounds good. What kind of infra-structure would we need at the egcs >http server? A cgi program? Shouldn't be to hard. Franz. PS. Would you mind updating the test_summary script in the branch too? I have an update for faq.html in my queue mentioning the script. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-12 16:02 ` Alexandre Oliva 1999-06-15 4:11 ` Franz Sirl @ 1999-06-30 15:43 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-06-30 15:43 UTC (permalink / raw) To: Franz Sirl; +Cc: Philipp Thomas, egcs On Jun 10, 1999, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote: > Am Thu, 10 Jun 1999 schrieb Alexandre Oliva: >> On Jun 10, 1999, kthomas@gwdg.de (Philipp Thomas) wrote: >>> (could be a Windows system with no directly callable mailer) >> >> That's why I was suggesting to connect directly to the egcs MX. > That's rubbish, a lot of people are behind firewalls and can't send > mail directly. It would only be used if there's no local mailer. And then, if we cannot contact the egcs MX, we'd have to fallback to file anyway. > Why not use http POST and respect http_proxy like lynx? Sounds good. What kind of infra-structure would we need at the egcs http server? -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-10 17:50 ` Franz Sirl 1999-06-12 16:02 ` Alexandre Oliva @ 1999-06-30 15:43 ` Franz Sirl 1 sibling, 0 replies; 268+ messages in thread From: Franz Sirl @ 1999-06-30 15:43 UTC (permalink / raw) To: Alexandre Oliva, Philipp Thomas; +Cc: egcs Am Thu, 10 Jun 1999 schrieb Alexandre Oliva: >On Jun 10, 1999, kthomas@gwdg.de (Philipp Thomas) wrote: >>> We could generate MIME base64 on our own; it's not that hard, and >>> there must be some perl package to do it already :-) > >> I guess so, but I don't know of any. I guess you don't have any >> hints at hand, do you ? > >Unfortunately not :-( MIME-Base64 MIME-Tools >> (could be a Windows system with no directly callable mailer) > >That's why I was suggesting to connect directly to the egcs MX. That's rubbish, a lot of people are behind firewalls and can't send mail directly. And dial-up users will probably be blocked by the egcs-server itself due to spam protection. Why not use http POST and respect http_proxy like lynx? Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: libs/csengine/basic/polyset.cpp:46: Internal compiler error 191. 1999-06-10 17:18 ` Alexandre Oliva 1999-06-10 17:50 ` Franz Sirl @ 1999-06-30 15:43 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-06-30 15:43 UTC (permalink / raw) To: Philipp Thomas; +Cc: egcs On Jun 10, 1999, kthomas@gwdg.de (Philipp Thomas) wrote: > - check for a Makefile, ask the user if this is the correct one to call > (it could be a sublevel makefile that can only be called by the toplevel > one). > - call make > - capture the output > - find the failing gcc call > - parse the gcc call for all options Nope, I'm suggesting that the user should do this and call `gccbug gcc options', or make CC=`gccbug gcc'. > I'd suggest we hash out the ideas a bit and then go to the list to > (hopefully) get others interested. Good idea ? I had failed to notice that the discussion was going on in private :-) IMO, we should have already gone to the list... >> We could generate MIME base64 on our own; it's not that hard, and >> there must be some perl package to do it already :-) > I guess so, but I don't know of any. I guess you don't have any > hints at hand, do you ? Unfortunately not :-( > (could be a Windows system with no directly callable mailer) That's why I was suggesting to connect directly to the egcs MX. > That way you don't have to bother what mailer the user actually uses > and you don't have to do direct mail transfer. We do, because we have to make sure that MIME headers are properly introduced, otherwise the message will be useless. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files @ 1999-05-23 11:45 Mark Klein 1999-05-23 19:27 ` Jeffrey A Law 1999-05-31 21:36 ` Mark Klein 0 siblings, 2 replies; 268+ messages in thread From: Mark Klein @ 1999-05-23 11:45 UTC (permalink / raw) To: law; +Cc: egcs, java-discuss At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote: >I wouldn't worry about the extra .IMPORTs. In fact, it's a little known >aspect of SOM that the assembler is responsible for _not_ adding an imported >symbol to the undefined symbols for a module if that symbol is not actually >referenced. To which I responded: >Thanks ... brute force method it is! Just when I was starting to see the >_trees_ through the forest. :-) On further thought ... what will this do to other platforms requiring assemble_external? While this fix may work for PA-RISC, might it cause other problems elsewhere? -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-23 11:45 assemble_external on .class files Mark Klein @ 1999-05-23 19:27 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Mark Klein 1 sibling, 1 reply; 268+ messages in thread From: Jeffrey A Law @ 1999-05-23 19:27 UTC (permalink / raw) To: Mark Klein; +Cc: egcs, java-discuss In message < 4.1.19990523114346.00c77100@garfield.dis.com >you write: > >Thanks ... brute force method it is! Just when I was starting to see the > >_trees_ through the forest. :-) > > On further thought ... what will this do to other platforms requiring > assemble_external? While this fix may work for PA-RISC, might it cause > other problems elsewhere? I do not believe so -- first most systems don't require importing symbols. Second, we're already importing symbols which are never referenced on those few systems that need imports. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-23 19:27 ` Jeffrey A Law @ 1999-05-31 21:36 ` Jeffrey A Law 0 siblings, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw) To: Mark Klein; +Cc: egcs, java-discuss In message < 4.1.19990523114346.00c77100@garfield.dis.com >you write: > >Thanks ... brute force method it is! Just when I was starting to see the > >_trees_ through the forest. :-) > > On further thought ... what will this do to other platforms requiring > assemble_external? While this fix may work for PA-RISC, might it cause > other problems elsewhere? I do not believe so -- first most systems don't require importing symbols. Second, we're already importing symbols which are never referenced on those few systems that need imports. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: assemble_external on .class files 1999-05-23 11:45 assemble_external on .class files Mark Klein 1999-05-23 19:27 ` Jeffrey A Law @ 1999-05-31 21:36 ` Mark Klein 1 sibling, 0 replies; 268+ messages in thread From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw) To: law; +Cc: egcs, java-discuss At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote: >I wouldn't worry about the extra .IMPORTs. In fact, it's a little known >aspect of SOM that the assembler is responsible for _not_ adding an imported >symbol to the undefined symbols for a module if that symbol is not actually >referenced. To which I responded: >Thanks ... brute force method it is! Just when I was starting to see the >_trees_ through the forest. :-) On further thought ... what will this do to other platforms requiring assemble_external? While this fix may work for PA-RISC, might it cause other problems elsewhere? -- Mark Klein DIS International, Ltd. http://www.dis.com 415-892-8400 PGP Public Key Available ^ permalink raw reply [flat|nested] 268+ messages in thread
* Bug in libm or libstdc++. @ 1999-02-24 15:13 Paul Derbyshire [not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net > 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-24 15:13 UTC (permalink / raw) To: egcs, egcs-bugs C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to `atan(long double)' c:/djgpp/tmp/cc5PNfut.o(.text+0xa8):ntst.cc: undefined reference to `exp(long double)' c:/djgpp/tmp/cc5PNfut.o(.text+0xef):ntst.cc: undefined reference to `log(long double)' c:/djgpp/tmp/cc5PNfut.o(.text+0x136):ntst.cc: undefined reference to `log(long double)' c:/djgpp/tmp/cc5PNfut.o(.text+0x17d):ntst.cc: undefined reference to `sqrt(long double)' What the hell? Stroustrup 3rd Ed definitely informs me that long double overloads for these and other functions are supposed to be in either libm or libstdc++. Using egcs 1.1.1 and the libm and libstdc++ that came with it. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net >]
* Re: Bug in libm or libstdc++. [not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net > @ 1999-02-24 15:34 ` Joe Buck [not found] ` < 199902242332.PAA09334@atrus.synopsys.com > 1999-02-28 22:53 ` Joe Buck 1999-02-24 15:42 ` Bob McWhirter 1 sibling, 2 replies; 268+ messages in thread From: Joe Buck @ 1999-02-24 15:34 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs, egcs-bugs [ no "long double" overloads of math functions ] > Stroustrup 3rd Ed definitely informs me that long double overloads for > these and other functions are supposed to be in either libm or libstdc++. You have already been informed that libstdc++ is not complete. Sorry. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 199902242332.PAA09334@atrus.synopsys.com >]
* Re: Bug in libm or libstdc++. [not found] ` < 199902242332.PAA09334@atrus.synopsys.com > @ 1999-02-25 22:25 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net > 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-25 22:25 UTC (permalink / raw) To: egcs At 03:32 PM 2/24/99 PST, you wrote: >You have already been informed that libstdc++ is not complete. Sorry. The standard has been around in largely complete form for over a year, and finalized for many months. I am curious as to what is the cause for all of these omissions... I would love to help but I don't know the first thing about implementing these mathematical functions. In any case, to avoid any more unpleasant surprised I would like to see a list of all the omissions in the current libstdc++ and other non-conformances, and where possible ETAs for the missing components. It would be a good idea to post a periodic libstdc++ progress report and calls for volunteers to implement some of the stuff. I think that might attract more developers to fixing up and finishing implementing the standard C++ library. An area where I may be able to help is with the standard valarray and its friends, once I get back a response regarding making the compiler eliminate temporaries and excess copies in argument passing and return. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net >]
* Re: Bug in libm or libstdc++. [not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net > @ 1999-02-26 10:38 ` Joe Buck [not found] ` < 199902261836.KAA17757@atrus.synopsys.com > 1999-02-28 22:53 ` Joe Buck 0 siblings, 2 replies; 268+ messages in thread From: Joe Buck @ 1999-02-26 10:38 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs > At 03:32 PM 2/24/99 PST, you wrote: > >You have already been informed that libstdc++ is not complete. Sorry. > > The standard has been around in largely complete form for over a year, and > finalized for many months. I am curious as to what is the cause for all of > these omissions... Limited resources. Up to now most resources have been concentrated on completing the compiler portion of the standard, and we are very close. The only significant unimplemented feature is "export". > In any case, to avoid any more unpleasant surprised I would like to see a > list of all the omissions in the current libstdc++ and other > non-conformances, and where possible ETAs for the missing components. If you would like to volunteer to assemble such a list, and do most of the research yourself, you might find that others are willing to help. If you continue to demand that others do work, you will probably just create more hostility. As for ETAs, in the free software world the only answer you will get is "when it's ready". > It > would be a good idea to post a periodic libstdc++ progress report and calls > for volunteers to implement some of the stuff. I think that might attract > more developers to fixing up and finishing implementing the standard C++ > library. See http://sourceware.cygnus.com/libstdc++/ > An area where I may be able to help is with the standard valarray and its > friends, once I get back a response regarding making the compiler eliminate > temporaries and excess copies in argument passing and return. Again, see above. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 199902261836.KAA17757@atrus.synopsys.com >]
* Re: Bug in libm or libstdc++. [not found] ` < 199902261836.KAA17757@atrus.synopsys.com > @ 1999-02-26 22:21 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-26 22:21 UTC (permalink / raw) To: egcs At 10:36 AM 2/26/99 PST, you wrote: >Limited resources. Up to now most resources have been concentrated on >completing the compiler portion of the standard, and we are very close. >The only significant unimplemented feature is "export". My copy of Stroustrup makes no mention of "export", IIRC. >If you would like to volunteer to assemble such a list... Ack! Well, for starters: * <valarray> to be implemented * <limits> to be implemented * "void (*foo) (void) throw ();" causes a spurious error * IIRC stringstreams and <sstream> were incomplete/missing Anyone else who'se noticed an omission/incomplete thing/bug in C++ support that isn't platform-dependent is welcome to add to the list. >As for ETAs, in the free software world the only answer you will get is >"when it's ready". Or "when you do it yourself" right? <g> I may be able to cobble together a draft of a working <valarray>. If I come up with one amidst all the other work I'm doing on my own stuff, I'll be sure to offer it here. >See http://sourceware.cygnus.com/libstdc++/ OK -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net >]
* Re: Bug in libm or libstdc++. [not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > @ 1999-02-27 9:40 ` Marc Espie [not found] ` < 199902271740.SAA14323@quatramaran.ens.fr > 1999-02-28 22:53 ` Marc Espie 0 siblings, 2 replies; 268+ messages in thread From: Marc Espie @ 1999-02-27 9:40 UTC (permalink / raw) To: egcs In article < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > you write: >At 10:36 AM 2/26/99 PST, you wrote: >>Limited resources. Up to now most resources have been concentrated on >>completing the compiler portion of the standard, and we are very close. >>The only significant unimplemented feature is "export". >My copy of Stroustrup makes no mention of "export", IIRC. Get a newer one, or better yet, get a clue. I have the chance to read the egcs-ml thru an email to local news gateway. You know what ? You're the first individual to make my kill-file on this list. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 199902271740.SAA14323@quatramaran.ens.fr >]
* Re: Bug in libm or libstdc++. [not found] ` < 199902271740.SAA14323@quatramaran.ens.fr > @ 1999-02-27 20:45 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 0:19 ` Alexandre Oliva 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-27 20:45 UTC (permalink / raw) To: egcs At 06:40 PM 2/27/99 +0100, you wrote: >Get a newer one, or better yet, get a clue. 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as I've mentioned a few times before. 2. There is no need to be insulting. We're all mature adults here...or at least I thought we were... -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-27 20:45 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 0:19 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 06:40 PM 2/27/99 +0100, you wrote: >Get a newer one, or better yet, get a clue. 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as I've mentioned a few times before. 2. There is no need to be insulting. We're all mature adults here...or at least I thought we were... -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-27 20:45 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire @ 1999-03-01 0:19 ` Alexandre Oliva [not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br > 1999-03-31 23:46 ` Alexandre Oliva 1 sibling, 2 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-01 0:19 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 589 bytes --] On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote: > At 06:40 PM 2/27/99 +0100, you wrote: >> Get a newer one, or better yet, get a clue. > 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as > I've mentioned a few times before. It is outdated anyway. It is not the ANSI C++ Standard, and egcs targets the ANSI C++ Standard, not the ARM. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < ord82tlj4l.fsf@araguaia.dcc.unicamp.br >]
* Re: Bug in libm or libstdc++. [not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br > @ 1999-03-02 7:58 ` Paul Derbyshire 1999-03-02 23:08 ` Alexandre Oliva 1999-03-31 23:46 ` Paul Derbyshire 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-03-02 7:58 UTC (permalink / raw) To: egcs At 05:16 AM 3/1/99 -0300, you wrote: >> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as >> I've mentioned a few times before. > >It is outdated anyway. No it is not. It's the most recent version around, so it isn't possible for it to be outdated, especially since if it were, this would be completely unacceptable, as it would imply that there is no up-to-date reference, and that of course just can't have been allowed. >...egcs targets the ANSI C++ Standard, not the ARM. What is "the ARM"? (Note: Search engine results: 725,480 hits, of which none on the first page are relevant. Search engines are simply not usable for finding this stuff out! Unless you honestly expect me to read through 72,548 pages and 725,480 URLs and descriptions before asking any questions, which would be ludicruous.) In any case, quit accusing me of ignorance of the C++ essentials and quit accusing, of all people, Bjarne Stroustrup of same. BTW, this is veering rapidly off-topic due to you. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-03-02 7:58 ` Paul Derbyshire @ 1999-03-02 23:08 ` Alexandre Oliva 1999-03-31 23:46 ` Alexandre Oliva 1999-03-31 23:46 ` Paul Derbyshire 1 sibling, 1 reply; 268+ messages in thread From: Alexandre Oliva @ 1999-03-02 23:08 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 424 bytes --] On Mar 2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote: >> ...egcs targets the ANSI C++ Standard, not the ARM. > What is "the ARM"? The ARM is Stroustrup's book. It is not the ANSI/ISO C++ Standard. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-03-02 23:08 ` Alexandre Oliva @ 1999-03-31 23:46 ` Alexandre Oliva 0 siblings, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 425 bytes --] On Mar 2, 1999, Paul Derbyshire <pderbysh@usa.net> wrote: >> ...egcs targets the ANSI C++ Standard, not the ARM. > What is "the ARM"? The ARM is Stroustrup's book. It is not the ANSI/ISO C++ Standard. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-03-02 7:58 ` Paul Derbyshire 1999-03-02 23:08 ` Alexandre Oliva @ 1999-03-31 23:46 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-03-31 23:46 UTC (permalink / raw) To: egcs At 05:16 AM 3/1/99 -0300, you wrote: >> 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as >> I've mentioned a few times before. > >It is outdated anyway. No it is not. It's the most recent version around, so it isn't possible for it to be outdated, especially since if it were, this would be completely unacceptable, as it would imply that there is no up-to-date reference, and that of course just can't have been allowed. >...egcs targets the ANSI C++ Standard, not the ARM. What is "the ARM"? (Note: Search engine results: 725,480 hits, of which none on the first page are relevant. Search engines are simply not usable for finding this stuff out! Unless you honestly expect me to read through 72,548 pages and 725,480 URLs and descriptions before asking any questions, which would be ludicruous.) In any case, quit accusing me of ignorance of the C++ essentials and quit accusing, of all people, Bjarne Stroustrup of same. BTW, this is veering rapidly off-topic due to you. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-03-01 0:19 ` Alexandre Oliva [not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br > @ 1999-03-31 23:46 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-03-31 23:46 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 590 bytes --] On Feb 28, 1999, Paul Derbyshire <pderbysh@usa.net> wrote: > At 06:40 PM 2/27/99 +0100, you wrote: >> Get a newer one, or better yet, get a clue. > 1. I have THE 3RD EDITION, in other words THE MOST RECENT VERSION, as > I've mentioned a few times before. It is outdated anyway. It is not the ANSI C++ Standard, and egcs targets the ANSI C++ Standard, not the ARM. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-27 9:40 ` Marc Espie [not found] ` < 199902271740.SAA14323@quatramaran.ens.fr > @ 1999-02-28 22:53 ` Marc Espie 1 sibling, 0 replies; 268+ messages in thread From: Marc Espie @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs In article < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > you write: >At 10:36 AM 2/26/99 PST, you wrote: >>Limited resources. Up to now most resources have been concentrated on >>completing the compiler portion of the standard, and we are very close. >>The only significant unimplemented feature is "export". >My copy of Stroustrup makes no mention of "export", IIRC. Get a newer one, or better yet, get a clue. I have the chance to read the egcs-ml thru an email to local news gateway. You know what ? You're the first individual to make my kill-file on this list. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-26 22:21 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > @ 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 10:36 AM 2/26/99 PST, you wrote: >Limited resources. Up to now most resources have been concentrated on >completing the compiler portion of the standard, and we are very close. >The only significant unimplemented feature is "export". My copy of Stroustrup makes no mention of "export", IIRC. >If you would like to volunteer to assemble such a list... Ack! Well, for starters: * <valarray> to be implemented * <limits> to be implemented * "void (*foo) (void) throw ();" causes a spurious error * IIRC stringstreams and <sstream> were incomplete/missing Anyone else who'se noticed an omission/incomplete thing/bug in C++ support that isn't platform-dependent is welcome to add to the list. >As for ETAs, in the free software world the only answer you will get is >"when it's ready". Or "when you do it yourself" right? <g> I may be able to cobble together a draft of a working <valarray>. If I come up with one amidst all the other work I'm doing on my own stuff, I'll be sure to offer it here. >See http://sourceware.cygnus.com/libstdc++/ OK -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-26 10:38 ` Joe Buck [not found] ` < 199902261836.KAA17757@atrus.synopsys.com > @ 1999-02-28 22:53 ` Joe Buck 1 sibling, 0 replies; 268+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs > At 03:32 PM 2/24/99 PST, you wrote: > >You have already been informed that libstdc++ is not complete. Sorry. > > The standard has been around in largely complete form for over a year, and > finalized for many months. I am curious as to what is the cause for all of > these omissions... Limited resources. Up to now most resources have been concentrated on completing the compiler portion of the standard, and we are very close. The only significant unimplemented feature is "export". > In any case, to avoid any more unpleasant surprised I would like to see a > list of all the omissions in the current libstdc++ and other > non-conformances, and where possible ETAs for the missing components. If you would like to volunteer to assemble such a list, and do most of the research yourself, you might find that others are willing to help. If you continue to demand that others do work, you will probably just create more hostility. As for ETAs, in the free software world the only answer you will get is "when it's ready". > It > would be a good idea to post a periodic libstdc++ progress report and calls > for volunteers to implement some of the stuff. I think that might attract > more developers to fixing up and finishing implementing the standard C++ > library. See http://sourceware.cygnus.com/libstdc++/ > An area where I may be able to help is with the standard valarray and its > friends, once I get back a response regarding making the compiler eliminate > temporaries and excess copies in argument passing and return. Again, see above. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-25 22:25 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net > @ 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 03:32 PM 2/24/99 PST, you wrote: >You have already been informed that libstdc++ is not complete. Sorry. The standard has been around in largely complete form for over a year, and finalized for many months. I am curious as to what is the cause for all of these omissions... I would love to help but I don't know the first thing about implementing these mathematical functions. In any case, to avoid any more unpleasant surprised I would like to see a list of all the omissions in the current libstdc++ and other non-conformances, and where possible ETAs for the missing components. It would be a good idea to post a periodic libstdc++ progress report and calls for volunteers to implement some of the stuff. I think that might attract more developers to fixing up and finishing implementing the standard C++ library. An area where I may be able to help is with the standard valarray and its friends, once I get back a response regarding making the compiler eliminate temporaries and excess copies in argument passing and return. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-24 15:34 ` Joe Buck [not found] ` < 199902242332.PAA09334@atrus.synopsys.com > @ 1999-02-28 22:53 ` Joe Buck 1 sibling, 0 replies; 268+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs, egcs-bugs [ no "long double" overloads of math functions ] > Stroustrup 3rd Ed definitely informs me that long double overloads for > these and other functions are supposed to be in either libm or libstdc++. You have already been informed that libstdc++ is not complete. Sorry. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. [not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net > 1999-02-24 15:34 ` Joe Buck @ 1999-02-24 15:42 ` Bob McWhirter [not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org > 1999-02-28 22:53 ` Bob McWhirter 1 sibling, 2 replies; 268+ messages in thread From: Bob McWhirter @ 1999-02-24 15:42 UTC (permalink / raw) To: egcs On Mon, 22 Feb 1999, Paul Derbyshire wrote: > C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx > c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to > `atan(long double)' [ snip ] > What the hell? Is that -really- necessary? Pipe down, already. > Stroustrup 3rd Ed definitely informs me that long double overloads for > these and other functions are supposed to be in either libm or libstdc++. Uhhh... if you're referring to page 660 (section 22.3) it most certainly does not make any such guarantee with regards to -long double- datatypes. > Using egcs 1.1.1 and the libm and libstdc++ that came with it. at least on my box (sparc solaris), libm is vendor provided. gnu/include/g++/cmath -does- make reference to the math functions that use long doubles for arguments, but I don't think any library on my box actually supports them. Possibly there for platforms that do? There for platforms that typedef a long double to be the same as a double? (nm'ing vendor's libm and stdc++ does not reveal math functions taking long doubles, but possibly some other lib I'm ignoring? I did find math functions take complex objects as arguments though.) -Bob ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org >]
* Re: Bug in libm or libstdc++. [not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org > @ 1999-02-25 22:20 ` Paul Derbyshire [not found] ` <199902261635.LAA23787@wagner.Princeton.EDU> ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-25 22:20 UTC (permalink / raw) To: egcs, djgpp > Uhhh... if you're referring to page 660 (section 22.3) > it most certainly does not make any such guarantee with > regards to -long double- datatypes. S22.3, page 661: "double atan (double) ..... In addition, <cmath> and <math.h> supply these functions for float and long double arguments." You're wrong, I'm right. Long double versions of atan and friends ARE demanded by the standard. I would like to see them very soon so that I may use them (the long double versions anyways) when I want that bit of extra precision....... > at least on my box (sparc solaris), libm is vendor provided. Not on an IBM PC clone, where it comes with the DJGPP/Cygwin/whatever development environment you install. I installed the DJGPP/EGCS development environment and got a broken libm. > gnu/include/g++/cmath -does- make reference to the math > functions that use long doubles for arguments, but I don't > think any library on my box actually supports them. Then those libraries are broken and not conformant. I suggest you complain to the vendor. You may also want to ask the bookstore where you got your copy of Stroustrup for an exchange or a refund; I sure would have if my copy had turned out to have pp. 661-662 torn out or missing. Anyways, since these are function overloads in C++, I would expect the long double and float versions to be in libstdc++, not libm. And libstdc++ comes with gcc/egcs rather than being vendor supplied, on all platforms. If the egcs libstdc++ is lacking long double overloads for atan and the like, then this is a bug in egcs. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <199902261635.LAA23787@wagner.Princeton.EDU>]
* Re: Bug in libm or libstdc++. [not found] ` <199902261635.LAA23787@wagner.Princeton.EDU> @ 1999-02-27 19:08 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 8:30 ` Joern Rennecke 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-27 19:08 UTC (permalink / raw) To: egcs At 11:35 AM 2/26/99 -0500, you wrote: [Long double overloads of libm functions in libstdc++] >Then ... implement them. I may be mathematically inclined but I have none of the numerical-computation background necessary to know how to implement these things in an optimized way. Best I could probably do is a slowly converging Taylor series for these things. You ened a volunteer with a bit more knowledge in techniques of rapid numerical computation of trig functions. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-27 19:08 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 8:30 ` Joern Rennecke 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 11:35 AM 2/26/99 -0500, you wrote: [Long double overloads of libm functions in libstdc++] >Then ... implement them. I may be mathematically inclined but I have none of the numerical-computation background necessary to know how to implement these things in an optimized way. Best I could probably do is a slowly converging Taylor series for these things. You ened a volunteer with a bit more knowledge in techniques of rapid numerical computation of trig functions. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-27 19:08 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire @ 1999-03-01 8:30 ` Joern Rennecke [not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk > 1999-03-31 23:46 ` Joern Rennecke 1 sibling, 2 replies; 268+ messages in thread From: Joern Rennecke @ 1999-03-01 8:30 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs > I may be mathematically inclined but I have none of the > numerical-computation background necessary to know how to implement these > things in an optimized way. Best I could probably do is a slowly converging > Taylor series for these things. You ened a volunteer with a bit more > knowledge in techniques of rapid numerical computation of trig functions. When you want to use a Polynom approximation, you should rather use a Tschebyscheff polynom. Look it up in a mathematical enceclopedia. If you just want to get something working, you can skip the proofs and go straight for the recipes ;-) I happen to have written sqrt functions when I worked on an XFmode / TFmode fp-bit.c . ( The project got stuck for lack of priority. ) I'll send it to you in private email. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 199903011630.QAA00110@phal.cygnus.co.uk >]
* Re: Bug in libm or libstdc++. [not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk > @ 1999-03-02 8:04 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net > 1999-03-31 23:46 ` Paul Derbyshire 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-03-02 8:04 UTC (permalink / raw) To: egcs At 04:30 PM 3/1/99 +0000, you wrote: >When you want to use a Polynom approximation, you should rather use a >Tschebyscheff polynom. Perhaps. >Look it up in a mathematical enceclopedia. Impossible, since I don't have the URL for any, and a Web search turned up dry. (Again.) Of course, printed, expensive ones are not a viable alternative, since I have insufficient funds, no access to any vendor of such a product, and moreover no information about how I would locate such a vendor given that I did have the access and the three-figure amount of spare cash. Also, egcs is a free software product run on an open development model, and so it is not possible for them to require/expect a contributor to obtain expensive items in order to contribute, without thereby violating their own charter. >If you just want to get something working, you can skip the proofs and go >straight for the recipes ;-) Of course. >I happen to have written sqrt functions when I worked on an XFmode / >TFmode fp-bit.c . ( The project got stuck for lack of priority. ) >I'll send it to you in private email. A sqrt can be implemented quickly with Newton's method, converging in O(log_2 # binary digits in mantissa) starting from a suitable guess. This is O(log n)... I doubt it can be bettered. It's the trig, exponentials, and especially the logarithms that are the nontrivial ones. :-) -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 3.0.6.32.19990302110405.00945870@pop.globalserve.net >]
* Re: Bug in libm or libstdc++. [not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net > @ 1999-03-02 8:38 ` Joern Rennecke 1999-03-31 23:46 ` Joern Rennecke 0 siblings, 1 reply; 268+ messages in thread From: Joern Rennecke @ 1999-03-02 8:38 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs > Impossible, since I don't have the URL for any, and a Web search turned up > dry. (Again.) > Of course, printed, expensive ones are not a viable alternative, since I > have insufficient funds, no access to any vendor of such a product, and > moreover no information about how I would locate such a vendor given that I > did have the access and the three-figure amount of spare cash. Also, egcs > is a free software product run on an open development model, and so it is > not possible for them to require/expect a contributor to obtain expensive > items in order to contribute, without thereby violating their own charter. Oh, I bought one for a sum that, expresed in US dollars, would be one-figure. But never mind, you can go to one of these old-fashioned places called 'public libraries' or 'university libraries'. > A sqrt can be implemented quickly with Newton's method, converging in > O(log_2 # binary digits in mantissa) starting from a suitable guess. This > is O(log n)... I doubt it can be bettered. You have to keep in mind that multiplication itself is O(n^1.6). Moreover, XFmode and TFmode can be expressed in a small number of 32 / 64 bit values, so you have a lot of discretization noise in the actual precision - runtime function. And sqrt is supposed to be rounded EXACTLY for IEEE, i.e. for round to nearest, you should return that floating point value that most accurately describes the actual square root. > It's the trig, exponentials, and especially the logarithms that are the > nontrivial ones. :-) For these functions, the rounding requirements ar a lot more relaxed. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-03-02 8:38 ` Joern Rennecke @ 1999-03-31 23:46 ` Joern Rennecke 0 siblings, 0 replies; 268+ messages in thread From: Joern Rennecke @ 1999-03-31 23:46 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs > Impossible, since I don't have the URL for any, and a Web search turned up > dry. (Again.) > Of course, printed, expensive ones are not a viable alternative, since I > have insufficient funds, no access to any vendor of such a product, and > moreover no information about how I would locate such a vendor given that I > did have the access and the three-figure amount of spare cash. Also, egcs > is a free software product run on an open development model, and so it is > not possible for them to require/expect a contributor to obtain expensive > items in order to contribute, without thereby violating their own charter. Oh, I bought one for a sum that, expresed in US dollars, would be one-figure. But never mind, you can go to one of these old-fashioned places called 'public libraries' or 'university libraries'. > A sqrt can be implemented quickly with Newton's method, converging in > O(log_2 # binary digits in mantissa) starting from a suitable guess. This > is O(log n)... I doubt it can be bettered. You have to keep in mind that multiplication itself is O(n^1.6). Moreover, XFmode and TFmode can be expressed in a small number of 32 / 64 bit values, so you have a lot of discretization noise in the actual precision - runtime function. And sqrt is supposed to be rounded EXACTLY for IEEE, i.e. for round to nearest, you should return that floating point value that most accurately describes the actual square root. > It's the trig, exponentials, and especially the logarithms that are the > nontrivial ones. :-) For these functions, the rounding requirements ar a lot more relaxed. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-03-02 8:04 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net > @ 1999-03-31 23:46 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-03-31 23:46 UTC (permalink / raw) To: egcs At 04:30 PM 3/1/99 +0000, you wrote: >When you want to use a Polynom approximation, you should rather use a >Tschebyscheff polynom. Perhaps. >Look it up in a mathematical enceclopedia. Impossible, since I don't have the URL for any, and a Web search turned up dry. (Again.) Of course, printed, expensive ones are not a viable alternative, since I have insufficient funds, no access to any vendor of such a product, and moreover no information about how I would locate such a vendor given that I did have the access and the three-figure amount of spare cash. Also, egcs is a free software product run on an open development model, and so it is not possible for them to require/expect a contributor to obtain expensive items in order to contribute, without thereby violating their own charter. >If you just want to get something working, you can skip the proofs and go >straight for the recipes ;-) Of course. >I happen to have written sqrt functions when I worked on an XFmode / >TFmode fp-bit.c . ( The project got stuck for lack of priority. ) >I'll send it to you in private email. A sqrt can be implemented quickly with Newton's method, converging in O(log_2 # binary digits in mantissa) starting from a suitable guess. This is O(log n)... I doubt it can be bettered. It's the trig, exponentials, and especially the logarithms that are the nontrivial ones. :-) -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-03-01 8:30 ` Joern Rennecke [not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk > @ 1999-03-31 23:46 ` Joern Rennecke 1 sibling, 0 replies; 268+ messages in thread From: Joern Rennecke @ 1999-03-31 23:46 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs > I may be mathematically inclined but I have none of the > numerical-computation background necessary to know how to implement these > things in an optimized way. Best I could probably do is a slowly converging > Taylor series for these things. You ened a volunteer with a bit more > knowledge in techniques of rapid numerical computation of trig functions. When you want to use a Polynom approximation, you should rather use a Tschebyscheff polynom. Look it up in a mathematical enceclopedia. If you just want to get something working, you can skip the proofs and go straight for the recipes ;-) I happen to have written sqrt functions when I worked on an XFmode / TFmode fp-bit.c . ( The project got stuck for lack of priority. ) I'll send it to you in private email. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <Pine.SUN.3.91.990228142826.5950V-100000@is>]
* Re: Bug in libm or libstdc++. [not found] ` <Pine.SUN.3.91.990228142826.5950V-100000@is> @ 1999-02-28 4:57 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 4:57 UTC (permalink / raw) To: egcs, djgpp At 02:28 PM 2/28/99 +0200, you wrote: > >On Fri, 26 Feb 1999, Paul Derbyshire wrote: > >> You're wrong, I'm right. Long double versions of atan and friends ARE >> demanded by the standard. >Which standard is that? The ISO C++ standard. The C++ compiling environment is what was under discussion. >libm.a which comes with DJGPP v2.02 is not a C++ >library, it's a C library, and AFAIK it conforms to current C >standards. Then it must be libstdc++ that is supposed to overload those functions for floats and long doubles. As the subject says, the bug was in one of those libraries, and your clarification has narrowed it down to libstdc++. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-28 4:57 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs, djgpp At 02:28 PM 2/28/99 +0200, you wrote: > >On Fri, 26 Feb 1999, Paul Derbyshire wrote: > >> You're wrong, I'm right. Long double versions of atan and friends ARE >> demanded by the standard. >Which standard is that? The ISO C++ standard. The C++ compiling environment is what was under discussion. >libm.a which comes with DJGPP v2.02 is not a C++ >library, it's a C library, and AFAIK it conforms to current C >standards. Then it must be libstdc++ that is supposed to overload those functions for floats and long doubles. As the subject says, the bug was in one of those libraries, and your clarification has narrowed it down to libstdc++. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-25 22:20 ` Paul Derbyshire [not found] ` <199902261635.LAA23787@wagner.Princeton.EDU> [not found] ` <Pine.SUN.3.91.990228142826.5950V-100000@is> @ 1999-02-28 22:53 ` Paul Derbyshire 2 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs, djgpp > Uhhh... if you're referring to page 660 (section 22.3) > it most certainly does not make any such guarantee with > regards to -long double- datatypes. S22.3, page 661: "double atan (double) ..... In addition, <cmath> and <math.h> supply these functions for float and long double arguments." You're wrong, I'm right. Long double versions of atan and friends ARE demanded by the standard. I would like to see them very soon so that I may use them (the long double versions anyways) when I want that bit of extra precision....... > at least on my box (sparc solaris), libm is vendor provided. Not on an IBM PC clone, where it comes with the DJGPP/Cygwin/whatever development environment you install. I installed the DJGPP/EGCS development environment and got a broken libm. > gnu/include/g++/cmath -does- make reference to the math > functions that use long doubles for arguments, but I don't > think any library on my box actually supports them. Then those libraries are broken and not conformant. I suggest you complain to the vendor. You may also want to ask the bookstore where you got your copy of Stroustrup for an exchange or a refund; I sure would have if my copy had turned out to have pp. 661-662 torn out or missing. Anyways, since these are function overloads in C++, I would expect the long double and float versions to be in libstdc++, not libm. And libstdc++ comes with gcc/egcs rather than being vendor supplied, on all platforms. If the egcs libstdc++ is lacking long double overloads for atan and the like, then this is a bug in egcs. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: Bug in libm or libstdc++. 1999-02-24 15:42 ` Bob McWhirter [not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org > @ 1999-02-28 22:53 ` Bob McWhirter 1 sibling, 0 replies; 268+ messages in thread From: Bob McWhirter @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs On Mon, 22 Feb 1999, Paul Derbyshire wrote: > C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx > c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to > `atan(long double)' [ snip ] > What the hell? Is that -really- necessary? Pipe down, already. > Stroustrup 3rd Ed definitely informs me that long double overloads for > these and other functions are supposed to be in either libm or libstdc++. Uhhh... if you're referring to page 660 (section 22.3) it most certainly does not make any such guarantee with regards to -long double- datatypes. > Using egcs 1.1.1 and the libm and libstdc++ that came with it. at least on my box (sparc solaris), libm is vendor provided. gnu/include/g++/cmath -does- make reference to the math functions that use long doubles for arguments, but I don't think any library on my box actually supports them. Possibly there for platforms that do? There for platforms that typedef a long double to be the same as a double? (nm'ing vendor's libm and stdc++ does not reveal math functions taking long doubles, but possibly some other lib I'm ignoring? I did find math functions take complex objects as arguments though.) -Bob ^ permalink raw reply [flat|nested] 268+ messages in thread
* Bug in libm or libstdc++. 1999-02-24 15:13 Bug in libm or libstdc++ Paul Derbyshire [not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net > @ 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs, egcs-bugs C:\PGD\C++\omega\ofc>gcc ntst.cc -o ntst.exe -Wall -lm -lstdcxx c:/djgpp/tmp/cc5PNfut.o(.text+0x51):ntst.cc: undefined reference to `atan(long double)' c:/djgpp/tmp/cc5PNfut.o(.text+0xa8):ntst.cc: undefined reference to `exp(long double)' c:/djgpp/tmp/cc5PNfut.o(.text+0xef):ntst.cc: undefined reference to `log(long double)' c:/djgpp/tmp/cc5PNfut.o(.text+0x136):ntst.cc: undefined reference to `log(long double)' c:/djgpp/tmp/cc5PNfut.o(.text+0x17d):ntst.cc: undefined reference to `sqrt(long double)' What the hell? Stroustrup 3rd Ed definitely informs me that long double overloads for these and other functions are supposed to be in either libm or libstdc++. Using egcs 1.1.1 and the libm and libstdc++ that came with it. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* [Meta] Enough of the "egcs.cygnus.com" already! @ 1999-01-31 22:09 Paul Derbyshire 1999-01-31 22:14 ` CaT ` (4 more replies) 0 siblings, 5 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-01-31 22:09 UTC (permalink / raw) To: egcs Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail filter to filter anything with a To: or Cc: containing "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely that anyone would BCc: to the list and confound the filter. Trouble is, it seems you can post to the list using just "egcs@cygnus.com", since I keep finding a shitload of egcs mail in my main Inbox with this on the Cc: line! Argh. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire @ 1999-01-31 22:14 ` CaT 1999-01-31 22:24 ` Bob McWhirter 1999-01-31 23:12 ` Ken Raeburn ` (3 subsequent siblings) 4 siblings, 1 reply; 268+ messages in thread From: CaT @ 1999-01-31 22:14 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs Paul Derbyshire wrote the following: > > Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail > filter to filter anything with a To: or Cc: containing > "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely > that anyone would BCc: to the list and confound the filter. > > Trouble is, it seems you can post to the list using just "egcs@cygnus.com", > since I keep finding a shitload of egcs mail in my main Inbox with this on > the Cc: line! I filter on the From_ line like this: /^From (egcs(-|-testresults-|-announce-)return-[0-9]+-cat\=zip\.com\.au\@egcs\.cygnus\.com|owner-egcs-bugs\@cygnus\.com)/ That catches all the egcs mail for me just fine (it's from a list perl script I've written to postprocess my mailbox. don't ask why. :). -- CaT (cat@zip.net.au) URL: http://www.zip.com.au/dev/null There was farting in the air that night, It lit so bright, Fernando... ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-01-31 22:14 ` CaT @ 1999-01-31 22:24 ` Bob McWhirter 1999-01-31 22:50 ` Paul Derbyshire 0 siblings, 1 reply; 268+ messages in thread From: Bob McWhirter @ 1999-01-31 22:24 UTC (permalink / raw) To: CaT; +Cc: Paul Derbyshire, egcs > > Trouble is, it seems you can post to the list using just "egcs@cygnus.com", > > since I keep finding a shitload of egcs mail in my main Inbox with this on > > the Cc: line! > > I filter on the From_ line like this: > > /^From (egcs(-|-testresults-|-announce-)return-[0-9]+-cat\=zip\.com\.au\@egcs\.cygnus\.com|owner-egcs-bugs\@cygnus\.com)/ Pardon the 'me too!', but I've found this regexp (from .procmailrc) to work rather well: ^Sender:.*owner-egcs It's short, and seems to work regardless of the address used to send to the list itself. -Bob ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-01-31 22:24 ` Bob McWhirter @ 1999-01-31 22:50 ` Paul Derbyshire 1999-02-01 2:01 ` Franz Sirl 0 siblings, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-01-31 22:50 UTC (permalink / raw) To: egcs >Pardon the 'me too!', but I've found this regexp (from .procmailrc) >to work rather well: > > ^Sender:.*owner-egcs Mine doesn't come with a Sender: header...there's an X-Sender: header but it's the message originator again and not owner-egcs. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-01-31 22:50 ` Paul Derbyshire @ 1999-02-01 2:01 ` Franz Sirl [not found] ` < 4.1.19990201105045.054320e0@mail.lauterbach.com > 1999-02-28 22:53 ` Franz Sirl 0 siblings, 2 replies; 268+ messages in thread From: Franz Sirl @ 1999-02-01 2:01 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs At 07:50 01.02.99 , Paul Derbyshire wrote: >>Pardon the 'me too!', but I've found this regexp (from .procmailrc) >>to work rather well: >> >> ^Sender:.*owner-egcs > >Mine doesn't come with a Sender: header...there's an X-Sender: header but >it's the message originator again and not owner-egcs. Sure it has a Sender: header. Just enable the "BlahBlah" button of the message in Eudora and you will see it. So you can either filter on: "Sender:" contains "owner-egcs" or "Delivered-To:" contains "egcs@egcs.cygnus.com" in Eudora. You'll see that neither one one of these headers is preconfigured in Eudora's header popup list, but you can simply overtype one of the preconfigured headers. Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 4.1.19990201105045.054320e0@mail.lauterbach.com >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` < 4.1.19990201105045.054320e0@mail.lauterbach.com > @ 1999-02-01 15:53 ` Paul Derbyshire 1999-02-28 22:53 ` Rask Ingemann Lambertsen 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 2 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-01 15:53 UTC (permalink / raw) To: egcs At 11:00 AM 2/1/99 +0100, you wrote: >Sure it has a Sender: header. Just enable the "BlahBlah" button of the >message in Eudora and you will see it. I know about that button, dammit, and trust me it's not there. Neither is the "From " header. I looked for both of those in the very message I'm replying to, and saw neither. Tehre was an X-Sender: but there was no mention of owner-egcs in it. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 15:53 ` Paul Derbyshire @ 1999-02-28 22:53 ` Rask Ingemann Lambertsen 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Rask Ingemann Lambertsen @ 1999-02-28 22:53 UTC (permalink / raw) To: EGCS mailing list [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1377 bytes --] Den 02-Feb-99 00:52:33 skrev Paul Derbyshire følgende om "Re: [Meta] Enough of the "egcs.cygnus.com" already!": > At 11:00 AM 2/1/99 +0100, you wrote: >>Sure it has a Sender: header. Just enable the "BlahBlah" button of the >>message in Eudora and you will see it. > I know about that button, dammit, and trust me it's not there. Neither is > the "From " header. I looked for both of those in the very message I'm > replying to, and saw neither. Tehre was an X-Sender: but there was no > mention of owner-egcs in it. IIRC, RFC1123 requires Internet mail systems to preserve the envelope sender address. This is what the "From " header is normally used for. Perhaps there is a Return-Path: header instead? Btw, my copies of the messages all have the Sender: header. Regards, /¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | |To err is human. To forgive is beyond the scope of the Operating System.| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 15:53 ` Paul Derbyshire 1999-02-28 22:53 ` Rask Ingemann Lambertsen @ 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 11:00 AM 2/1/99 +0100, you wrote: >Sure it has a Sender: header. Just enable the "BlahBlah" button of the >message in Eudora and you will see it. I know about that button, dammit, and trust me it's not there. Neither is the "From " header. I looked for both of those in the very message I'm replying to, and saw neither. Tehre was an X-Sender: but there was no mention of owner-egcs in it. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 2:01 ` Franz Sirl [not found] ` < 4.1.19990201105045.054320e0@mail.lauterbach.com > @ 1999-02-28 22:53 ` Franz Sirl 1 sibling, 0 replies; 268+ messages in thread From: Franz Sirl @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs At 07:50 01.02.99 , Paul Derbyshire wrote: >>Pardon the 'me too!', but I've found this regexp (from .procmailrc) >>to work rather well: >> >> ^Sender:.*owner-egcs > >Mine doesn't come with a Sender: header...there's an X-Sender: header but >it's the message originator again and not owner-egcs. Sure it has a Sender: header. Just enable the "BlahBlah" button of the message in Eudora and you will see it. So you can either filter on: "Sender:" contains "owner-egcs" or "Delivered-To:" contains "egcs@egcs.cygnus.com" in Eudora. You'll see that neither one one of these headers is preconfigured in Eudora's header popup list, but you can simply overtype one of the preconfigured headers. Franz. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire 1999-01-31 22:14 ` CaT @ 1999-01-31 23:12 ` Ken Raeburn 1999-02-01 7:13 ` Jeffrey A Law ` (2 subsequent siblings) 4 siblings, 0 replies; 268+ messages in thread From: Ken Raeburn @ 1999-01-31 23:12 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs Paul Derbyshire <pderbysh@usa.net> writes: > Trouble is, it seems you can post to the list using just "egcs@cygnus.com", It's not unheard of for a site to have a local alias that points to a remote mailing list, especially if, say, a news/mail gateway is situated at that machine (so that "posts" may automatically be routed by email to that machine, where some spam filter might be installed), or the machine used to host the list before it moved (so that people may have the old address saved away somewhere, and old versions of the software may refer to it in documentation). The latter is the case here. Getting annoyed at such sites isn't going to do you much good. Find some way to match on the alternate addresses; they're usually few in number. Me, I look for something like egcs@[-a-zA-Z0-9.]*cygnus.com in the to or cc lines. (The long list of characters is to avoid matching whitespace and thus span multiple addresses.) But I see the incoming mail headers (at my site) currently also have: Mailing-List: contact egcs-help@egcs.cygnus.com; run by ezmlm Sender: owner-egcs@egcs.cygnus.com Delivered-To: mailing list egcs@egcs.cygnus.com that you could look for. And the envelope-sender address (also known as a "From " header -- that's "from" with a trailing space and *NO* colon -- in the UNIX/sendmail world) also indicates that it's from the egcs list, but I don't know if your mailer will make that info available to you. Ken ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire 1999-01-31 22:14 ` CaT 1999-01-31 23:12 ` Ken Raeburn @ 1999-02-01 7:13 ` Jeffrey A Law 1999-02-01 7:27 ` Alexandre Oliva 1999-02-28 22:53 ` Jeffrey A Law [not found] ` <19990201200631.A227@tardis.ed.ac.uk> 1999-02-03 12:05 ` Rask Ingemann Lambertsen 4 siblings, 2 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-01 7:13 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs In message <3.0.6.32.19990201010831.00880950@pop.netaddress.com>you write: > Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail > filter to filter anything with a To: or Cc: containing > "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely > that anyone would BCc: to the list and confound the filter. > > Trouble is, it seems you can post to the list using just "egcs@cygnus.com", > since I keep finding a shitload of egcs mail in my main Inbox with this on > the Cc: line! The @cygnus.com relays are scheduled to go away on or around March 1, 1999. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:13 ` Jeffrey A Law @ 1999-02-01 7:27 ` Alexandre Oliva [not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br > 1999-02-28 22:53 ` Alexandre Oliva 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 2 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-02-01 7:27 UTC (permalink / raw) To: law; +Cc: Paul Derbyshire, egcs On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote: > The @cygnus.com relays are scheduled to go away on or around March 1, 1999. What about the following error message, printed by egcs 1.1.1? bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br > @ 1999-02-01 7:30 ` Jeffrey A Law 1999-02-01 7:35 ` Alexandre Oliva ` (2 more replies) 1999-02-13 10:47 ` Jeffrey A Law 1 sibling, 3 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-01 7:30 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write: > On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote: > > > The @cygnus.com relays are scheduled to go away on or around March 1, 199 > 9. > > What about the following error message, printed by egcs 1.1.1? > > bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. Easily fixed ;-) jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:30 ` Jeffrey A Law @ 1999-02-01 7:35 ` Alexandre Oliva [not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br > 1999-02-28 22:53 ` Alexandre Oliva 1999-02-01 7:59 ` Ken Raeburn 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 2 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-02-01 7:35 UTC (permalink / raw) To: law; +Cc: Paul Derbyshire, egcs On Feb 1, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote: > In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write: >> On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote: >> > The @cygnus.com relays are scheduled to go away on or around March 1, 199 >> 9. >> What about the following error message, printed by egcs 1.1.1? >> bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. > Easily fixed ;-) No, I mean, we must keep at least egcs-bugs@cygnus.com as a valid address, otherwise people that don't know about the change won't be able to submit bug reports against egcs 1.1.1, that will probably still be floating around for a long time :-( Either the relay or an automatic reply saying ``the new e-mail address for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit your report again, sorry for the inconvenience''. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br > @ 1999-02-01 7:50 ` Jeffrey A Law [not found] ` < 3391.917883892@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 1999-02-01 15:58 ` Paul Derbyshire 1 sibling, 2 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-01 7:50 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs In message < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >you write: > No, I mean, we must keep at least egcs-bugs@cygnus.com as a valid > address, otherwise people that don't know about the change won't be > able to submit bug reports against egcs 1.1.1, that will probably > still be floating around for a long time :-( > > Either the relay or an automatic reply saying ``the new e-mail address > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit > your report again, sorry for the inconvenience''. We'll probably have an auto-reply for all the old addresses. And we'll be changing the address in that message RSN. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 3391.917883892@hurl.cygnus.com >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` < 3391.917883892@hurl.cygnus.com > @ 1999-02-01 8:23 ` Joe Buck [not found] ` < 199902011621.IAA00385@atrus.synopsys.com > ` (2 more replies) 0 siblings, 3 replies; 268+ messages in thread From: Joe Buck @ 1999-02-01 8:23 UTC (permalink / raw) To: law; +Cc: oliva, pderbysh, egcs > > Either the relay or an automatic reply saying ``the new e-mail address > > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit > > your report again, sorry for the inconvenience''. > We'll probably have an auto-reply for all the old addresses. Which won't reach the people who spam-protect their email address when mailing to large mailing lists (or just out of habit). We probably should archive the old messages at least for some transition period. ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: < 199902011621.IAA00385@atrus.synopsys.com >]
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` < 199902011621.IAA00385@atrus.synopsys.com > @ 1999-02-01 8:24 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-01 16:03 ` Paul Derbyshire 1 sibling, 1 reply; 268+ messages in thread From: Jeffrey A Law @ 1999-02-01 8:24 UTC (permalink / raw) To: Joe Buck; +Cc: oliva, pderbysh, egcs In message < 199902011621.IAA00385@atrus.synopsys.com >you write: > > > > Either the relay or an automatic reply saying ``the new e-mail addres > s > > > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit > > > your report again, sorry for the inconvenience''. > > We'll probably have an auto-reply for all the old addresses. > > Which won't reach the people who spam-protect their email address > when mailing to large mailing lists (or just out of habit). Yea, but we don't care about them. I'll mean someone (sysadmin) will get a lost of bounced messages, but that's someone else's problem :-) > We probably should archive the old messages at least for some transition > period. We'll continue to have all the messages in archive form. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 8:24 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Joe Buck; +Cc: oliva, pderbysh, egcs In message < 199902011621.IAA00385@atrus.synopsys.com >you write: > > > > Either the relay or an automatic reply saying ``the new e-mail addres > s > > > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit > > > your report again, sorry for the inconvenience''. > > We'll probably have an auto-reply for all the old addresses. > > Which won't reach the people who spam-protect their email address > when mailing to large mailing lists (or just out of habit). Yea, but we don't care about them. I'll mean someone (sysadmin) will get a lost of bounced messages, but that's someone else's problem :-) > We probably should archive the old messages at least for some transition > period. We'll continue to have all the messages in archive form. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` < 199902011621.IAA00385@atrus.synopsys.com > 1999-02-01 8:24 ` Jeffrey A Law @ 1999-02-01 16:03 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-01 16:03 UTC (permalink / raw) To: egcs >Which won't reach the people who spam-protect their email address >when mailing to large mailing lists (or just out of habit). If you munge your reply-to when sending to mailing lists you deserve what you get -- or fail to get. Any decent mailing list will kick off anyone who posts spam to the list or is suspected of harvesting on it. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 16:03 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >Which won't reach the people who spam-protect their email address >when mailing to large mailing lists (or just out of habit). If you munge your reply-to when sending to mailing lists you deserve what you get -- or fail to get. Any decent mailing list will kick off anyone who posts spam to the list or is suspected of harvesting on it. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 8:23 ` Joe Buck [not found] ` < 199902011621.IAA00385@atrus.synopsys.com > @ 1999-02-28 22:53 ` Joe Buck 1999-02-28 22:53 ` postmaster 2 siblings, 0 replies; 268+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: oliva, pderbysh, egcs > > Either the relay or an automatic reply saying ``the new e-mail address > > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit > > your report again, sorry for the inconvenience''. > We'll probably have an auto-reply for all the old addresses. Which won't reach the people who spam-protect their email address when mailing to large mailing lists (or just out of habit). We probably should archive the old messages at least for some transition period. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 8:23 ` Joe Buck [not found] ` < 199902011621.IAA00385@atrus.synopsys.com > 1999-02-28 22:53 ` Joe Buck @ 1999-02-28 22:53 ` postmaster 2 siblings, 0 replies; 268+ messages in thread From: postmaster @ 1999-02-28 22:53 UTC (permalink / raw) To: EGCS mailing list [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 943 bytes --] Den 01-Feb-99 17:21:45 skrev Joe Buck følgende om "Re: [Meta] Enough of the "egcs.cygnus.com" already!": >> We'll probably have an auto-reply for all the old addresses. > Which won't reach the people who spam-protect their email address > when mailing to large mailing lists (or just out of habit). It will if they do it properly. ;-) Regards, /¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\ | Rask Ingemann Lambertsen | postmaster@rask.nospam.kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | Do artificial plants need artificial water? | ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:50 ` Jeffrey A Law [not found] ` < 3391.917883892@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs In message < or1zkab0ou.fsf@araguaia.dcc.unicamp.br >you write: > No, I mean, we must keep at least egcs-bugs@cygnus.com as a valid > address, otherwise people that don't know about the change won't be > able to submit bug reports against egcs 1.1.1, that will probably > still be floating around for a long time :-( > > Either the relay or an automatic reply saying ``the new e-mail address > for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit > your report again, sorry for the inconvenience''. We'll probably have an auto-reply for all the old addresses. And we'll be changing the address in that message RSN. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br > 1999-02-01 7:50 ` Jeffrey A Law @ 1999-02-01 15:58 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1 sibling, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-01 15:58 UTC (permalink / raw) To: egcs At 01:31 PM 2/1/99 -0200, you wrote: >Either the relay or an automatic reply saying ``the new e-mail address >for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit >your report again, sorry for the inconvenience''. MAKE THAT THING QUOTE BACK THE ORIGINAL MESSAGE!! I've seen a few systems where outgoing mail is either not automatically saved or isn't even saved at all, and people using such systems will experience "please submit your report again" as meaning "Please struggle to remember all that you wrote and then rewrite it slowly and painstakingly from scratch, and at the end, remember to use the right address!". This is why mailer_daemon mail quotes back the bounced message too. Best would be to have it send the message described, quote the oiginal below it, and have a Reply-To: of egcs-bugs@egcs.com. Then all the guy has to do who sees it is 1. Note "hmm, the damned address changed." which is what you want to remind them. 2. Hit "reply". 3. Edit away the notice and prefix symbols on the requoted message. 4. Send. 5. Use the new address now. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 15:58 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs At 01:31 PM 2/1/99 -0200, you wrote: >Either the relay or an automatic reply saying ``the new e-mail address >for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit >your report again, sorry for the inconvenience''. MAKE THAT THING QUOTE BACK THE ORIGINAL MESSAGE!! I've seen a few systems where outgoing mail is either not automatically saved or isn't even saved at all, and people using such systems will experience "please submit your report again" as meaning "Please struggle to remember all that you wrote and then rewrite it slowly and painstakingly from scratch, and at the end, remember to use the right address!". This is why mailer_daemon mail quotes back the bounced message too. Best would be to have it send the message described, quote the oiginal below it, and have a Reply-To: of egcs-bugs@egcs.com. Then all the guy has to do who sees it is 1. Note "hmm, the damned address changed." which is what you want to remind them. 2. Hit "reply". 3. Edit away the notice and prefix symbols on the requoted message. 4. Send. 5. Use the new address now. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:35 ` Alexandre Oliva [not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br > @ 1999-02-28 22:53 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: Paul Derbyshire, egcs On Feb 1, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote: > In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write: >> On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote: >> > The @cygnus.com relays are scheduled to go away on or around March 1, 199 >> 9. >> What about the following error message, printed by egcs 1.1.1? >> bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. > Easily fixed ;-) No, I mean, we must keep at least egcs-bugs@cygnus.com as a valid address, otherwise people that don't know about the change won't be able to submit bug reports against egcs 1.1.1, that will probably still be floating around for a long time :-( Either the relay or an automatic reply saying ``the new e-mail address for reporting egcs bugs is egcs-bugs@egcs.cygnus.com, please submit your report again, sorry for the inconvenience''. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:30 ` Jeffrey A Law 1999-02-01 7:35 ` Alexandre Oliva @ 1999-02-01 7:59 ` Ken Raeburn 1999-02-28 22:53 ` Ken Raeburn 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 1 reply; 268+ messages in thread From: Ken Raeburn @ 1999-02-01 7:59 UTC (permalink / raw) To: law; +Cc: Alexandre Oliva, Paul Derbyshire, egcs Jeffrey A Law <law@hurl.cygnus.com> writes: > > bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. > Easily fixed ;-) Retroactively? Or do you expect people to update to a new egcs release within the next 28 days? We need *something* at that address, even if it's a vacation-like program telling people to use the new address. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:59 ` Ken Raeburn @ 1999-02-28 22:53 ` Ken Raeburn 0 siblings, 0 replies; 268+ messages in thread From: Ken Raeburn @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: Alexandre Oliva, Paul Derbyshire, egcs Jeffrey A Law <law@hurl.cygnus.com> writes: > > bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. > Easily fixed ;-) Retroactively? Or do you expect people to update to a new egcs release within the next 28 days? We need *something* at that address, even if it's a vacation-like program telling people to use the new address. ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:30 ` Jeffrey A Law 1999-02-01 7:35 ` Alexandre Oliva 1999-02-01 7:59 ` Ken Raeburn @ 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write: > On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote: > > > The @cygnus.com relays are scheduled to go away on or around March 1, 199 > 9. > > What about the following error message, printed by egcs 1.1.1? > > bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. Easily fixed ;-) jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br > 1999-02-01 7:30 ` Jeffrey A Law @ 1999-02-13 10:47 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 1 reply; 268+ messages in thread From: Jeffrey A Law @ 1999-02-13 10:47 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write: > On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote: > > > The @cygnus.com relays are scheduled to go away on or around March 1, 199 > 9. > > What about the following error message, printed by egcs 1.1.1? > > bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. An FYI -- I fixed all the addresses about a week ago :-) jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-13 10:47 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Paul Derbyshire, egcs In message < or4sp6b12f.fsf@araguaia.dcc.unicamp.br >you write: > On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote: > > > The @cygnus.com relays are scheduled to go away on or around March 1, 199 > 9. > > What about the following error message, printed by egcs 1.1.1? > > bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. An FYI -- I fixed all the addresses about a week ago :-) jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:27 ` Alexandre Oliva [not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br > @ 1999-02-28 22:53 ` Alexandre Oliva 1 sibling, 0 replies; 268+ messages in thread From: Alexandre Oliva @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: Paul Derbyshire, egcs On Feb 1, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote: > The @cygnus.com relays are scheduled to go away on or around March 1, 1999. What about the following error message, printed by egcs 1.1.1? bug.c:3: Please submit a full bug report to `egcs-bugs@cygnus.com'. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org} oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 7:13 ` Jeffrey A Law 1999-02-01 7:27 ` Alexandre Oliva @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 268+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Paul Derbyshire; +Cc: egcs In message <3.0.6.32.19990201010831.00880950@pop.netaddress.com>you write: > Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail > filter to filter anything with a To: or Cc: containing > "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely > that anyone would BCc: to the list and confound the filter. > > Trouble is, it seems you can post to the list using just "egcs@cygnus.com", > since I keep finding a shitload of egcs mail in my main Inbox with this on > the Cc: line! The @cygnus.com relays are scheduled to go away on or around March 1, 1999. jeff ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <19990201200631.A227@tardis.ed.ac.uk>]
* Re: [Meta] Enough of the "egcs.cygnus.com" already! [not found] ` <19990201200631.A227@tardis.ed.ac.uk> @ 1999-02-01 15:31 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 1 reply; 268+ messages in thread From: Paul Derbyshire @ 1999-02-01 15:31 UTC (permalink / raw) To: Mark Brown; +Cc: egcs At 08:06 PM 2/1/99 +0000, you wrote: > Sender: owner-egcs@egcs.cygnus.com > >which is guarenteed to be in any message sent through this list. I don't get any Sender: headers in my incoming egcs mail, interestingly enough. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-01 15:31 ` Paul Derbyshire @ 1999-02-28 22:53 ` Paul Derbyshire 0 siblings, 0 replies; 268+ messages in thread From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw) To: Mark Brown; +Cc: egcs At 08:06 PM 2/1/99 +0000, you wrote: > Sender: owner-egcs@egcs.cygnus.com > >which is guarenteed to be in any message sent through this list. I don't get any Sender: headers in my incoming egcs mail, interestingly enough. -- .*. "Clouds are not spheres, mountains are not cones, coastlines are not -() < circles, and bark is not smooth, nor does lightning travel in a `*' straight line." ------------------------------------------------- -- B. Mandelbrot | http://surf.to/pgd.net _____________________ ____|________ Paul Derbyshire pderbysh@usa.net Programmer & Humanist|ICQ: 10423848| ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire ` (3 preceding siblings ...) [not found] ` <19990201200631.A227@tardis.ed.ac.uk> @ 1999-02-03 12:05 ` Rask Ingemann Lambertsen 1999-02-28 22:53 ` Rask Ingemann Lambertsen 4 siblings, 1 reply; 268+ messages in thread From: Rask Ingemann Lambertsen @ 1999-02-03 12:05 UTC (permalink / raw) To: EGCS mailing list [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1769 bytes --] Den 01-Feb-99 07:08:31 skrev Paul Derbyshire følgende om "[Meta] Enough of the "egcs.cygnus.com" already!": > Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail > filter to filter anything with a To: or Cc: containing > "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely > that anyone would BCc: to the list and confound the filter. Mail sorting based on To:, Cc: or Bcc: headers hasn't ever worked, doesn't work, and won't ever work. This doesn't seem to stop people from trying to do so anyway. :-( > Trouble is, it seems you can post to the list using just "egcs@cygnus.com", > since I keep finding a shitload of egcs mail in my main Inbox with this on > the Cc: line! Good example of why it hasn't ever worked, doesn't work and won't ever work. Searching for the Delivered-To: mailing list egcs@egcs.cygnus.com header does work. Always. Reliably. Since it is quite normal for list subscribers of today not to know how how do set up their mail readers, perhaps it should be mentioned somewhere that this header appears in all egcs mailing list mail, so as to at least provide the initial clue. Regards, /¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | Diplomacy is the art of saying "Nice doggie" till you can find a rock | ^ permalink raw reply [flat|nested] 268+ messages in thread
* Re: [Meta] Enough of the "egcs.cygnus.com" already! 1999-02-03 12:05 ` Rask Ingemann Lambertsen @ 1999-02-28 22:53 ` Rask Ingemann Lambertsen 0 siblings, 0 replies; 268+ messages in thread From: Rask Ingemann Lambertsen @ 1999-02-28 22:53 UTC (permalink / raw) To: EGCS mailing list [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1770 bytes --] Den 01-Feb-99 07:08:31 skrev Paul Derbyshire følgende om "[Meta] Enough of the "egcs.cygnus.com" already!": > Grr. I subscribe to the EGCS mailing list at egcs.cygnus.com and set a mail > filter to filter anything with a To: or Cc: containing > "egcs@egcs.cygnus.com" into an 'egcs' folder, figuring that it isn't likely > that anyone would BCc: to the list and confound the filter. Mail sorting based on To:, Cc: or Bcc: headers hasn't ever worked, doesn't work, and won't ever work. This doesn't seem to stop people from trying to do so anyway. :-( > Trouble is, it seems you can post to the list using just "egcs@cygnus.com", > since I keep finding a shitload of egcs mail in my main Inbox with this on > the Cc: line! Good example of why it hasn't ever worked, doesn't work and won't ever work. Searching for the Delivered-To: mailing list egcs@egcs.cygnus.com header does work. Always. Reliably. Since it is quite normal for list subscribers of today not to know how how do set up their mail readers, perhaps it should be mentioned somewhere that this header appears in all egcs mailing list mail, so as to at least provide the initial clue. Regards, /¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯T¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\ | Rask Ingemann Lambertsen | E-mail: mailto:rask@kampsax.k-net.dk | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC | | Diplomacy is the art of saying "Nice doggie" till you can find a rock | ^ permalink raw reply [flat|nested] 268+ messages in thread
[parent not found: <David>]
[parent not found: <J>]
[parent not found: <Brad>]
[parent not found: <Eli>]
[parent not found: <Paul>]
[parent not found: <Franz>]
[parent not found: <Ken>]
end of thread, other threads:[~2001-06-12 6:48 UTC | newest] Thread overview: 268+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-05-20 21:06 assemble_external on .class files Mark Klein 1999-05-22 14:23 ` Jeffrey A Law 1999-05-22 15:28 ` Mark Klein 1999-05-31 21:36 ` Mark Klein 1999-05-25 18:33 ` Mark Klein 1999-05-25 19:41 ` Jeffrey A Law 1999-05-25 21:00 ` Per Bothner 1999-05-25 21:50 ` Jeffrey A Law 1999-05-25 22:19 ` Mark Klein 1999-05-25 22:24 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-25 22:49 ` Per Bothner 1999-05-31 14:53 ` Mark Klein 1999-05-31 21:36 ` Mark Klein 1999-05-31 21:36 ` Per Bothner 1999-05-31 21:36 ` Mark Klein 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Per Bothner 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Mark Klein 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Mark Klein [not found] <Jeffrey> [not found] ` <A> [not found] ` <Law's> [not found] ` <message> [not found] ` <of> [not found] ` <"Wed,> [not found] ` <5> [not found] ` <Fri,> [not found] ` <"Thu,> [not found] ` <"Sun,> [not found] ` <19> [not found] ` <"Mon,> [not found] ` <01> [not found] ` <Mar> [not found] ` <99> [not found] ` <Feb> [not found] ` <1999> [not found] ` <02:37:52> [not found] ` <12:29:11> [not found] ` <-0500> 1999-02-01 8:23 ` A Lisp compiler? Matthew X. Economou 1999-02-01 9:29 ` Ken Raeburn 1999-02-02 15:44 ` Matthew X. Economou [not found] ` < w4ou2x4jrke.fsf@nemesis.irtnog.org > 1999-02-02 16:14 ` [Meta] " Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Matthew X. Economou 1999-02-19 23:14 ` Matthias Hölzl 1999-02-28 22:53 ` Matthias Hölzl 1999-02-28 22:53 ` Ken Raeburn 1999-02-28 22:53 ` Matthew X. Economou 1999-02-27 21:39 ` Confirmed template parsing bug: bug in error message generation Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 0:02 ` Alexandre Oliva [not found] ` < oriuclljxv.fsf@araguaia.dcc.unicamp.br > 1999-03-02 8:43 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990302114234.0086bd80@pop.globalserve.net > 1999-03-02 9:26 ` Robert Lipe 1999-03-31 23:46 ` Robert Lipe 1999-03-02 22:22 ` Alexandre Oliva 1999-03-31 23:46 ` Alexandre Oliva 1999-03-31 23:46 ` Paul Derbyshire 1999-03-31 23:46 ` Alexandre Oliva 1999-02-28 19:05 ` Possible egcs-1.1.2-pre2 configure problem on HP-UX 9.04 rodneybrown 1999-02-28 22:53 ` rodneybrown 1999-03-01 9:05 ` Alexandre Oliva [not found] ` < orogmdf8jw.fsf@araguaia.dcc.unicamp.br > 1999-03-01 9:14 ` Franz Sirl 1999-03-01 9:32 ` Alexandre Oliva 1999-03-31 23:46 ` Alexandre Oliva 1999-03-31 23:46 ` Franz Sirl 1999-03-31 23:46 ` Alexandre Oliva 1999-03-01 9:18 ` Jeffrey A Law 1999-03-31 23:46 ` Jeffrey A Law [not found] ` <(EST)> 1999-06-25 17:54 ` Occasional use of GNU ld problems Brad Lucier 1999-06-29 2:06 ` Alexandre Oliva 1999-06-29 2:20 ` Franz Sirl 1999-06-30 15:43 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva 1999-06-30 15:43 ` Brad Lucier [not found] ` <04:47:24> [not found] ` <-0800> 1999-02-12 3:00 ` C++ default copy ctor not optimal Sylvain Pion [not found] ` < 19990212120037.C13091@rigel.inria.fr > 1999-02-12 4:46 ` Sylvain Pion 1999-02-28 22:53 ` Sylvain Pion [not found] ` <19990212134607.F13091.cygnus.egcs@rigel.inria.fr> 1999-02-12 13:41 ` Jason Merrill [not found] ` <3.0.6.32.19990212172607.00844860.cygnus.egcs@pop.netaddress.com> 1999-02-12 15:27 ` Jason Merrill 1999-02-28 22:53 ` Jason Merrill [not found] ` < u9d83fl2q8.fsf@yorick.cygnus.com > 1999-02-12 14:26 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-14 10:57 ` Sylvain Pion 1999-02-14 21:01 ` Jason Merrill [not found] ` < u9iud4jm52.fsf@yorick.cygnus.com > 1999-02-15 17:15 ` Richard Henderson [not found] ` < 19990215171524.A19063@cygnus.com > 1999-02-15 20:14 ` Jeffrey A Law [not found] ` < 14555.919137968@upchuck > 1999-02-15 21:39 ` Richard Henderson [not found] ` < 19990215213927.A19254@cygnus.com > 1999-02-16 0:10 ` Sylvain Pion 1999-02-28 22:53 ` Sylvain Pion 1999-02-28 22:53 ` Richard Henderson 1999-02-28 22:53 ` Jeffrey A Law 1999-02-16 10:08 ` Joe Buck [not found] ` < 199902161807.KAA19010@atrus.synopsys.com > 1999-02-16 10:18 ` Richard Henderson [not found] ` < 19990216101811.A19900@cygnus.com > 1999-02-16 10:33 ` Sylvain Pion 1999-02-28 22:53 ` Sylvain Pion 1999-02-28 22:53 ` Richard Henderson 1999-02-28 22:53 ` Joe Buck 1999-02-28 22:53 ` Richard Henderson 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Sylvain Pion 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Sylvain Pion [not found] ` <3.0.6.32.19990212180551.00841100.cygnus.egcs@pop.netaddress.com> 1999-02-12 15:29 ` Code gen question Jason Merrill [not found] ` < u990e3kxq8.fsf@yorick.cygnus.com > 1999-02-12 17:34 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990212203311.0083e6d0@pop.netaddress.com > 1999-02-12 17:39 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Jason Merrill 1999-02-24 16:27 ` Question about compiler-supplied assignment and copy with egcs Mike Stump [not found] ` < 199902250026.QAA04615@kankakee.wrs.com > 1999-02-25 22:31 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire [not found] ` <3.0.6.32.19990226013110.0083c530.cygnus.egcs@pop.globalserve.net> 1999-02-25 22:45 ` Jason Merrill [not found] ` < u91zjdirxx.fsf@yorick.cygnus.com > 1999-02-27 21:01 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990228000118.00923340@pop.globalserve.net > 1999-02-27 21:58 ` Question about compiler-supplied assignment and copy with Joe Buck [not found] ` < 199902280557.VAA14849@atrus.synopsys.com > 1999-02-27 23:29 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Joe Buck 1999-02-28 22:53 ` Question about compiler-supplied assignment and copy with egcs Paul Derbyshire [not found] ` <3.0.6.32.19990228000118.00923340.cygnus.egcs@pop.globalserve.net> 1999-02-27 23:55 ` Jason Merrill [not found] ` < u9yalj7yin.fsf@yorick.cygnus.com > 1999-02-28 1:10 ` Paul Derbyshire 1999-02-28 2:51 ` Tudor Hulubei [not found] ` < 14041.8114.947193.298212@hal.ttlc.net > 1999-02-28 4:36 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Tudor Hulubei 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 2:28 ` Gerald Pfeifer 1999-03-31 23:46 ` Gerald Pfeifer 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Mike Stump 2000-11-19 13:03 ` Removal of V2 code Mark Mitchell 2000-11-19 17:10 ` Geoff Keating [not found] ` <Mark> 2000-11-19 17:24 ` Christopher Faylor 2000-11-19 17:56 ` Mark Mitchell 2000-11-19 20:24 ` Geoff Keating 2000-11-19 21:52 ` Mark Mitchell 2000-11-19 22:12 ` Geoff Keating 2000-11-19 22:33 ` Mark Mitchell 2000-11-20 1:07 ` Mark Mitchell 2000-11-20 2:11 ` Geoff Keating 2000-11-21 10:56 ` Mark Mitchell 2000-11-21 12:20 ` Benjamin Kosnik 2000-11-21 12:45 ` Mark Mitchell 2000-11-21 12:37 ` Geoff Keating 2000-11-21 12:47 ` Mark Mitchell 2000-11-20 2:54 ` Franz Sirl 2000-11-21 6:38 ` Franz Sirl 2000-11-21 7:26 ` Daniel Berlin 2000-11-20 0:41 ` Andrew Cagney 2000-11-20 0:55 ` Mark Mitchell 2000-11-20 3:32 ` Marc Espie 2000-11-20 5:53 ` Joseph S. Myers 2000-11-20 8:34 ` Mark Mitchell [not found] ` <00112021562300.00259@hallo> 2000-11-20 14:58 ` Mark Mitchell 2000-11-21 14:14 ` Geoff Keating 2000-11-21 15:06 ` Mark Mitchell 2000-11-21 16:08 ` Tom Tromey 2000-11-21 17:21 ` 2.95.3 (was Re: Removal of V2 code) Joe Buck 2000-11-22 13:55 ` Tom Tromey 2000-11-21 21:41 ` Removal of V2 code Mark Mitchell 2000-11-21 20:00 ` SC confidentiality Geoff Keating 2000-11-21 21:57 ` Mark Mitchell [not found] ` <08:25:39> [not found] ` <-0700> 2001-05-09 9:58 ` Automake and friends and fastjar Mark Klein 2001-05-09 12:08 ` Tom Tromey 2001-05-09 12:15 ` Mark Klein [not found] ` <"Fri,> [not found] ` <11> [not found] ` <Jun> [not found] ` <2000> [not found] ` <10:30:29> [not found] ` <-0400> 2000-06-29 7:30 ` SSA implementation David Dolan 2000-06-29 11:59 ` Geoff Keating 2000-06-29 12:07 ` Errors from Gcc Matt Minnis 2000-06-29 13:43 ` Martin v. Loewis 2000-06-29 12:11 ` SSA implementation Mark Mitchell 2000-06-29 12:24 ` Gerald Pfeifer 2000-07-05 11:52 ` PowerPC code generation David J Schinsing 2000-07-05 12:15 ` David Young 2000-07-05 12:57 ` gcc and struct passing in function arguments? David Young 2000-07-05 13:09 ` Michael Meissner 2000-07-05 14:00 ` Joern Rennecke 2000-07-05 13:50 ` Alan Lehotsky 2000-07-05 13:26 ` PowerPC code generation Geoff Keating 2000-07-05 13:53 ` Franz Sirl 2000-07-05 14:20 ` Michael Meissner 2000-07-05 14:36 ` Geoff Keating 2000-07-05 19:54 ` David Edelsohn [not found] ` <25> [not found] ` <May> [not found] ` <2001> [not found] ` <10:06:51> [not found] ` <+0300> 2001-06-07 18:27 ` Another RFC: regex in libiberty DJ Delorie 2001-06-07 18:31 ` Ian Lance Taylor 2001-06-07 18:33 ` DJ Delorie 2001-06-07 18:43 ` Ian Lance Taylor 2001-06-08 0:11 ` Eli Zaretskii 2001-06-08 9:18 ` Mark Mitchell 2001-06-08 9:59 ` Zack Weinberg 2001-06-08 10:05 ` H . J . Lu 2001-06-08 10:31 ` Eli Zaretskii 2001-06-08 10:39 ` H . J . Lu 2001-06-08 10:37 ` Eli Zaretskii 2001-06-11 22:50 ` Jim Blandy 2001-06-11 23:51 ` Randall R Schulz 2001-06-12 6:48 ` Jim Blandy 2001-06-09 13:34 ` Andrew Cagney [not found] <19990608202201.F17154@admin3.jump.net> [not found] ` <org142xios.fsf@saci.lsd.dcc.unicamp.br> [not found] ` <3761d206.15532319@mailer.gwdg.de> [not found] ` <oru2sg6sd1.fsf@saci.lsd.dcc.unicamp.br> [not found] ` <3762cfb6.8581897@mailer.gwdg.de> [not found] ` <oru2sf6hst.fsf@saci.lsd.dcc.unicamp.br> 1999-06-10 16:01 ` libs/csengine/basic/polyset.cpp:46: Internal compiler error 191 Philipp Thomas 1999-06-30 15:43 ` Philipp Thomas [not found] ` <376b1082.25172596@mailer.gwdg.de> 1999-06-10 17:18 ` Alexandre Oliva 1999-06-10 17:50 ` Franz Sirl 1999-06-12 16:02 ` Alexandre Oliva 1999-06-15 4:11 ` Franz Sirl 1999-06-15 4:54 ` Alexandre Oliva 1999-06-30 15:43 ` Alexandre Oliva 1999-06-30 15:43 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva 1999-06-30 15:43 ` Franz Sirl 1999-06-30 15:43 ` Alexandre Oliva -- strict thread matches above, loose matches on Subject: below -- 1999-05-23 11:45 assemble_external on .class files Mark Klein 1999-05-23 19:27 ` Jeffrey A Law 1999-05-31 21:36 ` Jeffrey A Law 1999-05-31 21:36 ` Mark Klein 1999-02-24 15:13 Bug in libm or libstdc++ Paul Derbyshire [not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net > 1999-02-24 15:34 ` Joe Buck [not found] ` < 199902242332.PAA09334@atrus.synopsys.com > 1999-02-25 22:25 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net > 1999-02-26 10:38 ` Joe Buck [not found] ` < 199902261836.KAA17757@atrus.synopsys.com > 1999-02-26 22:21 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net > 1999-02-27 9:40 ` Marc Espie [not found] ` < 199902271740.SAA14323@quatramaran.ens.fr > 1999-02-27 20:45 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 0:19 ` Alexandre Oliva [not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br > 1999-03-02 7:58 ` Paul Derbyshire 1999-03-02 23:08 ` Alexandre Oliva 1999-03-31 23:46 ` Alexandre Oliva 1999-03-31 23:46 ` Paul Derbyshire 1999-03-31 23:46 ` Alexandre Oliva 1999-02-28 22:53 ` Marc Espie 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Joe Buck 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Joe Buck 1999-02-24 15:42 ` Bob McWhirter [not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org > 1999-02-25 22:20 ` Paul Derbyshire [not found] ` <199902261635.LAA23787@wagner.Princeton.EDU> 1999-02-27 19:08 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-03-01 8:30 ` Joern Rennecke [not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk > 1999-03-02 8:04 ` Paul Derbyshire [not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net > 1999-03-02 8:38 ` Joern Rennecke 1999-03-31 23:46 ` Joern Rennecke 1999-03-31 23:46 ` Paul Derbyshire 1999-03-31 23:46 ` Joern Rennecke [not found] ` <Pine.SUN.3.91.990228142826.5950V-100000@is> 1999-02-28 4:57 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Bob McWhirter 1999-02-28 22:53 ` Paul Derbyshire 1999-01-31 22:09 [Meta] Enough of the "egcs.cygnus.com" already! Paul Derbyshire 1999-01-31 22:14 ` CaT 1999-01-31 22:24 ` Bob McWhirter 1999-01-31 22:50 ` Paul Derbyshire 1999-02-01 2:01 ` Franz Sirl [not found] ` < 4.1.19990201105045.054320e0@mail.lauterbach.com > 1999-02-01 15:53 ` Paul Derbyshire 1999-02-28 22:53 ` Rask Ingemann Lambertsen 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Franz Sirl 1999-01-31 23:12 ` Ken Raeburn 1999-02-01 7:13 ` Jeffrey A Law 1999-02-01 7:27 ` Alexandre Oliva [not found] ` < or4sp6b12f.fsf@araguaia.dcc.unicamp.br > 1999-02-01 7:30 ` Jeffrey A Law 1999-02-01 7:35 ` Alexandre Oliva [not found] ` < or1zkab0ou.fsf@araguaia.dcc.unicamp.br > 1999-02-01 7:50 ` Jeffrey A Law [not found] ` < 3391.917883892@hurl.cygnus.com > 1999-02-01 8:23 ` Joe Buck [not found] ` < 199902011621.IAA00385@atrus.synopsys.com > 1999-02-01 8:24 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-01 16:03 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Joe Buck 1999-02-28 22:53 ` postmaster 1999-02-28 22:53 ` Jeffrey A Law 1999-02-01 15:58 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-28 22:53 ` Alexandre Oliva 1999-02-01 7:59 ` Ken Raeburn 1999-02-28 22:53 ` Ken Raeburn 1999-02-28 22:53 ` Jeffrey A Law 1999-02-13 10:47 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Alexandre Oliva 1999-02-28 22:53 ` Jeffrey A Law [not found] ` <19990201200631.A227@tardis.ed.ac.uk> 1999-02-01 15:31 ` Paul Derbyshire 1999-02-28 22:53 ` Paul Derbyshire 1999-02-03 12:05 ` Rask Ingemann Lambertsen 1999-02-28 22:53 ` Rask Ingemann Lambertsen [not found] <David> [not found] ` <J> [not found] <Brad> [not found] <Eli> [not found] <Paul> [not found] <Franz> [not found] <Ken>
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).