On 08/31/2018 01:08 AM, Bernd Edlinger wrote: > Hi, > > > when re-testing the new STRING_CST semantic patch here: > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01569.html > > I noticed that the (my) fix for PR 87053 does still use > semantic properties of the STRING_CST that is not compatible > with the new proposed STRING_CST semantics. > > That means that c_strlen needs to handle the case > where strings are not zero terminated. > > When this is fixed, fortran.dg/pr45636.f90 starts to regress, > because the check in gimple_fold_builtin_memory_op here: > > if (tree_fits_uhwi_p (len) > && compare_tree_int (len, MOVE_MAX) <= 0 > /* ??? Don't transform copies from strings with known length this > confuses the tree-ssa-strlen.c. This doesn't handle > the case in gcc.dg/strlenopt-8.c which is XFAILed for that > reason. */ > && !c_strlen (src, 2)) > > does now return NULL_TREE, because the fortran string is not null terminated. > However that allows the folding which makes the fortran test case fail. > > I fixed that by pulling in the c_getstr patch again, and use > it to make another exception for string constants without any embedded NUL. > That is what tree-ssa-forwprop.c can handle, and should make this work in > fortran again. > > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? I've gone the rounds on pr45636 a couple times and it's part of the reason why there's a FIXME in the bits I committed earlier this week.
I'll look at this closely in conjunction with the (unposted) patch which addresses the FIXME. Jeff
