On Thu, 19 Mar 2020, Christophe Lyon wrote: > On Wed, 18 Mar 2020 at 20:30, Richard Biener <rguent...@suse.de> wrote: > > > > On March 18, 2020 6:20:29 PM GMT+01:00, Maxim Kuvyrkov > > <maxim.kuvyr...@linaro.org> wrote: > > > > > >> On 17 Mar 2020, at 17:40, Richard Biener <rguent...@suse.de> wrote: > > >> > > >> > > >> This adds a missing type conversion to build_fold_addr_expr and > > >adjusts > > >> fallout - build_fold_addr_expr was used as a convenience to build an > > >> ADDR_EXPR but some callers do not expect the result to be simplified > > >> to something else. > > >> > > >> Bootstrapped on x86_64-unknown-linux-gnu, testin in progress. > > >> > > >> This is the 3rd or 4th attempt and I hope to have catched all fallout > > > > > >> with this. I think it's inevitable we fix the mistake in > > >> build_fold_addr_expr. > > >> > > >> Richard. > > >> > > >> 2020-03-17 Richard Biener <rguent...@suse.de> > > >> > > >> PR middle-end/94188 > > >> * fold-const.c (build_fold_addr_expr): Convert address to > > >> correct type. > > >> * asan.c (maybe_create_ssa_name): Strip useless type conversions. > > >> * gimple-fold.c (gimple_fold_stmt_to_constant_1): Use build1 > > >> to build the ADDR_EXPR which we don't really want to simplify. > > >> * tree-ssa-dom.c (record_equivalences_from_stmt): Likewise. > > >> * tree-ssa-loop-im.c (gather_mem_refs_stmt): Likewise. > > >> * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Likewise. > > >> (simplify_builtin_call): Strip useless type conversions. > > >> * tree-ssa-strlen.c (new_strinfo): Likewise. > > >> > > >> * gcc.dg/pr94188.c: New testcase. > > > > > >Hi Richard, > > > > > >This breaks Linux kernel build on 32-bit ARM: > > > > > >00:01:29 ./include/linux/string.h:333:9: internal compiler error: in > > >gen_movsi, at config/arm/arm.md:6291 > > >00:01:29 make[2]: *** [sound/drivers/serial-u16550.o] Error 1 > > > > > >Would you please investigate? Let me know if you need any help > > >reproducing the problem. > > > > Please file a bug report with preprocessed source and instructions how to > > configure a cross to reproduce this. > > > > The change has caused more fallout than I expected... > > > > I think this commit is also causing regressions in gfortran, that's > probably easier to reproduce for you? > gfortran.dg/char_expr_3.f90 -O1 (internal compiler error) > gfortran.dg/char_expr_3.f90 -O2 (internal compiler error) > gfortran.dg/char_expr_3.f90 -O3 -fomit-frame-pointer > -funroll-loops -fpeel-loops -ftracer -finline-functions (internal > compiler error) > gfortran.dg/char_expr_3.f90 -O3 -g (internal compiler error) > > seen on cross arm-none-linux-gnueabi[hf]
Can't reproduce those on master (which has seen two fixes already). Richard. > Christophe > > > Thanks, > > Richard. > > > > >Kernel’s build line is (assuming cross-compilation): > > >make CC=/path/to/arm-linux-gnueabihf-gcc ARCH=arm > > >CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc allyesconfig > > > > > >Regards, > > > > > >-- > > >Maxim Kuvyrkov > > >https://www.linaro.org > > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
