On Thu, 19 Mar 2020 at 13:34, Richard Biener <rguent...@suse.de> wrote: > > 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). > Ha, it's possible this has been fixed, then. Sorry my validations are bit delayed these days.
Christophe > 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)
