https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Martin Jambor from comment #15) > Created attachment 58724 [details] > simple (wip) fix > > I'm wondering whether just simply something like this would not be enough. > I have looked at total scalarization and we will not replace a type found in > the IL with another one there. Similarly, only propagation through > assignments fiddles with existing types (when they are not aggregate) only > when propagating from RHS to LHS and not the other way round. > > If we want to be more aggressive, we can add a flag when the new predicate > fails but there is a good bitwise_type_for_mode and then when the flag is > set, use that type instead in analyze_access_subtree. > > Note that so far I have only tested the attached patch with > make -k check-gcc RUNTESTFLAGS="tree-ssa.exp=*sra*.c" > make -k check-g++ RUNTESTFLAGS="dg.exp=*sra*.c" > make -k check-gcc RUNTESTFLAGS="dg.exp=*sra*.c" > > I'll have a look at full test results tomorrow morning. I think it should be OK to fix the wrong-code issue in this bug but it prevents scalarization completely, likely at least failing gcc.dg/tree-ssa/sra-6.c Note the name of the predicate should probably reflect the problem, like can_use_type_as_storage_for (tree storage_type, tree value_type) or so. With my patch I trieds to instead use a bit-pattern preserving load similar as what we do with non-mode precision integer prevailing types. Note I plan to add a new target hook to identify problematic FP modes.
