Re: -current 'make release' status? [SOLVED]
On Tue, Jul 29, 2003 at 09:41:54AM -0400, John De Boskey wrote: - Ruslan Ermilov's Original Message - No, I have nothing in my environment that should affect the build, no /etc/make.conf in the chroot area.. But then again: running make rerelease is effectively just calls the command above. I'm currently in the middle of the make release and will see if this is reproduceable. # chroot /vol/vol0/work/5-current-chrootdir /bin/sh # env A few things not needed that are inherited from my normal account, but nothing that should have a negative affect. Do you still get the error if you try make rerelease? Do you still get the error if you try chroot ... /mk? Do you still get the error if you try env -i chroot ... /mk? I'll see what I can find.. John, I see the same breakage as you do. But in all three cases above, I see the same breakage (as expected). Even if I'm running chroot /data/ru/R then ./mk doMFSKERN, I still get it: : In file included from /usr/src/sys/cam/cam_periph.c:41: : /usr/src/sys/sys/buf.h: In function `BUF_LOCK': : /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break strict-aliasing rules : ... : *** Error code 1 : : Stop in /usr/obj/usr/src/sys/BOOTMFS. Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: -current 'make release' status? [SOLVED]
On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote: On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: -current 'make release' status? [SOLVED]
In the last episode (Jul 29), Ruslan Ermilov said: Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. That does work, but there are still things you can't turn off with -f. They're half-aliases. toplev.c::parse_options_and_default_flags does set -f flags based on the optimization level, but there is still a whole lot of gcc code that directly tests the value of optimize and optimize_size. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Tue, 29 Jul 2003, Ruslan Ermilov wrote: On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote: On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter ^^ This was too complete :-). I meant -Wno-strict-aliasing when I wrote it (since I misread the info about -Os). than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. Yes, this seems to be the only option that needs warnings about strict aliasing. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
