On Mon, Oct 02, 2017 at 09:00:41AM -0600, Martin Sebor wrote:
> Thanks. That makes sense to me. The wrinkle with this approach
> is that the same code (same function) has different effects on
> the compiler (as in, is subject to different optimization
> decisions, or can cause false positives/negatives) depending
> whether some unrelated code (in another function) calls
> __builtin_stpcpy or calls (and declares) stpcpy, or does neither.
> This is probably not very common in application programs but it
> does happen often in the GCC test suite (this is the second time
> I've been bitten by it in just a few months).
Why is that a problem? In most user code, people just
#include <string.h> or #include <cstring> and depending on feature
test macros, either stpcpy is available, or not.
For GCC testsuite the tests that specially test for these transformations
have or intentionally don't have the stpcpy prototype available.
> IIUC, ideally, the decision whether or not to make
> the transformation would be based on whether stpcpy is called
> by the function on the result of a prior strcpy/strcat. A less
I don't understand this suggestion. Usually there is no stpcpy call
anywhere, we still want to make the transformation if we can assume
the library provides it. So you'd penalize a lot of code for no benefit.
Jakub
