This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH PR79868 ][aarch64] Fix error calls in aarch64 code so they can be translated (version 2)
- From: Steve Ellcey <sellcey at cavium dot com>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Martin Sebor <msebor at gmail dot com>, fmarchal <fmarchal at perso dot be>, "roland.illig" <roland dot illig at gmx dot de>
- Date: Tue, 31 Oct 2017 09:53:20 -0700
- Subject: Re: [PATCH PR79868 ][aarch64] Fix error calls in aarch64 code so they can be translated (version 2)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Steve dot Ellcey at cavium dot com;
- References: <1506381921.18449.22.camel@cavium.com> <b5ea1d1b-e1ec-b0de-b2f1-901e5f719b51@arm.com> <1509396631.10159.88.camel@cavium.com> <275df400-3dd4-aa10-2905-446ca8bab92c@arm.com>
- Reply-to: sellcey at cavium dot com
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Tue, 2017-10-31 at 09:57 +0000, Richard Earnshaw (lists) wrote:
>
> This is looking better...
>
> I may have missed some discussion on this topic, but what's the
> reasoning behind changing the quoting around the 'str' parameter
> value in
>
> - error ("unknown value %qs for 'cpu' target %s", str,
> pragma_or_attr);
> + error ("invalid name (\"%s\") in %<target(\"cpu=\")%> pragma
> or
> attribute", str);
>
> And also with the new generic message does the %<target(\"cpu=\")%>
> still make sense? My feeling is that the original text here is perhaps
> more appropriate. Similarly for other messages.
>
> R.
%qs uses single quotes vs. double quotes, changing that was suggested
by Martin Sebor in this comment:
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01569.html
using '%<target(\"cpu=\")%>' was also suggested by Martin in that
same thread at:
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01277.html
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01469.html
as being more consistent with other usage (mainly config/i386/i386.c).
Steve Ellcey
sellcey@cavium.com