On Thu, May 24, 2018 at 12:50 AM Martin Sebor <mse...@gmail.com> wrote:
> The attached patch enhances the get_size_range() function to > extract more accurate ranges out of MIN_EXPR and MAX_EXPR nodes > with SSA_NAME operand(s). This helps -Wstringop-overflow avoid > false positives on some targets in cases like some of those > reported in bug 85623 - strncmp() warns about attribute nonstring > incorrectly in -Wstringop-overflow > When first trying to expand calls to __builtin_strncmp, most back > ends succeed even when the expansion results in a call to the library > function. The powerpc64 back-end, however, fails and and allows > the generic expansion to take place. There is a subtle difference > between the two cases that shows up when examining the bound of > the strncmp call expression (the third argument): in the original > call expression (in expand_builtin_strncmp) the bound is or can be > an SSA_NAME. But when the early expansion fails, > expand_builtin_strncmp transforms the original call expression into > a new one, substituting MIN_EXPR (bound, CST) for the bound where > CST is the constant result of strlen (STR), with STR being either > the first or second strncmp argument. When the bound is an SSA_NAME > the subsequent attempt to determine its range from the MIN_EXPR fails. Hmm, wouldn't sth extracted from the attached random patch I have lying around be more useful in general? That is, refactor the GENERIC expression walk in determine_value_range_1 to sth that can be used in the current get_range_info () interface? Or if we don't want to change that to accept non-SSA names add a corresponding get_expr_range_info () interface. If you do that please cut out the dominator/loop condition handling and refrain from the idea of looking at SSA def stmts. I always wanted an excuse to actually push parts of the idea in this patch to trunk. Thanks, Richard. > Martin
fix-pr62630-3
Description: Binary data
