Re: egcs -O breaks ping.c:in_cksum()
On Tue, Nov 16, 1999 at 03:17:43PM +1100, Bruce Evans wrote:
On Mon, 15 Nov 1999, Pierre Beyssac wrote:
- volatile u_short answer = 0;
+ union {
+ u_int16_t us;
+ u_int8_t uc[2];
+ } answer;
This has indentation bugs.
Uh, which one(s) do you mean exactly? The 4-space indented union
(I just followed style(9)) or the double space before uc[2] (it
was just to align us and uc vertically)?
ping.c still assumes that u_short is u_int16_t everywhere else.
But in_cksum() is more or less self-contained. Probably it's more
consistent (even withing in_cksum which uses u_short elsewhere) to
change back the union to u_short and u_char, though.
This `answer' variable has nothing to do with the final `answer' variable.
The latter should not be a union. The original code apparently reuses
`answer' to do manual register allocation for ancient compilers.
Agreed.
Perhaps the above should be written as:
sum += ntohs(*(u_char *)w 8);
to avoid the undefined union access (answer.us).
Uh... I'm not sure I don't prefer the union, actually :-)
--
Pierre Beyssac [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, 16 Nov 1999 09:45:36 +0100, Pierre Beyssac wrote:
- volatile u_short answer = 0;
+ union {
+ u_int16_t us;
+ u_int8_t uc[2];
+ } answer;
Uh, which one(s) do you mean exactly? The 4-space indented union
(I just followed style(9))
The word ``union'' doesn't appear in style(9) and a 1 tab indent is used
consistently in the examples of structs. Use 1 tab.
or the double space before uc[2] (it was just to align us and uc
vertically)?
Use tabs for that as well.
Look at the rest of ping.c, and you'll see that 4-space indents aren't
used except to prevent line-wrap in one weird case of a switch block and
for run-over lines.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, Nov 16, 1999 at 10:58:06AM +0200, Sheldon Hearn wrote: The word ``union'' doesn't appear in style(9) and a 1 tab indent is used consistently in the examples of structs. Use 1 tab. Right, I reread style(9) and I apparently misunderstood the following part which only applies to code (mainly inside a statement): Indentation is an 8 character tab. Second level indents are four spaces. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, 16 Nov 1999, Pierre Beyssac wrote:
On Tue, Nov 16, 1999 at 03:17:43PM +1100, Bruce Evans wrote:
On Mon, 15 Nov 1999, Pierre Beyssac wrote:
- volatile u_short answer = 0;
+ union {
+ u_int16_t us;
+ u_int8_t uc[2];
+ } answer;
This has indentation bugs.
Uh, which one(s) do you mean exactly? The 4-space indented union
(I just followed style(9)) or the double space before uc[2] (it
was just to align us and uc vertically)?
See Sheldon's reply. u_int16_t and u_int8_t are too wide for the
normal indentation rules to apply. Various inconsistent formattings
are used for them. E.g., in Lite2, ufs/ufs/dir.h uses an extra space
in one struct and an extra tab in the others. This is another reason
to use u_short :-).
ping.c still assumes that u_short is u_int16_t everywhere else.
But in_cksum() is more or less self-contained. Probably it's more
consistent (even withing in_cksum which uses u_short elsewhere) to
change back the union to u_short and u_char, though.
There are better examples to copy in the kernel. They still use too
many shorts, ints and union hacks, however. The alpha version is
most interesting.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, Nov 15, 1999 at 05:59:23PM -0800, Kris Kennaway wrote: On Tue, 16 Nov 1999, Pierre Beyssac wrote: I've checked, the answer is no: apparently, in_cksum() in routed/rdisc.c is only called in two places, both with an even size. Can it hurt to pre-emptively fix it anyway in case some future change pulls the rug out from underneath? We could, but since the danger is purely theoretical for now (and probably will stay that way forever), I don't see any advantage in cluttering up the code. Since routed is sometimes sync'ed from external sources, it would only make life harder for the people doing the merges. Plus, everyone steals in_cksum from ping, not from routed (at least, that's what I do :-) Since in_cksum is used in several places (there's another optimized copy in libstand), a cleaner solution would be to put it in some library. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
In message [EMAIL PROTECTED], Pierre Beyssac writes: Since in_cksum is used in several places (there's another optimized copy in libstand), a cleaner solution would be to put it in some library. Isn't there one in libalias already ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, Nov 16, 1999 at 07:29:35PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Pierre Beyssac writes: Since in_cksum is used in several places (there's another optimized Isn't there one in libalias already ? Right. I missed it because it's called PacketAliasInternetChecksum()... -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, 15 Nov 1999 17:48:31 +0100, Pierre Beyssac wrote: I've discovered the following problem, either due to egcs or the source code for in_cksum in ping, I'm not sure. Alas, you're not in virgin territory, Columbus. :-) See PR 13292. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, Nov 15, 1999 at 06:52:23PM +0200, Sheldon Hearn wrote: On Mon, 15 Nov 1999 17:48:31 +0100, Pierre Beyssac wrote: I've discovered the following problem, either due to egcs or the source code for in_cksum in ping, I'm not sure. See PR 13292. Wow, Thanks! August 21th, it's not really new... Maybe I can at least commit the addition of "volatile" to the source code. That will work around that particular bug until egcs is fixed... That doesn't say how many occurences of similar code there are in the rest of the system, of course. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, 15 Nov 1999 18:01:45 +0100, Pierre Beyssac wrote: Maybe I can at least commit the addition of "volatile" to the source code. That will work around that particular bug until egcs is fixed... FWIW, the newly committed gcc-2.95.2 doesn't "fix" the problem. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
Maybe I can at least commit the addition of "volatile" to the source code. That will work around that particular bug until egcs is fixed... FWIW, the newly committed gcc-2.95.2 doesn't "fix" the problem. Are you sure? GCC-2.95.2 seems OK here. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, 15 Nov 1999 18:01:45 +0100, Pierre Beyssac [EMAIL PROTECTED] said: Maybe I can at least commit the addition of "volatile" to the source code. That will work around that particular bug until egcs is fixed... It's not a compiler bug, it's a source code bug. The C Language specifies that pointers to distinct types can be assumed, under certain conditions, never to alias one another. (This might actually be a C99 feature as opposed to C89.) Recent values of GCC make use of this obscure language feature to improve optimization. Essentially, the optimizer can assume that stores through a pointer of type `foo *' will never modify any local variable which is not of type `foo' (and thus those values can remain cached in registers). If, rather than casting pointers, the code used a union (containing one u_int16_t and one array[2] of u_int8_t), the compiler would have enough information to know about the aliases. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, Nov 15, 1999 at 01:35:15PM -0500, Garrett Wollman wrote:
If, rather than casting pointers, the code used a union (containing
one u_int16_t and one array[2] of u_int8_t), the compiler would have
enough information to know about the aliases.
You're right, this seems to work even with optimization turned on.
If nobody objects, I'll commit it.
--- ck.c.oldMon Nov 15 19:41:35 1999
+++ ck.cMon Nov 15 19:39:43 1999
@@ -13,7 +13,10 @@
register int nleft = len;
register u_short *w = addr;
int sum = 0;
- volatile u_short answer = 0;
+ union {
+ u_int16_t us;
+ u_int8_t uc[2];
+ } answer;
/*
* Our algorithm is simple, using a 32 bit accumulator (sum), we add
@@ -27,15 +30,16 @@
/* mop up an odd byte, if necessary */
if (nleft == 1) {
- *(u_char *)(answer) = *(u_char *)w ;
- sum += answer;
+ answer.uc[0] = *(u_char *)w ;
+ answer.uc[1] = 0;
+ sum += answer.us;
}
/* add back carry outs from top 16 bits to low 16 bits */
sum = (sum 16) + (sum 0x); /* add hi 16 to low 16 */
sum += (sum 16); /* add carry */
- answer = ~sum; /* truncate to 16 bits */
- return(answer);
+ answer.us = ~sum; /* truncate to 16 bits */
+ return(answer.us);
}
int main()
--
Pierre Beyssac [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
:It's not a compiler bug, it's a source code bug. : :The C Language specifies that pointers to distinct types can be :assumed, under certain conditions, never to alias one another. (This :... :Recent values of GCC make use of this obscure language feature to :improve optimization. Essentially, the optimizer can assume that :... :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same Someone try the patch below and tell me if it fixes the problem. If it does then I'll commit it. If someone else wants to commit a 'better' fix, be my guest! (but inform the list that you've done so). Otherwise this is the one that will go in. -Matt Index: ping.c === RCS file: /home/ncvs/src/sbin/ping/ping.c,v retrieving revision 1.45 diff -u -r1.45 ping.c --- ping.c 1999/08/28 00:13:59 1.45 +++ ping.c 1999/11/15 19:26:23 @@ -920,6 +920,9 @@ /* * in_cksum -- * Checksum routine for Internet Protocol family headers (C Version) + * + * note: volatilization of 'answer' is a bad hack to work around an + * aliasing problem. */ u_short in_cksum(addr, len) @@ -929,7 +932,7 @@ register int nleft = len; register u_short *w = addr; register int sum = 0; - u_short answer = 0; + volatile u_short answer = 0; /* * Our algorithm is simple, using a 32 bit accumulator (sum), we add To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
[in_cksum bugs] Fix committed for ping. There's another bug in sbin/routed/rdisc.c:in_cksum() on odd packet sizes, albeit I'm not sure it's ever triggered (does routed ever generate odd-size packets?). It's a portability bug (works only on little-endian machines). I'll commit the same fix if there's no objection. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
[in_cksum bugs] There's another bug in sbin/routed/rdisc.c:in_cksum() on odd packet sizes, albeit I'm not sure it's ever triggered (does routed ever generate odd-size packets?). I've checked, the answer is no: apparently, in_cksum() in routed/rdisc.c is only called in two places, both with an even size. -- Pierre Beyssac[EMAIL PROTECTED] [EMAIL PROTECTED] BSD : il y a moins bien, mais c'est coté en bourse Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Tue, 16 Nov 1999, Pierre Beyssac wrote: [in_cksum bugs] There's another bug in sbin/routed/rdisc.c:in_cksum() on odd packet sizes, albeit I'm not sure it's ever triggered (does routed ever generate odd-size packets?). I've checked, the answer is no: apparently, in_cksum() in routed/rdisc.c is only called in two places, both with an even size. Can it hurt to pre-emptively fix it anyway in case some future change pulls the rug out from underneath? Kris Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs -O breaks ping.c:in_cksum()
On Mon, 15 Nov 1999, Pierre Beyssac wrote:
On Mon, Nov 15, 1999 at 01:35:15PM -0500, Garrett Wollman wrote:
If, rather than casting pointers, the code used a union (containing
one u_int16_t and one array[2] of u_int8_t), the compiler would have
enough information to know about the aliases.
You're right, this seems to work even with optimization turned on.
If nobody objects, I'll commit it.
--- ck.c.old Mon Nov 15 19:41:35 1999
+++ ck.c Mon Nov 15 19:39:43 1999
@@ -13,7 +13,10 @@
register int nleft = len;
register u_short *w = addr;
int sum = 0;
- volatile u_short answer = 0;
+ union {
+ u_int16_t us;
+ u_int8_t uc[2];
+ } answer;
This has indentation bugs.
ping.c still assumes that u_short is u_int16_t everywhere else.
/*
* Our algorithm is simple, using a 32 bit accumulator (sum), we add
@@ -27,15 +30,16 @@
/* mop up an odd byte, if necessary */
if (nleft == 1) {
- *(u_char *)(answer) = *(u_char *)w ;
- sum += answer;
+ answer.uc[0] = *(u_char *)w ;
+ answer.uc[1] = 0;
+ sum += answer.us;
This `answer' variable has nothing to do with the final `answer' variable.
The latter should not be a union. The original code apparently reuses
`answer' to do manual register allocation for ancient compilers.
Perhaps the above should be written as:
sum += ntohs(*(u_char *)w 8);
to avoid the undefined union access (answer.us). I think this works
on all systems, but it is a pessimisation on some little-endian systems
including i386's (on i386's, ntohs() is inline, but it is inline asm
so the compiler can't see that it just reverses the shift).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: egcs unstable
"MM" == Marcel Moolenaar [EMAIL PROTECTED] writes: MM After (by accident) compiling world (excluding kernel) with MM optimization disabled (ie -O0) and installing the resulting MM binaries, xemacs (21.1.7) coredumps with a bus error. I MM recompiled and reinstalled xemacs and all was fine. Now, after MM building and installing world (excluding kernel again) with MM optimization (ie -O), xemacs does exactly the same: core dumps MM on bus error. I'll recompile xemacs again and expect it to be MM solved, but something is definitely broken: xemacs should not MM core dump after recompiling world with only a simple change in MM compiler flags. Are you sure this isn't a problem with xemacs itself? Reading the xemacs group, I read about crashes all the time on various platforms. It is getting worse with newer versions (the 19.x versions were pretty stable). Anyway I stick to good old GNU emacs (I can do without inline images for the time being) which is rock solid, also after -current 'make world's. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs unstable
On Sat, 13 Nov 1999, Marcel Moolenaar wrote: BTW: I also don't need inline images, but I find xemacs more appealing in an X env. Funny ... I only find xemacs useful when *not* using X, because that's where xemacs will do syntax coloring and emacs won't. Followups redirected to -chat. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs unstable
Marcel Moolenaar [EMAIL PROTECTED] writes: After (by accident) compiling world (excluding kernel) with optimization disabled (ie -O0) and installing the resulting binaries, xemacs (21.1.7) coredumps with a bus error. I recompiled and reinstalled xemacs and all was fine. Now, after building and installing world (excluding kernel again) with optimization (ie -O), xemacs does exactly the same: core dumps on bus error. I'll recompile xemacs again and expect it to be solved, but something is definitely broken: xemacs should not core dump after recompiling world with only a simple change in compiler flags. I don't believe that it's the compiler flag change that is causing this. My xemacs has been core dumping after each build and install of world the last couple of times I did it. I have not had time to investigate the real cause yet. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs unstable
According to Kevin Street: this. My xemacs has been core dumping after each build and install of world the last couple of times I did it. I have not had time to investigate the real cause yet. I got the same problem between 3.3-R and 3.3-STABLE as well. Recompiling fixed it. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EGCS, or EGCS?
look at gcc's behaviour. This has left me somewhat confused. I
appear to have two complete copies of gcc - one in src/contrib/gcc and
another in src/contrib/egcs/gcc.
WIP. src/contrib/egcs is the current home. It is moving to
src/contrib/{gcc,libio,libstdc++,etc.}. After the move, it will be
upgraded to 2.95.1. School year has started, advisor been very
demanding, and I've been AWOL for 2-3 weeks now. :-(
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: EGCS, or EGCS?
: David O'Brien is working on this now but I think he's : suffering from gcc-induced insanity. :-) Actually, I'd bet more on amd induced insanity rather than gcc. There have been too many problems with amd of late... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EGCS, or EGCS?
According to Peter Jeremy: That's the way I remembered things. What threw me is that I currently have two _different_ gcc directories, both claiming to be EGCS 1.1.2, and both being updated. The main reason is that we don't lose history with the directory change. At first we had contrib/gcc, then it moved into contrib/egcs then back to contrib/gcc. By importing egcs on top of 2.7.2.3 in contrib/gcc we have a clear line going from gcc to egcs to gcc in one place. As soon as 2.95.1 gets imported, contrib/egcs will disappear. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EGCS, or EGCS?
Peter Wemm [EMAIL PROTECTED] wrote: Peter Jeremy wrote: I appear to have two complete copies of gcc - one in src/contrib/gcc and another in src/contrib/egcs/gcc. src/contrib/gcc is where gcc used to live. Then along came egcs with a cygnus-style tree that ended up in src/contrib/egcs (v1.1.1 and later 1.1.2). Now, egcs has become gcc 2.95, so it's going back to src/contrib/ gcc again. That's the way I remembered things. What threw me is that I currently have two _different_ gcc directories, both claiming to be EGCS 1.1.2, and both being updated. David O'Brien is working on this now but I think he's suffering from gcc-induced insanity. :-) I guess that's one explanation... Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs, libstdc++, libg++, Class Library
On Thu, May 13, 1999 at 09:32:06PM -0500, Thomas T. Veldhouse wrote: Have you tried using the C++ standard way? It works. #include iostream #include string using namespace std; Of course, there are many times you won't want to include the entire namespace. You don't need to. EGCS is still buggy with namespaces because namespace std is on by default. -- German Tischler ta...@gaspode.franken.de ta...@cip.informatik.uni-wuerzburg.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs, libstdc++, libg++, Class Library
The new ISO Standard C++ is upon you! Rejoice! libg++ is not updated. libg++ is *dead*. Its has mostly been superseded by the STL. See http://egcs.cygus.com/ and the G++ FAQ for details. For those that absolutely need some of the libg++ classes, you can download libstdc++-2.8.1.1.tar.gz the will work with EGCS 1.1.2 / GCC 2.8.1 from ftp://egcs.cygnus.com/pub/egcs/infrastructure/ (or maybe also prep.ai.mit.edu) libstdc++ has some classes 'if 0'-ed out. What from the ISO standard is missing from libstdc++? I have a project that uses the string class and iostream. Whose string class? C++ string classes are even better than standards -- everybody's got one so there's so many to choose from (and of course none of their API's match). Or, is there a near-term fix for the egcs package? There is no fix for the EGCS package as it isn't broken. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs, libstdc++, libg++, Class Library
Have you tried using the C++ standard way? It works. #include iostream #include string using namespace std; Of course, there are many times you won't want to include the entire namespace. Tom Veldhouse ve...@visi.com On Thu, 13 May 1999, Thomas Dean wrote: I think I missed something, again. What is the current and near-future status of Class Libraries? libg++ is not updated. libstdc++ has some classes 'if 0'-ed out. I have a project that uses the string class and iostream. I cannot build it with -current as of Apr 11. Is the solution to get and install libg++? Or, is there a near-term fix for the egcs package? tomdean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS
I forgot the particular error, but I don't think I'm doing it right. Is The actual error would be most helpful, otherwise this is sort of a waste of email. :( there something that I have to do before I do a make world? Thanks. A make world, assuming that you're already ELF, should do it. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS
In message pine.bsf.4.05.9904112257120.2543-100...@culverk.student.umd.edu Kenneth Wayne Culver writes: : I forgot the particular error, but I don't think I'm doing it right. Is : there something that I have to do before I do a make world? Thanks. Read src/UPDATING for a start. If the error isn't there, then please post the error. We can't do anything without a specific error message. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
On Sun, Apr 04, 1999 at 04:02:28PM -0700, David O'Brien wrote: what's the name of the system compiler going to be, egcs or gcc, or cc? And the C++ one? No change in names. cc/gcc and c++/g++/CC -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. Thanks. -- Glenn Johnson gljo...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS troubles
Compile Jade with -g and see where in the coredump the signal 11 is occuring.? What does ``ldd jade'' show?? You might be mixing shared libs, that doesn't work for C++.? Could also be an exceptions problem.? Try compiling with -fnoexpcetions. [asmo...@daemon] (163) $ ldd /usr/local/bin/jade /usr/local/bin/jade: ??? libstyle.so.1 = /usr/local/lib/libstyle.so.1 (0x280b6000) ??? libspgrove.so.1 = /usr/local/lib/libspgrove.so.1 (0x282ac000) ??? libgrove.so.1 = /usr/local/lib/libgrove.so.1 (0x282ef000) ??? libsp.so.1 = /usr/local/lib/libsp.so.1 (0x282f7000) ??? libintl.so.1 = /usr/local/lib/libintl.so.1 (0x284ce000) ??? libstdc++.so.3 = /usr/lib/libstdc++.so.3 (0x284d2000) ??? libm.so.2 = /usr/lib/libm.so.2 (0x2850d000) ??? libc.so.3 = /usr/lib/libc.so.3 (0x28527000) I know for certain that libintl is gcc. Will go and do recompilations of all stuff this weekend *sigh*? ;) ? In my case (it seems all libs compiled under egcs - exactly when jade compiled): /usr/local/bin/jade: ??? libstyle.so.1 = /usr/local/lib/libstyle.so.1 (0x280b9000) ??? libspgrove.so.1 = /usr/local/lib/libspgrove.so.1 (0x282b6000) ??? libgrove.so.1 = /usr/local/lib/libgrove.so.1 (0x282f9000) ??? libsp.so.1 = /usr/local/lib/libsp.so.1 (0x28301000) ??? libstdc++.so.3 = /usr/lib/libstdc++.so.3 (0x284e4000) ??? libm.so.2 = /usr/lib/libm.so.2 (0x28521000) ??? libc.so.3 = /usr/lib/libc.so.3 (0x2853c000) ? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS troubles
The Only way I could get Jade to work with the new compiler was with CFLAGS= -O -pipe That is not so bad. Before EGCS, we would state that -O is the only optimization that is know to always work and what we tell people to use. Mike Smith has written about this many times in Hackers and Current. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS troubles
At 09:58 AM 4/9/99 +0300, Maxim Sobolev wrote: Compile Jade with -g and see where in the coredump the signal 11 is occuring. What does ``ldd jade'' show? You might be mixing shared libs, that doesn't work for C++. Could also be an exceptions problem. Try compiling with -fnoexpcetions. [asmo...@daemon] (163) $ ldd /usr/local/bin/jade /usr/local/bin/jade: libstyle.so.1 = /usr/local/lib/libstyle.so.1 (0x280b6000) libspgrove.so.1 = /usr/local/lib/libspgrove.so.1 (0x282ac000) libgrove.so.1 = /usr/local/lib/libgrove.so.1 (0x282ef000) libsp.so.1 = /usr/local/lib/libsp.so.1 (0x282f7000) libintl.so.1 = /usr/local/lib/libintl.so.1 (0x284ce000) libstdc++.so.3 = /usr/lib/libstdc++.so.3 (0x284d2000) libm.so.2 = /usr/lib/libm.so.2 (0x2850d000) libc.so.3 = /usr/lib/libc.so.3 (0x28527000) I know for certain that libintl is gcc. Will go and do recompilations of all stuff this weekend *sigh* ;) In my case (it seems all libs compiled under egcs - exactly when jade compiled): /usr/local/bin/jade: libstyle.so.1 = /usr/local/lib/libstyle.so.1 (0x280b9000) libspgrove.so.1 = /usr/local/lib/libspgrove.so.1 (0x282b6000) libgrove.so.1 = /usr/local/lib/libgrove.so.1 (0x282f9000) libsp.so.1 = /usr/local/lib/libsp.so.1 (0x28301000) libstdc++.so.3 = /usr/lib/libstdc++.so.3 (0x284e4000) libm.so.2 = /usr/lib/libm.so.2 (0x28521000) libc.so.3 = /usr/lib/libc.so.3 (0x2853c000) The Only way I could get Jade to work with the new compiler was with CFLAGS= -O -pipe The only way I have tested it is by building the Handbook -O2 -pipe built ,but Signal 11 -O2 -fno-exceptions won't build Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS troubles
At 09:37 AM 4/9/99 -0700, David O'Brien wrote: The Only way I could get Jade to work with the new compiler was with CFLAGS= -O -pipe That is not so bad. Before EGCS, we would state that -O is the only optimization that is know to always work and what we tell people to use. Mike Smith has written about this many times in Hackers and Current. mysql322 from ports is another one, if you try and compile it with the stock -O -pipe it builds up till almost the end but when it gets to sql.yacc.cc the machine just hangs there and finally dies (no input or output). I have to go into the debugger and reboot. But if you add -fno-exceptions it builds fine.It's taken a couple of days but I've weeded out all of the programs that depended on old gcc libs and rebuilt them. Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS
On Wed, Apr 07, 1999 at 07:17:42PM +0200, Jeroen Ruigrok/Asmodai wrote: On 07-Apr-99 Kenneth Wayne Culver wrote: I can't get a make world to work with egcs. I deleted the whole obj directory, and recvsuppped the entire source tree, and it still doesn't work. Every time I cvsup I get a different error while compiling. OK, make sure ye go to /usr/src/gnu/usr.bin/cc first make clean, make obj, make depend, make, make install then try the libs in /usr/src/lib/ with roughly the same make targets. Then try to make a world again. remove /usr/include and build it freshly before doing the above with make includes I remeember somebody mentioned, that there might be some old header files -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS
remove /usr/include and build it freshly before doing the above with make includes cd /usr/src make -DCLOBBER includes is the perfered method. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS troubles
eebsd.dsl -t sgml handbook.sgml *** Signal 11 Interesting that when it was compiled using pgcc port it worked just fine. Then it would probably do fine using the EGCS Port. But, the port != /usr/src. The library setup of EGCS in /usr/src is very different than the Port -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: EGCS troubles
On 08-Apr-99 Maxim Sobolev wrote: Hi, While this problem might not belongs to this list however it is difficult in this case to distinguish exactly. Something broken in new egcs c++ compiler - jade doesn't work with following symptoms (checked on two machines). Apr 7 20:26:04 daemon /kernel: pid 61135 (jade), uid 0: exited on signal 11 (core dumped) Verified... David, might this be due to the compiler itself of the libraries? Any way of making certain? --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS troubles
Something broken in new egcs c++ compiler - jade doesn't work with following symptoms (checked on two machines). Apr 7 20:26:04 daemon /kernel: pid 61135 (jade), uid 0: exited on signal 11 (core dumped) Verified... David, might this be due to the compiler itself of the libraries? Any way of making certain? Compile Jade with -g and see where in the coredump the signal 11 is occuring. What does ``ldd jade'' show? You might be mixing shared libs, that doesn't work for C++. Could also be an exceptions problem. Try compiling with -fnoexpcetions. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS troubles
On 08-Apr-99 David O'Brien wrote: Something broken in new egcs c++ compiler - jade doesn't work with following symptoms (checked on two machines). Apr 7 20:26:04 daemon /kernel: pid 61135 (jade), uid 0: exited on signal 11 (core dumped) Verified... David, might this be due to the compiler itself of the libraries? Any way of making certain? Compile Jade with -g and see where in the coredump the signal 11 is occuring. What does ``ldd jade'' show? You might be mixing shared libs, that doesn't work for C++. Could also be an exceptions problem. Try compiling with -fnoexpcetions. [asmo...@daemon] (163) $ ldd /usr/local/bin/jade /usr/local/bin/jade: libstyle.so.1 = /usr/local/lib/libstyle.so.1 (0x280b6000) libspgrove.so.1 = /usr/local/lib/libspgrove.so.1 (0x282ac000) libgrove.so.1 = /usr/local/lib/libgrove.so.1 (0x282ef000) libsp.so.1 = /usr/local/lib/libsp.so.1 (0x282f7000) libintl.so.1 = /usr/local/lib/libintl.so.1 (0x284ce000) libstdc++.so.3 = /usr/lib/libstdc++.so.3 (0x284d2000) libm.so.2 = /usr/lib/libm.so.2 (0x2850d000) libc.so.3 = /usr/lib/libc.so.3 (0x28527000) I know for certain that libintl is gcc. Will go and do recompilations of all stuff this weekend *sigh* ;) --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
On Wed, Apr 07, 1999 at 12:51:50AM -0700, David O'Brien wrote: AFAIK, there are *NO* remaining bootstrap problems. NOTE, I am assuming one is *NOT* using the -j option. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
* From: David O'Brien obr...@nuxi.com * * Hi all, * * I just committed a fix to the libstdc++ errors people see on the initial * bootstrap from gcc 2.7.2 to EGCS. AFAIK, there are *NO* remaining * bootstrap problems. I don't know about the bootstrapping problems but 4.0-snaps started showing up again on current.freebsd.org today (19990406) so I rebuilt the XFree86 (private) package and just started a whole-tree package build. Errors are starting to appear in http://bento.freebsd.org/~asami/errorlogs/4-latest/ -PW To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
I don't know about the bootstrapping problems but 4.0-snaps started showing up again on current.freebsd.org today (19990406) I wouldn't trust that 4.0-snap. That one should have a broken /usr/lib/libstdc++. I can send you working versions if you need. The 19990407 4.0-snap should be gold (well silver as we are still using the worse of the excptions stack unwinding method, jdp and I will change this soon) -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
* From: David O'Brien obr...@nuxi.com * I wouldn't trust that 4.0-snap. That one should have a broken * /usr/lib/libstdc++. I can send you working versions if you need. * * The 19990407 4.0-snap should be gold (well silver as we are still using * the worse of the excptions stack unwinding method, jdp and I will change * this soon) Thanks for the notice, but don't worry too much. I just meant to say I've restarted the regular package building on both 3.1 and 4.0 trees. By the way, do I need to rebuild the private XFree86 package when I grab a better snap or is that not necessary? (That part is not automatic) -PW To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
By the way, do I need to rebuild the private XFree86 package when I grab a better snap or is that not necessary? (That part is not automatic) I don't believe there are any C++ programs in XFree86, so you would be Ok. You would have noticed that C++ programs would not link. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
* From: David O'Brien obr...@nuxi.com * I don't believe there are any C++ programs in XFree86, so you would be * Ok. You would have noticed that C++ programs would not link. Ok, thanks. BTW, the list of ports that built in 3.1 but failed in 4.0 are in http://bento.freebsd.org/~asami/errorlogs/4-latest-3-latest.html The netscape's are a known problem (no a.out libs), I don't know about the rest. -PW To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
The 19990407 4.0-snap should be gold (well silver as we are still using the worse of the excptions stack unwinding method, jdp and I will change this soon) That snap and those following it are pending... Peter broke the compat lib stuff last night so the snaps are falling over again. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
On 07-Apr-99 Satoshi - the Wraith - Asami wrote: Errors are starting to appear in http://bento.freebsd.org/~asami/errorlogs/4-latest/ Weird that CoolEdit is on that list. I built both 3.8.3 and 3.9.0 by hand here using gcc and egcs, both work a-ok after patching up ltconfig to make shared libs. --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: EGCS
On 07-Apr-99 Kenneth Wayne Culver wrote: I can't get a make world to work with egcs. I deleted the whole obj directory, and recvsuppped the entire source tree, and it still doesn't work. Every time I cvsup I get a different error while compiling. OK, make sure ye go to /usr/src/gnu/usr.bin/cc first make clean, make obj, make depend, make, make install then try the libs in /usr/src/lib/ with roughly the same make targets. Then try to make a world again. HTH, --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
Alex Zepeda wrote: On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. Really? The pgcc web page (goof.com/pcg) lead me to believe that there were a few more optimizations turned on by -O5 -O6.. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message As far as I know, pgcc is different from egcs. I had pgcc, it did *significantly* better code than gcc at the time (about 1 to 2 years before), especially in floating point code, but it was buggy. I have egcs-1.2 (on a current-3.0) and I am rather disappointed with the code performance. With standard code without floating point calculations it does a bit worse than old gcc-2.7.x. In floating point (as in Mesa, ..) it is awful. It generates much slower code, than gcc-2.7.x. I am using an old Linpack benchmark (Calculate n linear equations) and I can get best perfomance usually with gcc-2.7.x using -O (*not* -O2!!). The same seems to be true with egcs, but more so. Egcs with x86-prozessors work best with -O, don't use more (-marchxxx does nothing significant). I understand there are reasons to switch to egcs (exceptions, C++ enhancements,..) but I hope they will do something for egcs' code performance. (Does code size really matter that much. Sure, it accumulates, but...). -- Helmut F. Wirth Email: hfwi...@teleweb.at To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
On Tue, 6 Apr 1999, David O'Brien wrote: Well what would be the chances of getting the pgcc patches committed? I'm quite interested in doing this, BUT only after the dust has settled on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC patches aren't available yet. jdp and I have another round of bootstraping to fix our current less-than-optimal exception handling. I want to wait a week or so until putting the changes into the tree. It's important to note that PGCC is NOWHERE NEAR production quality, last time I tried it, and not proven at all. I express no animosity toward PGCC itself, but unless it's been proven, I'd strongly oppose anything like this. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
* Weird that CoolEdit is on that list. * * I built both 3.8.3 and 3.9.0 by hand here using gcc and egcs, both work * a-ok after patching up ltconfig to make shared libs. Did you click on the links to see what it's complaining about? It worked here doesn't mean much in this context, as the package building is done in a much more strict environment (empty /usr/local, PLIST checked (implicitly) by building package, etc.). -PW To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS
On Wed, Apr 7, 1999, Kenneth Wayne Culver wrote: I can't get a make world to work with egcs. I deleted the whole obj directory, and recvsuppped the entire source tree, and it still doesn't work. Every time I cvsup I get a different error while compiling. CVSup now, and build world. Do _not_ attempt to build world with the -j flag, dependancies will fail to build properly and the compile will certainly fail. -Chris Please Help. Kenneth Culver To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- = * This process can check if this value is * * zero, and if it is, it does something* * child-like. -Forbes Burkowski, CS 454 * = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS
On Wed, 7 Apr 1999, Chris Costello wrote: On Wed, Apr 7, 1999, Kenneth Wayne Culver wrote: I can't get a make world to work with egcs. I deleted the whole obj directory, and recvsuppped the entire source tree, and it still doesn't work. Every time I cvsup I get a different error while compiling. CVSup now, and build world. Do _not_ attempt to build world with the -j flag, dependancies will fail to build properly and the compile will certainly fail. And note that there have been several little bugs that have been cleared already, so if it doesn't do it the first time, have faith and cvsup again. It's built twice bad for me (the first 2 times) and since, twice good. -Chris Please Help. Kenneth Culver To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- = * This process can check if this value is * * zero, and if it is, it does something* * child-like. -Forbes Burkowski, CS 454 * = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS bootstrapping believed to be working
On 08-Apr-99 Satoshi - the Wraith - Asami wrote: * Weird that CoolEdit is on that list. * * I built both 3.8.3 and 3.9.0 by hand here using gcc and egcs, both work * a-ok after patching up ltconfig to make shared libs. Did you click on the links to see what it's complaining about? It worked here doesn't mean much in this context, as the package building is done in a much more strict environment (empty /usr/local, PLIST checked (implicitly) by building package, etc.). Sure it means much, I am the libtool nagging guy *g* This means that I always verify ltconfig. Now go look at the cooledit logs, someone forgot to patch ltconfig to create shared libraries. The patch is straightforward and I believe 3.9.0 has this incorporated and else maintainer oughtta be nagging the programmers about migrating to libtool 1.2f to at least solve the shared library problem on FreeBSD 4.x. Probably tons of others in that list... I will look at the log today and give ye an oversight of the ltconfig problemcases... --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
In the last episode (Apr 05), Alex Zepeda said: Have you tried anything beyond -O2? There is only -O3, which is just like -O2 except that it tries to inline all functions. -Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
Alternately, we could jimmy around with the current hack, and prefix it with 4 NULs, and see what happened. Sorry, I haven't tested this idea, as I've not yet made the EGCS jump. egcs aligns long (= about 28 bytes) strings to 32-byte boundaries. This adds up to 27 NULs to sccsid[] depending on the alignment of sccsidp[]. Aligning long strings to 32-byte boundaries is a pessimisation in kernels (because it makes poor locality poorer), especially on 486's where the cache line size is 16. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. When I tested this last year, -O3 on egcs produced a 10-15% slowdown for things like 'gzip'. OTOH, gcc's -O3 produced slightly faster code (as I recall). I /do/ however see noticeable (10-20%) speed improvements using -O2 -mpentium -march=pentium compared to -O2 -mno-486 on gcc. Kris - The Feynman problem-solving algorithm: 1. Write down the problem 2. Think real hard 3. Write down the solution To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. The only other optimization that might be useful is -fomit-frame-pointer, but it makes debugging impossible. Incorrect. gdb 4.18 supports frame-pointerless debugging, and gcc will generate the proper DWARF2 info to support it. I've done it before many times. In fact, two of the test programs in the testsuite i use to test my BeOS port of GDB are compiled specifically *with* -fomit-frame-pointer to amke sure the DWARF2 reading and unwinding is working properly. I don't know if it's in the 1.1 branch, i know it's been in the HEAD branch for a while. on the gdb side, i remember seeing it sometime after february, and i've used it since march. Also, if you guys want to play the EGCS benchmark game, let me point you to the *surprise* BENCHMARKS, a link to which can be found on the egcs homepage (as well as test suite results). They are very well organized. Go submit some results so people have more to compare against. Also, -mpentiumpro will actually usually generate WORSE code for a pentium pro. -mpentium and -march=pentium do better at it. I would use -O2 with the 1.1 branch, and -O99 with the head branch. As the benchmarks note, -O6 *IS* faster than -O3 which *IS* faster than -O2. They usually use the higher -O levels to test out experimental optimizations. Another useful optimization is -funroll-loops, which does what you think it does. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
Matthew Dillon wrote: :Totally informally, I replaced libc (compiled with -O2) with one compiled :with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit :slower (GNU make took longer to traverse directories and egcs took a bit :longer to run). : : Which leads me to believe that using -Os might be beneficial. : :Have you tried anything beyond -O2? : :- alex There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. The only other optimization that might be useful is -fomit-frame-pointer, but it makes debugging impossible. I don't have oppurtunity to use CURRENT, but on 3.1-RELEASE and 2.2.8 -fomit-frame-pointer applied to kernel compilation leads to system crash. If you want to reproduce this, compile kernel with -O -fomit-frame-pointer, reboot, and try, for example, to build kernel with make -j 16 ;) -Matt Matthew Dillon dil...@backplane.com -- Pavel Narozhniy nic-hdl: PN395-RIPE http://www.sumy.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
Hi, At 2:15 am -0700 6/4/99, Daniel Berlin wrote: Also, -mpentiumpro will actually usually generate WORSE code for a pentium pro. -mpentium and -march=pentium do better at it. OK, but according to man cc: NAME gcc, g++ - GNU project C and C++ Compiler (egcs-1.1.2) [...] -mpentium Synonym for -mcpu=pentium [...] Specifying -march=cpu type implies -mcpu=cpu type. If this is right, then -mpentium is redundant in the presence of -march=pentium. -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
I always use both (because it's in my darn makefiles :P), but that sounds correct to me. If it said -mpentium implied -march=pentium, i'd say it's lying. most of the -mwhatever architecture alone are worthless, it's the -march's that matter (note i say most to mean of the 4 architectures i've played with -m and -march on). On Tue, 6 Apr 1999, Bob Bishop wrote: Hi, At 2:15 am -0700 6/4/99, Daniel Berlin wrote: Also, -mpentiumpro will actually usually generate WORSE code for a pentium pro. -mpentium and -march=pentium do better at it. OK, but according to man cc: NAME gcc, g++ - GNU project C and C++ Compiler (egcs-1.1.2) [...] -mpentium Synonym for -mcpu=pentium [...] Specifying -march=cpu type implies -mcpu=cpu type. If this is right, then -mpentium is redundant in the presence of -march=pentium. -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
'what' is broken. C does not impose any sort of address ordering restriction on globals or autos that are declared next to each other. Right, except that 'what' isn't broken. It is vers.c (and conf/newvers.sh) that is broken, believing that the two variables will be allocating in contiguous memory. Changing newvers.sh to generate char sccs[] = @( #) FreeBSD ...; char version = FreeBSD ...; will make what on the kernel work again, at the expense of about 100 duplicated bytes. The real question is whether the extreme alignment and padding used by EGCS can be turned off, especially for 486s. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
The real question is whether the extreme alignment and padding used by EGCS can be turned off, especially for 486s. Considering it... probably based on -m486. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: EGCS optimizations
-Original Message- From: Matthew Dillon [mailto:dil...@apollo.backplane.com] Sent: 06 April 1999 05:58 To: curr...@freebsd.org Subject: EGCS optimizations Compiling up /usr/src/usr.sbin with egcs and libc compiled with: -O2 160 seconds -O2 -march=pentiumpro 162 seconds -Os 161 seconds Which leads me to believe that using -Os might be beneficial. If I'm reading that right you timed how long it took to build /usr/src/usr.sbin using egcs and libc compiled with the above optimisations? I doubt that that sort of benchmark is going to say an awful lot about the performance of the optimisation levels since compiling /usr/sr/usr.sbin is going to be affected by disk i/o performance far more than it would be by cpu performance. The relative speed differences of the different egcs/libc binaries is probably smoothed out by the i/o affects which is why the times look so similar. Something that is more cpu bound would be a better benchmark for comparing the optimisation options. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
:I doubt that that sort of benchmark is going to say an awful lot about the :performance of the optimisation levels since compiling /usr/sr/usr.sbin is :going to be affected by disk i/o performance far more than it would be by :cpu performance. The relative speed differences of the different egcs/libc :binaries is probably smoothed out by the i/o affects which is why the times :look so similar. : :Something that is more cpu bound would be a better benchmark for comparing :the optimisation options. : : :Paul. That test was 100% cpu bound. There was no ( significant ) I/O. I ran it a few times to build the cache before timing it. It's no big deal, really. I think the EGCS bandwagon is going to continue to move forward and PGCS runs on top of it, so moving to EGCS puts FreeBSD in a better position in the long term. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
In message 199904062001.naa10...@apollo.backplane.com, Matthew Dillon writes: That test was 100% cpu bound. There was no ( significant ) I/O. I ran it a few times to build the cache before timing it. What is the stddev on your measurements ? a delta-T 1 second need a very tight stddev to be significant. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Alex Zepeda wrote: On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. Really? The pgcc web page (goof.com/pcg) lead me to believe that there were a few more optimizations turned on by -O5 -O6.. pgcc isn't the same as egcs the current -mpentiumpro and -mpentiumarch stuff were taken from pgcc and ported back to egcs but i believe that pgcc has gone way beyond what it was when that happened. rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
On Tue, 6 Apr 1999, Bruce Evans wrote: Alternately, we could jimmy around with the current hack, and prefix it with 4 NULs, and see what happened. Sorry, I haven't tested this idea, as I've not yet made the EGCS jump. egcs aligns long (= about 28 bytes) strings to 32-byte boundaries. This adds up to 27 NULs to sccsid[] depending on the alignment of sccsidp[]. Aligning long strings to 32-byte boundaries is a pessimisation in kernels (because it makes poor locality poorer), especially on 486's where the cache line size is 16. Bruce not aligning data is extremely expensive on PII's rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:it a few times to build the cache before timing it. : :What is the stddev on your measurements ? : :a delta-T 1 second need a very tight stddev to be significant. The timing was +/- 0.5 second ( I ran the test four times ). But, remember, this is not comparing against GCC. This was simply comparing various EGCC optimization features. stddev on ~160 seconds +/- 0.5s is basically 0, so it is not a useful measurement beyond noting that it is near 0. I would love to see a comparison against GCC. I blew away my GCC :-( and do not want to spend time reinstalling it. :-- :Poul-Henning Kamp FreeBSD coreteam member :p...@freebsd.org Real hackers run -current on their laptop. :FreeBSD -- It will take a long time before progress goes too far! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:What is the stddev on your measurements ? : :a delta-T 1 second need a very tight stddev to be significant. I would say that a 1% increase or decrease in performance is not significant, so stddev is not significant either. There are too many other factors ( such as running a single program suite - EGCC, that does one task - compiling, instead of many different suites ). -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
On Tue, 6 Apr 1999, Matthew Dillon wrote: It's no big deal, really. I think the EGCS bandwagon is going to continue to move forward and PGCS runs on top of it, so moving to EGCS puts FreeBSD in a better position in the long term. Well what would be the chances of getting the pgcc patches committed? It seems like this wouldn't have a negative impact on other non x86 hardware, but might be a win for us stuck with Pentiums or PIIs. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
Well what would be the chances of getting the pgcc patches committed? I'm quite interested in doing this, BUT only after the dust has settled on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC patches aren't available yet. jdp and I have another round of bootstraping to fix our current less-than-optimal exception handling. I want to wait a week or so until putting the changes into the tree. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
'what' is broken. C does not impose any sort of address ordering restriction on globals or autos that are declared next to each other. Right, except that 'what' isn't broken. It is vers.c (and conf/newvers.sh) that is broken, believing that the two variables will be allocating in contiguous memory. Changing newvers.sh to generate char sccs[] = @( #) FreeBSD ...; char version = FreeBSD ...; I will assume you meant char *version here. will make what on the kernel work again, at the expense of about 100 duplicated bytes. Check me if I'm wrong, but could we not do the same thing without the duplication: char sccs[] = @( #) FreeBSD ...; char *version = sccs + 4; Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: EGCS optimizations
On Tue, 6 Apr 1999, David O'Brien wrote: Well what would be the chances of getting the pgcc patches committed? I'm quite interested in doing this, BUT only after the dust has settled on the EGCS import and the Alpha build is fixed. Also the 1.1.2 PGCC patches aren't available yet. Cool!! jdp and I have another round of bootstraping to fix our current less-than-optimal exception handling. I want to wait a week or so until putting the changes into the tree. Well, congrats on the reasonably smooth job so far. The only other thing I'd have on my wish list is the ability to not build the gcc related bits (so I could say drop in TenDRA) by adding -DNO_GCC or something. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. VERY good question. I have no opinion in the matter, but will follow the wishes of others (or Core, or committers, or who ever should make this decision and who ever tells me which way to go). -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
David O'Brien wrote: What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. VERY good question. I have no opinion in the matter, but will follow the wishes of others (or Core, or committers, or who ever should make this decision and who ever tells me which way to go). My take on this is that it could be a lot more difficult to make as a port than as a SUBDIR+= ? My (non-binding and unemotional) vote is for Fortran to be in the base system. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
David O'Brien wrote: What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. VERY good question. I have no opinion in the matter, but will follow the wishes of others (or Core, or committers, or who ever should make this decision and who ever tells me which way to go). My preference is to have g77 as part of the base egcs in the tree, and if we need f77 (ie: the Fortran-C translator), port-ify it since it is easily made standalone while g77 isn't. The sticky bit is what how to handle libI77 and libF77.. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs c++ problems
Thomas T. Veldhouse wrote: Are there any parts of world that are going to have a hard time building under egcs because of this? There would be if it had stay like that... the last changes from David : cvs commit: src/gnu/lib/libstdc++/doc Makefile Date: Mon, 5 Apr 1999 03:21:31 -0700 (PDT) fix it. I just recompiled your program with the new libstdc++.so.3, and it's fine. PYD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
Peter Wemm wrote:
David O'Brien wrote:
What will become of f77 which is in src/gnu/usr.bin/cc/f77? This
seems to be a good time to decide what will happen with Fortran in the
base FreeBSD system.
VERY good question. I have no opinion in the matter, but will follow the
wishes of others (or Core, or committers, or who ever should make this
decision and who ever tells me which way to go).
My preference is to have g77 as part of the base egcs in the tree, and if
we need f77 (ie: the Fortran-C translator), port-ify it since it is easily
made standalone while g77 isn't.
I already have a port of f2c and a new f77 wrapper to deal with
f2c+gcc. The includes the runtime libraries libI77 and libF77.
The sticky bit is what how to handle libI77 and libF77..
g77 has combined these libraries into is libg77.
If g77 were brought into the tree, I think we could delete
src/gnu/usr.bin/cc/f77, src/lib/{f2c, libI77, libF77}, and
src/usr.bin/f2c.
--
Steve
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: egcs
What will become of f77 which is in src/gnu/usr.bin/cc/f77? This seems to be a good time to decide what will happen with Fortran in the base FreeBSD system. VERY good question. I have no opinion in the matter, but will follow the wishes of others (or Core, or committers, or who ever should make this decision and who ever tells me which way to go). My vote is to include the sources for g77 that go with the egcs suite, but to have a knob in /etc/make.conf (BUILD_G77=yes) to control if they get built or not. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
: Okay, let me be a little clearer ;) What(1) on the kernel no longer works
:because previously, the
:char sccs[] = { '@', '(', '#', ')' };
:char version[] = blahhhfoo;
:Was contiguous. However, nowadays, nice EGCS pads 4 bytes (WHY?!?!) between
:those. So it appears @(#)\0\0\0\0FreeBSD. in the binary. Of course,
:strings are null-terminated... :P I don't know why EGCS does this!
:
: Brian Feldman_ __ ___ ___ ___ ___
: gr...@unixhelp.org_ __ ___ | _ ) __| \
: FreeBSD: The Power to Serve! _ __ | _ \__ \ |) |
: http://www.freebsd.org _ |___/___/___/
'what' is broken. C does not impose any sort of address ordering
restriction on globals or autos that are declared next to each other.
While it is true that programmers regularly make assumptions in regards
to the placement and alignment of fields in structures and the
placement and alignment of arguments to procedures, it does not follow
that programmers can make assumptions in regards to the placement and
alignment of globals.
EGCS is trying to optimize access to the array by aligning it, in order
to reduce cache line burst-from-meory inefficiencies. It happens
to break bad assumptions made in 'what'.
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
Hmm. interesting. My test kernel under GCC was considerably smaller then my test kernel under EGCS, even with -Os. textdata bss dec hex filename 1287575 95512 122972 1506059 16fb0b kernel.gcc -O2 1326304 111628 125708 1563640 17dbf8 kernel.egcs -Os -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Matthew Dillon wrote: My conclusion: Don't bother with -mpentiumpro or -march=pentiumpro. Not only do they not result in better performance, -march=pentiumpro will not run on a K6-2. I dunno about a K6-3. -mcpu does not change the assembly output at all. -march=cpu does change the assembly output, but does not appear to result in any noticeable improvement in performance over not using -m at all. Totally informally, I replaced libc (compiled with -O2) with one compiled with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit slower (GNU make took longer to traverse directories and egcs took a bit longer to run). Which leads me to believe that using -Os might be beneficial. Have you tried anything beyond -O2? - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:Totally informally, I replaced libc (compiled with -O2) with one compiled :with -mpentiumpro and -O6, and compiling kdebase seemed to run a bit :slower (GNU make took longer to traverse directories and egcs took a bit :longer to run). : : Which leads me to believe that using -Os might be beneficial. : :Have you tried anything beyond -O2? : :- alex There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. The only other optimization that might be useful is -fomit-frame-pointer, but it makes debugging impossible. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
On Monday, 5th April 1999, Matthew Dillon wrote:
:char sccs[] = { '@', '(', '#', ')' };
:char version[] = blahhhfoo;
:Was contiguous.
'what' is broken. C does not impose any sort of address ordering
restriction on globals or autos that are declared next to each other.
Well, it's really an abuse of 'what', and not anything wrong with 'what'
ifself. It will continue to work fine doing the job it was designed to do.
The NetBSD folks faced this problem some time ago, and I believe their
solution was to duplicate the version information. So, version[] is the
same as it used to be, and sccs[] is 4 bytes longer than version[] to hold
a complete copy, and the @(#) prefix. This is then completely portable.
Alternately, we could jimmy around with the current hack, and prefix it
with 4 NULs, and see what happened. Sorry, I haven't tested this idea, as
I've not yet made the EGCS jump.
Stephen.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
On Mon, 5 Apr 1999, Matthew Dillon wrote: There is nothing beyond -O2. Well, there's -O3, which tries to inline static functions, but that typically isn't beneficial because it really bloats up the code and subroutine calls on intel cpus are very fast. Really? The pgcc web page (goof.com/pcg) lead me to believe that there were a few more optimizations turned on by -O5 -O6.. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS optimizations
:On Mon, 5 Apr 1999, Matthew Dillon wrote: : : There is nothing beyond -O2. Well, there's -O3, which tries to : inline static functions, but that typically isn't beneficial because : it really bloats up the code and subroutine calls on intel cpus are : very fast. : :Really? : :The pgcc web page (goof.com/pcg) lead me to believe that there were a few :more optimizations turned on by -O5 -O6.. : :- alex pgcc != egcs. PGcc is a patchset on top of egcs and I suppose they might have added additinoal -O options, but egcs itself does not go beyond -O3. The PGcc faq indicates that they are slowly folding their stuff into egcs. Hopefully they've fixed the bugs :-). I have not tried compiling a kernel under pgcc but now that FreeBSD has moved to EGCS, it may actually work! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS and Alpha builds
On Sun, 4 Apr 1999, David O'Brien wrote: I should mention that ``make world'' on the alpha should be considered totally broken until an Alpha developer can tweak the contrib/egcs/gcc/config/freebsd.h and contrib/egcs/gcc/config/alpha/freebsd*.h bits. I would really like to see contrib/egcs/gcc/config/alpha/freebsd*.h combined into one file. I'll try to take a look tomorrow but I have visitors coming so I can't promise anything. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
what's the name of the system compiler going to be, egcs or gcc, or cc? And the C++ one? No change in names. cc/gcc and c++/g++/CC -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
Hi, On Sun, Apr 04, 1999 at 04:02:28PM -0700, David O'Brien wrote: what's the name of the system compiler going to be, egcs or gcc, or cc? And the C++ one? No change in names. cc/gcc and c++/g++/CC Experience says there are a lot of ports which look for egcc and eg++, so it might be nice to add these (and all the other names used for the port) as hardlinks. Won't cost anything (well a few bytes...), and also will help with the depends checking on ports. Regards, -Jeremy -- | I could be anything I wanted to, but one things true --+-- Never gonna be as big as Jesus, never gonna hold the world in my hand |Never gonna be as big as Jesus, never gonna build a promised land |But that's, that's all right, OK with me... -Audio Adrenaline To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs
Experience says there are a lot of ports which look for egcc and eg++, I thought those that do have exlicit CC=egcc and CXX=eg++ in the Makefiles. We will just remove them. so it might be nice to add these (and all the other names used for the port) as hardlinks. Nope. I still want the port around to do comparison testing with the base Egcs. Plus I'm reading a egcs-devel port. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: egcs
Besides, I can not imagine the base system is going to track egcs. At some point we will have a newer egcs port and the older system compiler, much as it was before. At least that is my take on things. Tom Veldhouse ve...@visi.com -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org]on Behalf Of Jeremy Lea Sent: Sunday, April 04, 1999 6:11 PM To: David O'Brien Cc: Chuck Robey; freebsd-current@FreeBSD.ORG Subject: Re: egcs Hi, On Sun, Apr 04, 1999 at 04:02:28PM -0700, David O'Brien wrote: what's the name of the system compiler going to be, egcs or gcc, or cc? And the C++ one? No change in names. cc/gcc and c++/g++/CC Experience says there are a lot of ports which look for egcc and eg++, so it might be nice to add these (and all the other names used for the port) as hardlinks. Won't cost anything (well a few bytes...), and also will help with the depends checking on ports. Regards, -Jeremy -- | I could be anything I wanted to, but one things true --+-- Never gonna be as big as Jesus, never gonna hold the world in my hand |Never gonna be as big as Jesus, never gonna build a promised land |But that's, that's all right, OK with me... -Audio Adrenaline To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs knob and objective C
Is there a simple knob to turn to get the egcs compiler by default? Not really. You would have to CVSup my src/gnu/ bits and spam them over the /usr/src/ tree. And, at the risk of being flamed, I noticed (after all these years) that we build some for Objective C stuff. Is this actually required within the base distribution? Yes. It is too tightly tied into the reset of the Gnu compiler that it would be too hard to make a port out of it. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs knob and objective C
Is there a simple knob to turn to get the egcs compiler by default? Not really. You would have to CVSup my src/gnu/ bits and spam them over the /usr/src/ tree. When do you intend to throw the switch in bringing egcs in by default? A lot of people are asking and perhaps a bit of an advance schedule wouldn't hurt at this point, if for no other reason than that people wouldn't be able to scream (with any justification) about the transition, when it happens, taking them by total surprise. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs knob and objective C
Also, I seem to recall that we already have another copy of libiberty (under gdb). Do we really need to have both of them? The EGCS copy is newer. We are considering building a libiberty.* for /usr/lib/. Once we know which sources to use, the duplicate can be deleted. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs knob and objective C
On Fri, 2 Apr 1999, David O'Brien wrote: Also, I seem to recall that we already have another copy of libiberty (under gdb). Do we really need to have both of them? The EGCS copy is newer. We are considering building a libiberty.* for /usr/lib/. Once we know which sources to use, the duplicate can be deleted. We should also consider installing libbfd. If and when we bring in a newer version of gdb, it would be a good idea to avoid importing yet another version of libiberty and libbfd. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: egcs knob and objective C
On 2 April 1999 at 22:25, Doug Rabson d...@nlsystems.com wrote: We should also consider installing libbfd. If and when we bring in a newer version of gdb, it would be a good idea to avoid importing yet another version of libiberty and libbfd. ... and GNU regex. Jacques Vidrine / n...@nectar.com / nec...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
