"-Os" was specfied when gcc 4.5.x was imported and the commit log says
"-O2 produces much bigger code with gcc 4.5 than it did with gcc 4.1"
but "-Os" disables most inline declarations and makes some applications
much slower. "-O2 -fno-reorder-blocks" seems enough to reduce sizes
and disabling -freorder-blocks wouldn't cause particular performance
impact on ancient m68k machines with small cache memories.
See my post on port-m68k@ for more details:
http://mail-index.NetBSD.org/port-m68k/2014/06/22/msg000488.html
No objection in the thread and "seems fine to me" from mrg@.
http://mail-index.NetBSD.org/source-changes/2014/06/29/msg055885.html
---
Tweak LIB1ASMFUNCS order to avoid linker warnings on libgcc_s build with -O2.
Without this change, ld complains as the following:
>> libgcc_s_pic.a(_float.pico):(.text+0x8): relocation truncated to fit:
>> R_68K_PC16 against symbol `$_exception_handler' defined in .text section in
>> libgcc_s_pic.a(_floatex.pico)
_float.S and _double.S refer `$_exception_handler' declared in _floatex.S
and linking the _floatex.S first seems to work around these warnings
(probably caused by pic relative jump addresses).
See port-m68k@ posts for more details:
http://mail-index.NetBSD.org/port-m68k/2014/06/22/msg000488.html
---
Note m68k/defs.mk is manually edited to avoid extra diffs.
Without this change, ld complains as the following:
>> libgcc_s_pic.a(_float.pico):(.text+0x8): relocation truncated to fit:
>> R_68K_PC16 against symbol `$_exception_handler' defined in .text section in
>> libgcc_s_pic.a(_floatex.pico)
_float.S and _double.S refer `$_exception_handler' declared in _floatex.S
and linking the _floatex.S first seems to work around these warnings
(probably caused by pic relative jump addresses).
See port-m68k@ posts for more details:
http://mail-index.NetBSD.org/port-m68k/2014/06/22/msg000488.html
Note m68k.mk is manually edited to avoid extra diffs.
src/sys/sys/quotactl.h 1.37
src/sys/compat/netbsd32/netbsd32.h 1.101
src/sys/compat/netbsd32/netbsd32_netbsd.c 1.188, 1.189
src/sys/kern/vfs_quotactl.c 1.39
src/sys/kern/vfs_syscalls.c 1.483
src/sys/ufs/lfs/ulfs_quota.c 1.11
src/sys/ufs/ufs/ufs_quota.c 1.116
src/lib/libquota/quota_kernel.c 1.5
and do them correctly.
If you're going to change the name of something, you need to change
the name of *all* the things with the same name, not just a handful,
and you should change it to something similar so it still matches the
rest of the system rather than just picking an arbitrarily different
name.
Hi, Joerg.
To wit, rename the quotactl "delete" operation to "del", because
"delete" is a reserved word in C++ and for some reason Joerg wants to
run internal interfaces used only by C code through his C++ compiler.
Do not rename it to "remove" instead, because this doesn't match
libquota or the rest of the usage throughout the system; and rename
all the related identifiers, not just the ones that blew the mind of
Joerg's C++ compiler.
Because this is not a user-facing API (the only userland consumer
sys/quotactl.h is libquota) it is sort of ok to make arbitrary
source-incompatible changes; however, by the same token it's completely
unnecessary. If it *were* a user-facing API that someone might have a
semi-rational reason to want to run a C++ compiler on, it would be
incorrect to change it at this point.
resulting from feedback.
move multiple copies of code for parsing boot.cfg file from sparc, i386
and zaurus into libsa/bootcfg.{h,c}. largely retained i386 parsing logic
in addition to keeping sparc dispatch function while remaining consistent
with boot.cfg(5).
previous sparc64 file format has been obsoleted but only used by boot
CDs distrib/sparc64/bootfs/boot.cfg has been updated to compensate.
exported names have been prefixed with either BOOTCFG_ or bootcfg_ as per
feedback from christos@
tested on amd64 & sparc64 but not zaurus.
aligned, by using kmem_roundup_size(). There's no functional difference with
the current MAX().
2) If there isn't enough space in the page padding for the red zone, allocate
one more page, not just 2 bytes. We only poison 1 or 2 bytes in this page,
depending on the space left in the previous page. That way 'allocsz' is
properly aligned. Again, there's no functional difference since the shift
already handles it correctly.
