Re: Comments on Release Building for -current
In the last episode (Aug 08), David O'Brien said: On Sun, Aug 04, 2002 at 08:01:10PM +1000, Bruce Evans wrote: sorry, but some time ago I read here that gcc -O2 breaks our printf() in libc. I haven't find any assembler code in /usr/src/lib/libc/stdio/vfprintf.c, ... If someone could find the small segment of code where the optimizer screws up, and write a small program to demonstrate the problem, we would have a good chance of it getting fixed. Er, someone (Dan Lukes) has already done this. See PR 40209. It looks like this PR is against the system GCC 3.1. As such it isn't a very interesting bug report. Someone needs to test to see if this bug exists when using the gcc31 (gcc 3.1.1 release) port. It does. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
David O'Brien wrote: If someone could find the small segment of code where the optimizer screws up, and write a small program to demonstrate the problem, we would have a good chance of it getting fixed. Er, someone (Dan Lukes) has already done this. See PR 40209. It looks like this PR is against the system GCC 3.1. As such it isn't a very interesting bug report. Someone needs to test to see if this bug exists when using the gcc31 (gcc 3.1.1 release) port. df seems to be a rather nice quick testcase (thanks perky). Compiling libc with -O2, then compiling df with it yields output like this: Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 252M5M:7M54%/ devfs 1.0K 1.0K 0B:0%/dev /dev/da0s1f 3.2G 2.2G 757M75%/usr /dev/da0s1e 252M28M 204M %/var procfs 4.0K 4.0K 0B:0%/proc linprocfs 4.0K 4.0K 0B:0% The system gcc3 and all versions of gcc3 in our ports do this. gcc295 does not. Regards, -- Michael Nottebrock And the reasons? There are no reasons. msg41726/pgp0.pgp Description: PGP signature
Re: Comments on Release Building for -current
Bruce Evans wrote: On Sat, 3 Aug 2002, Mike Barcroft wrote: Andrew Kolchoogin [EMAIL PROTECTED] writes: ... sorry, but some time ago I read here that gcc -O2 breaks our printf() in libc. I haven't find any assembler code in /usr/src/lib/libc/stdio/vfprintf.c, as such, if some C compiler can't handle VALID and STANDARDS-COMPLIANT C code, this compiler is broken. Isn't it? Indeed, all of FreeBSD users could help to catch such a bug in gcc optimizer code. :) If someone could find the small segment of code where the optimizer screws up, and write a small program to demonstrate the problem, we would have a good chance of it getting fixed. Er, someone (Dan Lukes) has already done this. See PR 40209. I'm sorry I haven't found time to look at it in detail. O2-compiling -CURRENT (and -march=athlon ...) still manages to break DCCs in xchat, like: Program received signal SIGBUS, Bus error. 0x286b3220 in __vfprintf () from /usr/lib/libc.so.5 (gdb) bt #0 0x286b3220 in __vfprintf () from /usr/lib/libc.so.5 #1 0x286b20ca in __vfprintf () from /usr/lib/libc.so.5 #2 0x286ad622 in snprintf () from /usr/lib/libc.so.5 #3 0x08066036 in fe_dcc_update_recv () #4 0x08086ee0 in dcc_check_timeouts () #5 0x0809dd83 in lag_check () #6 0x2825c496 in g_timeout_dispatch () from /usr/local/lib/libglib12.so.3 #7 0x2825b658 in g_main_dispatch () from /usr/local/lib/libglib12.so.3 #8 0x2825bbf9 in g_main_iterate () from /usr/local/lib/libglib12.so.3 #9 0x2825bd86 in g_main_run () from /usr/local/lib/libglib12.so.3 #10 0x2844fa38 in gtk_main () from /usr/X11R6/lib/libgtk12.so.2 #11 0x08069311 in fe_main () #12 0x0809e950 in main () #13 0x080638c1 in _start () Regards, -- Michael Nottebrock And the reasons? There are no reasons. msg41682/pgp0.pgp Description: PGP signature
Re: Comments on Release Building for -current
On Sun, Aug 04, 2002 at 08:01:10PM +1000, Bruce Evans wrote: sorry, but some time ago I read here that gcc -O2 breaks our printf() in libc. I haven't find any assembler code in /usr/src/lib/libc/stdio/vfprintf.c, ... If someone could find the small segment of code where the optimizer screws up, and write a small program to demonstrate the problem, we would have a good chance of it getting fixed. Er, someone (Dan Lukes) has already done this. See PR 40209. It looks like this PR is against the system GCC 3.1. As such it isn't a very interesting bug report. Someone needs to test to see if this bug exists when using the gcc31 (gcc 3.1.1 release) port. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
On Sat, 3 Aug 2002, Mike Barcroft wrote: Andrew Kolchoogin [EMAIL PROTECTED] writes: ... sorry, but some time ago I read here that gcc -O2 breaks our printf() in libc. I haven't find any assembler code in /usr/src/lib/libc/stdio/vfprintf.c, as such, if some C compiler can't handle VALID and STANDARDS-COMPLIANT C code, this compiler is broken. Isn't it? Indeed, all of FreeBSD users could help to catch such a bug in gcc optimizer code. :) If someone could find the small segment of code where the optimizer screws up, and write a small program to demonstrate the problem, we would have a good chance of it getting fixed. Er, someone (Dan Lukes) has already done this. See PR 40209. I'm sorry I haven't found time to look at it in detail. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
Andrew Kolchoogin [EMAIL PROTECTED] writes: David, On Fri, Aug 02, 2002 at 12:39:55AM -0700, David O'Brien wrote: The rest of the GCC using world can use -O2 on their code. We are the only ones that have so much trouble with it. It is probably due to our bugs, not GCC's. sorry, but some time ago I read here that gcc -O2 breaks our printf() in libc. I haven't find any assembler code in /usr/src/lib/libc/stdio/vfprintf.c, as such, if some C compiler can't handle VALID and STANDARDS-COMPLIANT C code, this compiler is broken. Isn't it? Indeed, all of FreeBSD users could help to catch such a bug in gcc optimizer code. :) If someone could find the small segment of code where the optimizer screws up, and write a small program to demonstrate the problem, we would have a good chance of it getting fixed. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
On Fri, Aug 02, 2002 at 04:20:53AM +1000, Bruce Evans wrote: I wouldn't trust -O2 for releases without lots of testing in -current (and not updating the compiler after testing). The rest of the GCC using world can use -O2 on their code. We are the only ones that have so much trouble with it. It is probably due to our bugs, not GCC's. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
David, On Fri, Aug 02, 2002 at 12:39:55AM -0700, David O'Brien wrote: The rest of the GCC using world can use -O2 on their code. We are the only ones that have so much trouble with it. It is probably due to our bugs, not GCC's. sorry, but some time ago I read here that gcc -O2 breaks our printf() in libc. I haven't find any assembler code in /usr/src/lib/libc/stdio/vfprintf.c, as such, if some C compiler can't handle VALID and STANDARDS-COMPLIANT C code, this compiler is broken. Isn't it? Indeed, all of FreeBSD users could help to catch such a bug in gcc optimizer code. :) Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Comments on Release Building for -current
On Wed, 31 Jul 2002, John Baldwin wrote: On 31-Jul-2002 Chris Knight wrote: ... the mfsroot floppy contents were too large ... the kern floppy contents were too large ... the fixit floppy contents were too large ... Oof. It's like our binaries are suddenly very bloated. Did this start very recently (like in the past few days?) Perhaps -mcpu=pentiumpro bloats things and we should use NO_CPU_FLAGS when building crunches, etc. -mcpu=pentiumpro causes huge bloatage here (+400K text for a 2000K text kernel IIRC). I quickly turned it off here. We might also want to use -Os instead of -O when building the kernels and crunches as well. I'm surprised -Os [-falign...] isn't already the default for crunches. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
On Fri, Aug 02, 2002 at 02:57:44AM +1000, Bruce Evans wrote: I'm surprised -Os [-falign...] isn't already the default for crunches. -Os is -O2 except for those optimizations which bloat. We don't trust -O2 and thus maybe should not -Os. Hopefully we have found all our bad in-line ASM and -O2 will work for FreeBSD now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
In the last episode (Aug 01), David O'Brien said: On Fri, Aug 02, 2002 at 02:57:44AM +1000, Bruce Evans wrote: I'm surprised -Os [-falign...] isn't already the default for crunches. -Os is -O2 except for those optimizations which bloat. We don't trust -O2 and thus maybe should not -Os. Hopefully we have found all our bad in-line ASM and -O2 will work for FreeBSD now. There is still a libc printf bug at -O2. It causes numbers to be printed with and : characters occasionally. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Comments on Release Building for -current
On 01-Aug-2002 Bruce Evans wrote: On Wed, 31 Jul 2002, John Baldwin wrote: On 31-Jul-2002 Chris Knight wrote: ... the mfsroot floppy contents were too large ... the kern floppy contents were too large ... the fixit floppy contents were too large ... Oof. It's like our binaries are suddenly very bloated. Did this start very recently (like in the past few days?) Perhaps -mcpu=pentiumpro bloats things and we should use NO_CPU_FLAGS when building crunches, etc. -mcpu=pentiumpro causes huge bloatage here (+400K text for a 2000K text kernel IIRC). I quickly turned it off here. Ok. I'll make some patches to use NO_CPU_CFLAGS and NO_CPU_COPTFLAGS when building stuff to go on the crunches as well as -Os. We might also want to use -Os instead of -O when building the kernels and crunches as well. I'm surprised -Os [-falign...] isn't already the default for crunches. Bruce -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
Yup, it's been reported several times by various people and it seems everyone who can help is too busy to care. This isn't fun anymore. :-( -- Jerry Hicks On Wednesday, July 31, 2002, at 06:18 AM, Chris Knight wrote: Howdy, As the snapshot manager at snapshots.jp.freebsd.org would be aware, current's release building capability is woeful to say the least. A fair bit of tidying up will need to be done for DP2. I've managed to complete a successful release build of current with a checkout of two days ago. For those interested, here's what I had to do: the mfsroot floppy contents were too large FIX: - edit /usr/src/release/i386/drivers.conf and move the following drivers from floppy 2 to floppy3: aue, cue, em, kue, sk, ti, wb, xe, and the SYSV stuff - edit /usr/src/release/scripts/driver-copy2.awk to not error when it encounters the floppy 3 candidates the kern floppy contents were too large FIX: - edit /usr/src/release/i386/dokern.sh and get sed to remove more drivers from MFSROOT. The drivers are: eisa, ahb, isp, ses the fixit floppy contents were too large FIX: - edit /usr/src/release/i386/fixit_crunch.conf and remove the following programs: mount_msdosfs restore rrestore telnet As you can see, all three 1.44MB floppies run out of space. With the above changes, the build just scrapes by. I'd imagine that the changes I made still wouldn't be enough for a release build to be successful for PC98 or Alpha. I'm happy to help resolve the release building issue if anybody is interested. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Comments on Release Building for -current
On 31-Jul-2002 Chris Knight wrote: Howdy, As the snapshot manager at snapshots.jp.freebsd.org would be aware, current's release building capability is woeful to say the least. A fair bit of tidying up will need to be done for DP2. I've managed to complete a successful release build of current with a checkout of two days ago. For those interested, here's what I had to do: the mfsroot floppy contents were too large FIX: - edit /usr/src/release/i386/drivers.conf and move the following drivers from floppy 2 to floppy3: aue, cue, em, kue, sk, ti, wb, xe, and the SYSV stuff - edit /usr/src/release/scripts/driver-copy2.awk to not error when it encounters the floppy 3 candidates the kern floppy contents were too large FIX: - edit /usr/src/release/i386/dokern.sh and get sed to remove more drivers from MFSROOT. The drivers are: eisa, ahb, isp, ses the fixit floppy contents were too large FIX: - edit /usr/src/release/i386/fixit_crunch.conf and remove the following programs: mount_msdosfs restore rrestore telnet As you can see, all three 1.44MB floppies run out of space. With the above changes, the build just scrapes by. I'd imagine that the changes I made still wouldn't be enough for a release build to be successful for PC98 or Alpha. I'm happy to help resolve the release building issue if anybody is interested. Oof. It's like our binaries are suddenly very bloated. Did this start very recently (like in the past few days?) Perhaps -mcpu=pentiumpro bloats things and we should use NO_CPU_FLAGS when building crunches, etc. We might also want to use -Os instead of -O when building the kernels and crunches as well. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Comments on Release Building for -current
Howdy, -Original Message- From: John Baldwin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 31 July 2002 23:12 To: Chris Knight Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Comments on Release Building for -current [snip] Oof. It's like our binaries are suddenly very bloated. Did this start very recently (like in the past few days?) Perhaps -mcpu=pentiumpro bloats things and we should use NO_CPU_FLAGS when building crunches, etc. We might also want to use -Os instead of -O when building the kernels and crunches as well. I had been doing semi-regular builds (twice weekly) up until early June. However, kernel stability then became an issue for me. Looking at snapshots.jp.freebsd.org, releases stopped being built on June 21, with the exception of July 7 and 8. I've been given some useful suggestions. I shall now go and do some more builds, then summarise the size changes to the list. It will take a while - my -current build box is a PII-300 laptop. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
On Wed, Jul 31, 2002 at 08:33:38AM -0400, W Gerald Hicks wrote: Yup, it's been reported several times by various people and it seems everyone who can help is too busy to care. This isn't fun anymore. :-( Uhm, did I miss something? Where does this attitude come from? Did you submit some patches for these problems that were ignored or something? Can we try to be a little more constructive here about solving problems? - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Comments on Release Building for -current
Murray Stokely wrote: On Wed, Jul 31, 2002 at 08:33:38AM -0400, W Gerald Hicks wrote: Yup, it's been reported several times by various people and it seems everyone who can help is too busy to care. This isn't fun anymore. :-( Uhm, did I miss something? Where does this attitude come from? Did you submit some patches for these problems that were ignored or something? Can we try to be a little more constructive here about solving problems? You're jumping on him a bit hard. It's pretty obvious that: 1) It used to work 2) Someone changed something that broke things 3) People complained about the breakage 4) The someone who broke things didn't unbreak them The simplest patch is obtained from: cvs diff -D date before it broke i.e.: back out whatever change is screwing everyone over. It's a reasonable thing to want, if the original author of the breakage is unwilling/unable to unbreak things. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
