On 10/20/18 6:01 PM, Martin Sebor wrote:
> > The warning only triggers when the bound is less than or equal > to the length of the constant source string (i.e, when strncpy > truncates). So IIUC, your suggestion would defer folding only > such strncpy calls and let gimple_fold_builtin_strncpy fold > those with a constant bound that's greater than the length of > the constant source string. That would be fine with me, but > since strncpy calls with a bound that's greater than the length > of the source are pointless I don't think they are important > enough to worry about folding super early. The constant ones > that serve any purpose (and that are presumably important to > optimize) are those that truncate. I was focused exclusively on the case where we have to look for a subsequent statement that handled termination. The idea was to only leave in the cases that we might need to warn for because we couldn't search subsequent statement for the termination. Splitting up was primarily meant to get the warning out of the folder with a minimal impact on code generation. But if the common case would result in deferral of folding, then I'd fully expect Richi to object. > > That said, when optimization isn't enabled, I don't think users > expect calls to library functions to be transformed to calls to > other functions, or inlined. Yet that's just what GCC does. > For example, besides triggering the warning, the following: I don't think we should drag this into the issue at hand. Though I do generally agree that folding this stuff into low level memory operations is not what most would expect at -O0. Jeff
