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.


Reply via email to