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 PacketAliasInternetChec
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 membe
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
< said:
> Perhaps the above should be written as:
> sum += ntohs(*(u_char *)w << 8);
> to avoid the undefined union access (answer.us).
No. The IP checksum is defined in a manner which is
endian-independent. Adding calls to ntohs() would only confuse
matters further.
-GAWollma
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
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 (m
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 ``un
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 exac
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 a
On Mon, Nov 15, 1999 at 05:48:31PM +0100, Pierre Beyssac wrote:
> The problem is apparently due to the following code fragment:
>
> register u_short answer = 0;
> [...]
> /* mop up an odd byte, if necessary */
> if (nleft == 1) {
> *(u_char *)(&answer) = *(
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_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 wit
[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 the
: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,
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
< 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 condi
>
> > 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 ma
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 Unsub
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 re
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 [EMAI
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.
--
B
Peter Mutsaers wrote:
>
> >> "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" == 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
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.
--
Ollivie
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 build
> 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 w
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/gc
: > 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 "unsubscri
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
Peter Jeremy wrote:
> The recent thread about the GCC optimiser prompted me to go and have a
> 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. Both of them have README file
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
> #include
>
> 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
Have you tried using the C++ standard way? It works.
#include
#include
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 i
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 t
In message
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 with
> 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.
-
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 f7
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 wr
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 -fnoexpcetion
> 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 Cur
> > 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/
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
> > 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 lib
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 daem
> 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
> 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
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
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 abou
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 whil
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 _
* 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
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.
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
> >
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/
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 share
> 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. :)
-
* From: "David O'Brien"
* 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
> 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.
--
-- Dav
* From: "David O'Brien"
* 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
> 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 (
* From: "David O'Brien"
*
* 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 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 "unsu
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.
> 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
>>>'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
> con
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 pg
: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
:>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 wa
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 boundar
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
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 st
: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/l
> -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
> 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 fr
> '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
co
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 -m 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
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)
[...]
> -mp
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
>
> 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 i
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
>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
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 "unsubscri
: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?
:
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
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,
: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 bene
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. -m does not change
> the assembly output at all.
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 k
: 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.
>> 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
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
> "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 1
"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 Cor
"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 Cor
> 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 shoul
d-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, D
> 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
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
> 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
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
In article ,
Doug Rabson wrote:
> We should also consider installing libbfd.
We can do that any time (ELF only), as far as I'm concerned.
John
--
John Polstra j...@polstra.com
John D. Polstra & Co., Inc.Seattle, Washing
1 - 100 of 122 matches
Mail list logo
