Hi Richard: I think preserve -fno-builtin is better than -fno-tree-loop-distribute-patterns too,
However if we preserve -fno-builtin, the coming problem is should we preserve all -fbuiltin-* and do the check logic[1] in common code in gcc? btw, in our internal gcc 4.9.x tree is move -fno-builtin to common group (CL_COMMON) (preserve in lto since it's in CL_COMMON) and check it in tree-loop-distribution.c for temporary workaround . [1] gcc/c-family/c-common.c:disable_builtin_function On Thu, Aug 28, 2014 at 4:45 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Wed, Aug 27, 2014 at 4:42 PM, Kito Cheng <kito.ch...@gmail.com> wrote: >> Hi all: >> >> This patch basically is extension for r210100[1], stream out >> non-explicit -fno-tree-loop-distribute-patterns since compile with >> `-flto -O3 -fno-builtin` still may gen builtin function call during >> LTO phase. >> >> LTO bootstrapped and tested on x86_64-unknown-linux-gnu. > > Hmm, but that will for two units, one compiled with -O2 and one > compiled with -O3, produce -O3 -fno-tree-loop-distribute-patterns. > The previous patch restricted this to -ffreestanding / -fno-builtin. > > I think it makes more sense to preserve -fno-builtin, that is, > add 'LTO' to the list of FEs supporting 'fbuiltin' (the non-joined version) > and stream '-fno-builtin' if set, doing similar option post-processing > in the LTO frontend as I added to the C family frontends. > > Richard. > >> 2014-09-27 Kito Cheng <k...@0xlab.org> >> >> * lto-opts.c (lto_write_options): Output non-explicit >> -fno-tree-loop-distribute-patterns. >> * lto-wrapper.c (merge_and_complain): Merge >> -fno-tree-loop-distribute-patterns conservatively. >> (run_gcc): Pass through -fno-tree-loop-distribute-patterns. >> >> >> [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210100
