This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Invoke maybe_warn_nonstring_arg for strcpy/stpcpy builtins.
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 <krebbel@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-