Author: Xiaojuan Zhai <zhaixiaojuan@loongson.cn> Author: Meidan Li <limeidan@loongson.cn> Author: Guoqi Chen <chenguoqi@loongson.cn> Author: Xiaolin Zhao <zhaoxiaolin@loongson.cn> Author: Fan peng <fanpeng@loongson.cn> Author: Jiantao Shan <shanjiantao@loongson.cn> Author: Xuhui Qiang <qiangxuhui@loongson.cn> Author: Jingyun Hua <huajingyun@loongson.cn> Author: Liu xue <liuxue@loongson.cn> Author: Hongliang Wang <wanghongliang@loongson.cn>
aside from the documented differences, which are the contents of this patch, GCC's -Os also has hard-coded unwanted behaviors which are impossible to override, like refusing to strength-reduce division by a constant to multiplication, presumably because the div saves a couple bytes of code. for this reason, getting rid of -Os and switching to an equivalent default optimization profile based on -O2 has been a long-term goal. as follow-ups, it may make sense to evaluate which of these variations from -O2 actually do anything useful, and eliminate the ones which are not helpful or which throw away performance for insignificant size savings. but for now, I've replicated -Os as closely as possible to provide a baseline for such evaluation.
unlike most projects that use -fno-strict-aliasing, we aim to have all sources respect the C language rules for effective type that make type-based alias analysis optimizations possible. unfortunately, it turns out that there are deep, and likely very difficult to fix, flaws in the TBAA performed by GCC and likely other compilers, whereby this kind of optimization can transform code that follows the rules strictly in ways that will make it malfunction. see for example GCC bugs 107107 and 107115, the latter of which also affects clang. there are not presently any known instances of breakage due to wrong type-based aliasing optimizations in our codebase. nonetheless, since the transformations are unsound and could introduce breakage, configure CFLAGS to build with -fno-strict-aliasing. some casual analysis of the effects on codegen suggest that this is unlikely to affect performance except possibly in the regex engine. in general, we should probably prefer making better use of the restrict keyword over relying on types to imply non-aliasing for optimization purposes; doing so should be able to get back any performance that was lost and more, should it turn out to matter (unlikely).
commit 0f814a4e57e80d2512934820b878211e9d71c93e removed its use.
use $srcdir in configure test for add-cfi script.
When the soft-float ABI for PowerPC was added in commit 5a92dd95c77cee81755f1a441ae0b71e3ae2bcdb, with Freescale cpus using the alternative SPE FPU as the main use case, it was noted that we could probably support hard float on them, but that it would involve determining some difficult ABI constraints. This commit is the completion of that work. The Power-Arch-32 ABI supplement defines the ABI profiles, and indeed ATR-SPE is built on ATR-SOFT-FLOAT. But setjmp/longjmp compatibility are problematic for the same reason they're problematic on ARM, where optional float-related parts of the register file are "call-saved if present". This requires testing __hwcap, which is now done. In keeping with the existing powerpc-sf subarch definition, which did not have fenv, the fenv macros are not defined for SPE and the SPEFSCR control register is left (and assumed to start in) the default mode.
The -a and -o operators are obsolescent and not in baseline POSIX.
now that -Wall is not used and we control which warnings are enabled, it makes sense to have the wanted ones on by default. hopefully this will also discourage manually adding -Wall to CFLAGS and making incorrect changes or bug reports based on the compiler's output.
-Wall varies too much by compiler and version. rather than trying to track all the unwanted style warnings that need to be subtracted, just enable wanted warnings. also, move -Wno-pointer-to-int-cast outside --enable-warnings conditional so that it always applies, since it's turning off a nuisance warning that's on-by-default with most compilers.