On 04/11/2018 11:20 PM, Martin Sebor wrote: > On 04/11/2018 06:47 AM, Andreas Krebbel wrote: >> On 04/11/2018 10:02 AM, Jakub Jelinek wrote: >>> On Wed, Apr 11, 2018 at 09:48:05AM +0200, Andreas Krebbel wrote: >>>> c-c++-common/attr-nonstring-3.c fails on IBM Z. The reason appears to be >>>> that we provide builtin implementations for strcpy and stpcpy. The >>>> warnings currently will only be emitted when expanding these as normal >>>> calls. >>>> >>>> Bootstrapped and regression tested on x86_64 and s390x. >>>> >>>> Ok? >>>> >>>> gcc/ChangeLog: >>>> >>>> 2018-04-11 Andreas Krebbel <kreb...@linux.vnet.ibm.com> >>>> >>>> * builtins.c (expand_builtin_strcpy): Invoke >>>> maybe_warn_nonstring_arg. >>>> (expand_builtin_stpcpy): Likewise. >>> >>> Don't you then warn twice if builtin implementations for strcpy and stpcpy >>> aren't available or can't be used, once here and once in calls.c? >> >> Looks like this could happen if the expander is present but rejects >> expansion. I basically copied >> this from the strcmp builtin which looks like possibly running into the same >> problem: > > I tried to avoid the problem in the other instances of the call > to maybe_warn_nonstring_arg (e.g., expand_builtin_strlen or > expand_builtin_strcmp). I don't know if the expander can fail > after the maybe_warn_nonstring_arg() call and so I have no > tests for it. > > In your patch the expander failing seems more likely than in > the others (in fact, on x86_64 it always fails because the call > to targetm.have_movstr () in expand_movstr() returns false). > > That said, I see two warnings for a call to strcmp() with > a nonstring argument even without the expander failing, so > what I did isn't quite right either. I opened bug 85359 for > it.
I've opened BZ85369 for the strcpy / stpcpy issue. -Andreas-
